From Hannes.Tschofenig@gmx.net Sun Mar 1 05:28:18 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 3EE4728C285 for ; Sun, 1 Mar 2009 05:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 Ti+cJlmHhhyU for ; Sun, 1 Mar 2009 05:28:17 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D44B328C477 for ; Sun, 1 Mar 2009 05:20:34 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2009 13:20:58 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp013) with SMTP; 01 Mar 2009 14:20:58 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18HRcoAYYoHNWhKt5SLQB/jlsfsaEIwOE5wF4QfcS 6n+h7m7EoKaCRK From: "Hannes Tschofenig" To: References: Date: Sun, 1 Mar 2009 15:21:58 +0200 Message-ID: <004a01c99a70$b3e6c5b0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmX3aR0Y6wvwZimQIujMo9UyRlsxQAGXN1wAJ2/LoA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: 'Jouni Korhonen' , dime@ietf.org, elwynd@dial.pipex.com Subject: Re: [Dime] DISCUSS: draft-ietf-dime-qos-parameters 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, 01 Mar 2009 13:28:18 -0000 Hi Chris, We have updated the document to address your discuss: http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft-i etf-dime-qos-parameters-10.txt References have been added to the document as requested. Ciao Hannes >-----Original Message----- >From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >Sent: 26 February, 2009 11:49 >To: jouni korhonen; Jouni Korhonen; Hannes Tschofenig; >elwynd@dial.pipex.com >Cc: dave@frascone.com >Subject: FW: DISCUSS: draft-ietf-dime-qos-parameters > >Please refer to the DISCUSS below and propose the edits to >resolve the lack of references. > >Thanks and Regards, > >Dan > > >-----Original Message----- >From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On >Behalf Of Chris Newman >Sent: Thursday, February 26, 2009 8:44 AM >To: iesg@ietf.org >Cc: dime-chairs@tools.ietf.org; >draft-ietf-dime-qos-parameters@tools.ietf.org >Subject: DISCUSS: draft-ietf-dime-qos-parameters > >Discuss: >This document has the following flaws: > >1. It names the "Diameter" protocol without providing a >reference to the protocol specification. > >2. This uses a formal grammar to define protocol elements >without providing a reference to the definition of the formal grammar. > >I believe both problems are resolved by adding the missing >normative reference to the Diameter base specification. > > From Hannes.Tschofenig@gmx.net Sun Mar 1 05:30:32 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 CDCD728C1C1 for ; Sun, 1 Mar 2009 05:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 fh8WCU85gWM4 for ; Sun, 1 Mar 2009 05:30:32 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3315128C199 for ; Sun, 1 Mar 2009 05:27:59 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2009 13:21:43 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp047) with SMTP; 01 Mar 2009 14:21:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18hm4R+MrYhy9cFuepITU96Z17H1oTUEkfezyMMKL d/+seYe2eDJ3Wd From: "Hannes Tschofenig" To: "'Pasi Eronen'" , References: <20090226112813.F23013A6A71@core3.amsl.com> Date: Sun, 1 Mar 2009 15:22:44 +0200 Message-ID: <004b01c99a70$cec76b00$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090226112813.F23013A6A71@core3.amsl.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmYBWViXt1dVHYCSv6LbDPmPfAtrgCaTKXg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: dime@ietf.org, dime-chairs@tools.ietf.org, draft-ietf-dime-qos-parameters@tools.ietf.org Subject: Re: [Dime] DISCUSS: draft-ietf-dime-qos-parameters 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, 01 Mar 2009 13:30:32 -0000 Hi Pasi, Thanks for pointing out a bug in these two sections regarding extensibility. We have updated the draft to address your comments: http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft-i etf-dime-qos-parameters-10.txt Ciao Hannes >-----Original Message----- >From: Pasi Eronen [mailto:pasi.eronen@nokia.com] >Sent: 26 February, 2009 13:28 >To: iesg@ietf.org >Cc: dime-chairs@tools.ietf.org; >draft-ietf-dime-qos-parameters@tools.ietf.org >Subject: DISCUSS: draft-ietf-dime-qos-parameters > >Discuss: >The text about QoS Profile IDs (in last paragraph of Section 4 >and Section 5.2) doesn't make sense as is. The intent probably >is that the first four octets are an IANA-assigned Enterprise >Number, and for the latter four octets, IANA maintains a >registry for Enterprise Number 0 (but for other Enterprise >Numbers, it's up to the owner how they're used). > >But that's not quite what the text currently says (in 4.2, the >sentence "If the four octets.." does not parse, and in 5.2, it >suddenty starts talking about OIDs ). > >Also, what's the IANA assignment policy for numbers 4096..4294967295? > > From Hannes.Tschofenig@gmx.net Sun Mar 1 05:30: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 37ACE28C276 for ; Sun, 1 Mar 2009 05:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 EMGZ17ZcNV8j for ; Sun, 1 Mar 2009 05:30:41 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 121DA28C1CC for ; Sun, 1 Mar 2009 05:28:36 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2009 13:28:57 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp027) with SMTP; 01 Mar 2009 14:28:57 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19LQJMhDKFLoLZBamPwuXpaw/i2KSRsetFqZImCfk RCHjSpJUtPovnX From: "Hannes Tschofenig" To: References: Date: Sun, 1 Mar 2009 15:29:57 +0200 Message-ID: <004c01c99a71$d189a2d0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmYMWmpcIcM0M9ASCOGqe/kUK5EygCPW2Zg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: 'Jouni Korhonen' , dime@ietf.org, elwynd@dial.pipex.com Subject: Re: [Dime] One more DISCUSS on dime-qos-parameters 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, 01 Mar 2009 13:30:42 -0000 Hi Dave, Thank you for your review. > David Ward: > Discuss: > [2009-02-26] Fundamentally this seems to be an interface for > configuring a 2 rate 3-color marker and other QoS behavior. Additionally, I have to mention that AAA protocols provide more capabilities, including accounting for resource usage and authorization. > I don't > understand why the policer is defined in absolute bandwidth in this > draft and doesn't include percentage. Because it matches the generic specifier in RFC 2215. Nobody had requirements for expressing percentage values. Are there QoS specifiers based on percentage defined somewhere in current RFCs? > Also on the usage of Bandwidth AVP, is it merely a > different unit of measurement from the Rate parameter in the TMOD AVP ? > It would be good to clarify. No, it is the same unit but is intended to be used in a separate context. Arguably you could use the same AVP but the feedback we got was to keep the semantic as simple as possible to make the life for those who use the system easier. Given that there is no shortage of AVPs in Diameter we did not see a problem with this approach. > > For the Priority AVP, is it to be used with RSVP for on-path CAC or > for local CAC decision or something else? It would be good to provide > some background information in the draft. > Diameter (and RADIUS for that matter) don't care too much where the information actually came from. It could be a link layer protocol, some configuration mechanism or also RSVP/NSIS. This draft defines the parameters and there is a separate document (http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-11.txt) that discusses the usage of the QoS parameters in context of Diameter AVP, without going too much into details on what the AAA server could do with each parameter. There are typically many options, such as logging, accounting, authorization, statistical analysis, charging, etc. Btw, more information regarding the priority element is provided in RFC 3181. I hope I was able to address your questions. Ciao Hannes >-----Original Message----- >From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >Sent: 26 February, 2009 18:44 >To: jouni korhonen; Jouni Korhonen; Hannes Tschofenig; >elwynd@dial.pipex.com >Cc: dave@frascone.com >Subject: One more DISCUSS on dime-qos-parameters > >Please address this DISCUSS as well. > >Dan > > >David Ward: >Discuss: >[2009-02-26] Fundamentally this seems to be an interface for >configuring a 2 rate 3-color marker and other QoS behavior. I >don't understand why the policer is defined in absolute >bandwidth in this draft and doesn't include percentage. Also >on the usage of Bandwidth AVP, is it merely a different unit >of measurement from the Rate parameter in the TMOD AVP ? >It would be good to clarify. > >For the Priority AVP, is it to be used with RSVP for on-path >CAC or for local CAC decision or something else? It would be >good to provide some background information in the draft. > From dromasca@avaya.com Sun Mar 1 06:04:01 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 177D23A67B3 for ; Sun, 1 Mar 2009 06:04:01 -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.088, 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 Wo3YuK7WPg8M for ; Sun, 1 Mar 2009 06:04:00 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 43AB63A6A8C for ; Sun, 1 Mar 2009 06:03:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,284,1233550800"; d="scan'208,217";a="153830324" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Mar 2009 09:04:09 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Mar 2009 09:04:09 -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_01C99A76.8D66E146" Date: Sun, 1 Mar 2009 15:03:51 +0100 Message-ID: In-Reply-To: <005301c9998a$03eba040$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments on RFC3588bis Thread-Index: AcmZigPfw3ZQR/rXRsqe9mSq7RK14gA5/FVg References: <005301c9998a$03eba040$7b27460a@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "Fortune HUANG" , Subject: Re: [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: Sun, 01 Mar 2009 14:04:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99A76.8D66E146 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Fortune, =20 The DIME working group is working under a charter that includes maintenance and extensions of the Diameter base protocol for specific AAA applications.=20 A change in the scope of the Diameter base protocol seems to me to be beyond what the WG is chartered to do at this point in time. If you believe that an extension of the scope of Diameter is necessary you need to came with a separate proposal, as this looks like a change of charter or maybe the charter of another working group.=20 =20 Dan =20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Saturday, February 28, 2009 11:51 AM To: dime@ietf.org Subject: [Dime] Comments on RFC3588bis =09 =09 Hi all, =20 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. =20 Take the definitions in section 1.3 for example. =20 " Diameter Client =20 A Diameter Client is a device at the edge of the network that performs access control. ... ... =20 Diameter Server=20 =20 A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. ..." =20 For an non-AAA application, these defintions are not precise at all.=20 =20 =20 Best Regards, Fortune =20 ------_=_NextPart_001_01C99A76.8D66E146 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Fortune,
 
The DIME working group is working under a = charter=20 that includes maintenance and extensions of the Diameter base = protocol for=20 specific  AAA applications.
A change in the scope of the Diameter base protocol = seems to=20 me to be beyond what the WG is chartered to do at this point in time. If = you=20 believe that an extension of the scope of Diameter is necessary you need = to came=20 with a separate proposal, as this looks like a change of charter or = maybe the=20 charter of another working group.
 
Dan
 
=
From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Fortune=20 HUANG
Sent: Saturday, February 28, 2009 11:51 = AM
To:=20 dime@ietf.org
Subject: [Dime] Comments on=20 RFC3588bis

Hi = all,
 
With the wide use = in multiple=20 applications, I think nowadays the Diameter protocol should not = be=20 considered as only a AAA protocol. Many of the Diameter = applications have nothing to do with the Authentication, Authorization = and=20 Accounting, although the AAA applications are some of the important=20 applications. Therefore, I propose we revise RFC3588bis to reflect this=20 fact.
 
Take the = definitions in=20 section 1.3 for example.
 
"   Diameter Client
 
      A Diameter Client = is a device=20 at the edge of the network that
      = performs=20 access control.  ...
...
 
Diameter Server=20
 
      A Diameter Server is one that = handles=20 authentication,
      authorization and = accounting=20 requests for a particular realm.  ..."
 
For an non-AAA = application,=20 these defintions are not precise at all.
 
 
Best=20 Regards,
Fortune
 
------_=_NextPart_001_01C99A76.8D66E146-- From dromasca@avaya.com Sun Mar 1 07:00:18 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 5BF183A6B14 for ; Sun, 1 Mar 2009 07:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.355, 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 JH0RoPx4ZdYP for ; Sun, 1 Mar 2009 07:00:11 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 361DA3A6ABF for ; Sun, 1 Mar 2009 07:00:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,285,1233550800"; d="scan'208,217";a="153832145" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Mar 2009 10:00:35 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Mar 2009 10:00:35 -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_01C99A7E.75639041" Date: Sun, 1 Mar 2009 16:00:26 +0100 Message-ID: In-Reply-To: <002701c99a7c$d3cb5470$9001a8c0@xxxx87e842e29b> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments on RFC3588bis Thread-Index: AcmZigPfw3ZQR/rXRsqe9mSq7RK14gA5/FVgAAH4gLAAANEA0A== References: <002701c99a7c$d3cb5470$9001a8c0@xxxx87e842e29b> From: "Romascanu, Dan (Dan)" To: "Fortune HUANG" , Subject: Re: [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: Sun, 01 Mar 2009 15:00:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99A7E.75639041 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Fortune, =20 RFC 3588 Abstract starts with:=20 =20 > The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility.=20 =20 DIME is chartered with extending Diameter within the scope of 3588 and not beyond. Non-AAA applications are beyond the scope.=20 =20 I read the phrase that you quote from the DIME charter as allowing to consider applications other than IP telephony and LAN AAA, but you still need to be within the scope of RFC 3588. =20 If you want to discuss further extensions of the scope of Diameter you need a WG rechartering or another WG.=20 =20 Regards, =20 Dan =20 =20 =20 ________________________________ From: Fortune HUANG [mailto:fqhuang@huawei.com]=20 Sent: Sunday, March 01, 2009 4:49 PM To: Romascanu, Dan (Dan); dime@ietf.org Subject: RE: [Dime] Comments on RFC3588bis =09 =09 Hi Dan, =20 Thank you very much for your advice. But before moving forward with your guidance, please allow me ask you a question in order to get rid of my doubt. =20 On the website of the DIME WG (i.e. http://www.ietf.org/html.charters/dime-charter.html), I found the following statement in the charter. =20 "The Diameter Maintanence and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting." =20 On reading this sentence, I think the AAA applications are only the example applications for DIME WG. I can't find any clue that the non AAA applications are outside the scope of DIME WG.=20 Did I understand the charter incorrectly at this point? Or did I not get the right version of the charter? Thanks. =20 Best Regards, Fortune=20 =20 =20 =09 ________________________________ From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Sunday, March 01, 2009 10:04 PM To: Fortune HUANG; dime@ietf.org Subject: RE: [Dime] Comments on RFC3588bis =20 Hi Fortune, =20 The DIME working group is working under a charter that includes maintenance and extensions of the Diameter base protocol for specific AAA applications.=20 A change in the scope of the Diameter base protocol seems to me to be beyond what the WG is chartered to do at this point in time. If you believe that an extension of the scope of Diameter is necessary you need to came with a separate proposal, as this looks like a change of charter or maybe the charter of another working group.=20 =20 Dan =20 =20 =09 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Saturday, February 28, 2009 11:51 AM To: dime@ietf.org Subject: [Dime] Comments on RFC3588bis Hi all, =20 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. =20 Take the definitions in section 1.3 for example. =20 " Diameter Client =20 A Diameter Client is a device at the edge of the network that performs access control. ... ... =20 Diameter Server=20 =20 A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. ..." =20 For an non-AAA application, these defintions are not precise at all.=20 =20 =20 Best Regards, Fortune =20 ------_=_NextPart_001_01C99A7E.75639041 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Fortune,
 
RFC 3588 Abstract starts with:=20
 
> The Diameter base protocol is intended to provide = an=20 Authentication,
   Authorization and Accounting (AAA) = framework for=20 applications such as
   network access or IP mobility.=20
 
DIME is chartered with extending Diameter within = the scope of=20 3588 and not beyond.  Non-AAA applications are beyond the scope.=20
 
I read the phrase that you quote from the DIME charter as = allowing to=20 consider applications other than IP telephony and LAN AAA, but you still = need to=20 be within the scope of RFC 3588.
 
If you want to discuss further extensions of the = scope of=20 Diameter you need a WG rechartering or another=20 WG. 
 
Regards,
 
Dan
 
 
 

From: Fortune HUANG=20 [mailto:fqhuang@huawei.com]
Sent: Sunday, March 01, 2009 = 4:49=20 PM
To: Romascanu, Dan (Dan); = dime@ietf.org
Subject: RE:=20 [Dime] Comments on RFC3588bis

Hi=20 Dan,

 

Thank you = very much=20 for your advice. But before moving forward with your guidance, please = allow me=20 ask you a question in order to get rid of my=20 doubt.

 

On the = website of the=20 DIME WG (i.e. http://www.ietf.org/html.charters/dime-charter.html), I = found=20 the following statement in the charter.

 

“The Diameter = Maintanence and Extensions WG will focus on maintenance and extensions = to the=20 Diameter protocol required to enable its use in applications such as = IP=20 telephony and Local Area Network authentication, authorization and=20 accounting.”

 

On reading = this=20 sentence, I think the AAA applications are only the example = applications for=20 DIME WG. I can’t find any clue that the non AAA applications are = outside the=20 scope of DIME WG.

Did I = understand the=20 charter incorrectly at this point? Or did I not get the right version = of the=20 charter? Thanks.

 

Best=20 Regards,

Fortune=20

 

 

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Sunday, March 01, 2009 = 10:04=20 PM
To: = Fortune = HUANG;=20 dime@ietf.org
Subject: RE:=20 [Dime] Comments on RFC3588bis

 

Hi=20 Fortune,

 

The=20 DIME working group is working under a charter that includes=20 maintenance and extensions of the Diameter base protocol for specific=20  AAA applications.

A=20 change in the scope of the Diameter base protocol seems to me to be = beyond=20 what the WG is chartered to do at this point in time. If you believe = that an=20 extension of the scope of Diameter is necessary you need to came with = a=20 separate proposal, as this looks like a change of charter or maybe the = charter=20 of another working group.

 

Dan

 

 

From: = dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf=20 Of Fortune=20 HUANG
Sent: Saturday, February 28, = 2009 11:51=20 AM
To:=20 dime@ietf.org
Subject:=20 [Dime] Comments on RFC3588bis

Hi all,

 

With the wide use in multiple = applications, I think=20 nowadays the Diameter protocol should not be considered as = only a AAA protocol. Many of the Diameter applications = have=20 nothing to do with the Authentication, Authorization and Accounting, = although the AAA applications are some of the important = applications.=20 Therefore, I propose we revise RFC3588bis to reflect this=20 fact.

 

Take the definitions in section 1.3 for=20 example.

 

"   Diameter = Client

 

      A Diameter = Client is=20 a device at the edge of the network = that
     =20 performs access control.  ...

...

 

Diameter Server=20

 

      A Diameter = Server is=20 one that handles authentication,
     =20 authorization and accounting requests for a particular realm. =20 ..."

 

For an non-AAA application, these = defintions are not=20 precise at all.

 

 

Best Regards,

Fortune

 

<= /BLOCKQUOTE> ------_=_NextPart_001_01C99A7E.75639041-- From Hannes.Tschofenig@gmx.net Sun Mar 1 07:16:56 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 D3A403A68F6 for ; Sun, 1 Mar 2009 07:16:56 -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.301, 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 TBut-BVRUoA4 for ; Sun, 1 Mar 2009 07:16:55 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0DB053A67F5 for ; Sun, 1 Mar 2009 07:16:54 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2009 15:17:18 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp058) with SMTP; 01 Mar 2009 16:17:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ULeAvdcFUmUCg5UrW/bP7jzRdqLCiC2dCWMf0Mj bXZNkTxFadj88r From: "Hannes Tschofenig" To: , , "'Romascanu, Dan \(Dan\)'" References: <07c701c99986$73684350$2ab5b70a@nsnintra.net> Date: Sun, 1 Mar 2009 17:18:18 +0200 Message-ID: <005c01c99a80$f420ee20$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <07c701c99986$73684350$2ab5b70a@nsnintra.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmZhnLBCottasOMTfm0ghEK2rc/lgA9JETQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Subject: Re: [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: Sun, 01 Mar 2009 15:16:56 -0000 Hi all, I just had a chat with Dan and he came up with the following alternative proposal. Instead of referencing draft-ietf-tsvwg-emergency-rsvp-11 normatively we reference it informatively. How can we make such a simple change? Well. We really only need a part of the registry in draft-ietf-tsvwg-emergency-rsvp-11. Then, we copy the text from the IANA consideration section that creates the numerical registry corresponding to the registry created by RFC 4412. Here are the necessary text changes: ---------- 3.5. Admission-Priority AVP The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. OLD: The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher priority. Section 3.1 of [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter) illustrates how these values are carried in RSVP. NEW: The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher priority. A given admission priority is encoded in this information element using the same value as when encoded in the Admission- Priority AVP defined in Section 3.1 of [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). 3.6. ALRP AVP The Application-Level Resource Priority (ALRP) AVP is a grouped AVP consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. OLD: A description of the semantic of the parameter values can be found in [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for parameter is as follows: NEW: A description of the semantic of the parameter values can be found in [RFC4412]. A description on how to carry the valus within RSVP is provided in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for parameter is as follows: ALRP ::= < AVP Header: TBD > { ALRP-Namespace } { ALRP-Priority } 3.6.1. ALRP-Namespace AVP The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. 3.6.2. ALRP-Priority AVP The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. OLD: [RFC4412] defines a resource priority header and established the initial registry. That registry was later extended by [I-D.ietf-tsvwg-emergency-rsvp]. NEW: [RFC4412] defines a resource priority header and established the corresponding registry. That registry was later converted to allow priorities to be expressed via numerical values by [I-D.ietf-tsvwg-emergency-rsvp]. ---------- ADD to the IANA consideration section: ---------- ALRP Namespace IANA already maintains the Resource-Priority Namespaces registry (under the SIP Parameters) listing all such namespace. However, that registry does not currently allocate a numerical value to each namespace. Hence, this document requests the IANA to extend the Resource-Priority Namespace registry in the following ways: o a new column should be added to the registry o the title of the new column should be "Namespace Numerical Value *" o in the Legend, add a line saying "Namespace Numerical Value = the unique numerical value identifying the namespace" o add a line at the bottom of the registry stating the following "* : [RFCXXX] " where XXX is the RFC number of the present document o allocate an actual numerical value to each namespace in the registry and state that value in the new "Namespace numerical Value *" column. A numerical value should be allocated immediately by IANA to all existing namespace. Then, in the future, IANA should automatically allocate a numerical value to any new namespace added to the registry. ALRP Priority IANA already maintains the Resource-Priority Priority-values registry (under the SIP Parameters) listing all such priorities. However, that registry does not currently allocate a numerical value to each priority-value. Hence, this document requests the IANA to extend the Resource-Priority Priority-Values registry in the following ways: o for each namespace, the registry should be structured with two columns o the title of the first column should read "Priority Values (least to greatest)" o the first column should list all the values currently defined in the registry (e.g. for the drsn namespace: "routine", "priority", "immediate", "flash", "flash-override", "flash-override-override" for the drsn namespace) o the title of the second column should read "Priority Numerical Value *" o At the bottom of the registry, add a "Legend" with a line saying "Priority Numerical Value = the unique numerical value identifying the priority within a namespace" o add a line at the bottom of the registry stating the following "* : [RFCXXX] " where XXX is the RFC number of the present document o allocate an actual numerical value to each and state that value in the new "Priority Numerical Value *" column. A numerical value should be allocated immediately by IANA to all existing priority. Then, in the future, IANA should automatically allocate a numerical value to any new namespace added to the registry. The numerical value must be unique within each namespace. For the initial allocation, within each namespace, values should be allocated in decreasing order ending with 0 (so that the greatest priority is always allocated value 0). For example, in the drsn namespace, "routine" would be allocated numerical value 5 and "flash- override-override" would be allocated numerical value 0. ----- Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Hannes Tschofenig >Sent: 28 February, 2009 11:25 >To: dime@ietf.org >Subject: [Dime] Diameter QoS Parameter -- DECISION TO MAKE > >Hi all, > >we have a normative reference in the Diameter QoS parameter >draft >http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-paramet >ers-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. > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From Hannes.Tschofenig@gmx.net Sun Mar 1 11:38: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 39CED3A6844 for ; Sun, 1 Mar 2009 11:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 ge-97xum1lnd for ; Sun, 1 Mar 2009 11:38:46 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BF2DF3A6359 for ; Sun, 1 Mar 2009 11:38:45 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2009 19:39:08 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp054) with SMTP; 01 Mar 2009 20:39:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX193Lfon6yx3vRRZxAIoStRLKjUXsxwqagQvfoMho1 GX/SxWvgFufJxR From: "Hannes Tschofenig" To: "'ECRIT'" , "'KEYPROV'" , Date: Sun, 1 Mar 2009 21:40:04 +0200 Message-ID: <00ab01c99aa5$88024020$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: AcmYSIQ2rlgWDFaARwS44XtqzrJYLwCXO13g X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [Dime] FW: Initial Version I-D Submission Deadline Extended to March 4, 2009 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, 01 Mar 2009 19:38:47 -0000 FYI; more time in case you work on new documents. Ciao Hannes >-----Original Message----- >From: wgchairs-bounces@ietf.org >[mailto:wgchairs-bounces@ietf.org] On Behalf Of Alexa Morris >Sent: 26 February, 2009 21:28 >To: ietf-announce@ietf.org; ietf@ietf.org; wgchairs@ietf.org >Subject: Initial Version I-D Submission Deadline Extended to >March 4, 2009 > >The IESG has extended the deadline for initial version (00) >submissions of Internet Drafts by 2 days (48 hours). The new >deadline is March 4, 2009 at 1700 Pacific (March 5, 2009 at >0100 UTC / GMT) and the extension is for IETF 74 only. The >deadline has been extended due to the copyright legend text >alternative being recently finalized, approved and implemented. > >Please note that the date for updated I-D versions has NOT >been extended, and is still March 9, 2009. > >Regards, >Alexa > >----------- >Alexa Morris / Executive Director / IETF >48377 Fremont Blvd., Suite 117, Fremont, CA 94538 >Phone: +1.510.492.4089 / Fax: +1.510.492.4001 >Email: amorris@amsl.com > >Managed by Association Management Solutions (AMS) Forum >Management, Meeting and Event Planning www.amsl.com > > From fqhuang@huawei.com Sun Mar 1 17:06:38 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 AA1C03A6833 for ; Sun, 1 Mar 2009 17:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[AWL=1.599, 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 tQtyYIjkn80h for ; Sun, 1 Mar 2009 17:06:37 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 782583A681D for ; Sun, 1 Mar 2009 17:06:36 -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 <0KFU00561TREW2@szxga01-in.huawei.com> for dime@ietf.org; Mon, 02 Mar 2009 09:06:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFU00CCVTREWW@szxga01-in.huawei.com> for dime@ietf.org; Mon, 02 Mar 2009 09:06:50 +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 <0KFU00BNNTREAP@szxml04-in.huawei.com> for dime@ietf.org; Mon, 02 Mar 2009 09:06:50 +0800 (CST) Date: Mon, 02 Mar 2009 09:06:50 +0800 From: Fortune HUANG In-reply-to: <005c01c99a80$f420ee20$0201a8c0@nsnintra.net> To: 'Hannes Tschofenig' , dime@ietf.org, magnus.westerlund@ericsson.com, "'Romascanu, Dan (Dan)'" Message-id: <002d01c99ad3$2ae99d60$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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmZhnLBCottasOMTfm0ghEK2rc/lgA9JETQABTPjDA= Subject: Re: [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: Mon, 02 Mar 2009 01:06:38 -0000 Hi Hannes, I basically support your proposal of referencing referencing draft-ietf-tsvwg-emergency-rsvp-11 informatively in stead of normatively. My further question for clarification is: can we just provide a complete and precise definition to each AVP (e.g. at least what the AVP indicates) in the section where it is defined, without redirecting the reader to another document to get his own version of the definition? Best Regards, Fortune -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, March 01, 2009 11:18 PM To: dime@ietf.org; magnus.westerlund@ericsson.com; 'Romascanu, Dan (Dan)' Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE Hi all, I just had a chat with Dan and he came up with the following alternative proposal. Instead of referencing draft-ietf-tsvwg-emergency-rsvp-11 normatively we reference it informatively. How can we make such a simple change? Well. We really only need a part of the registry in draft-ietf-tsvwg-emergency-rsvp-11. Then, we copy the text from the IANA consideration section that creates the numerical registry corresponding to the registry created by RFC 4412. Here are the necessary text changes: ---------- 3.5. Admission-Priority AVP The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. OLD: The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher priority. Section 3.1 of [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter) illustrates how these values are carried in RSVP. NEW: The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher priority. A given admission priority is encoded in this information element using the same value as when encoded in the Admission- Priority AVP defined in Section 3.1 of [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). 3.6. ALRP AVP The Application-Level Resource Priority (ALRP) AVP is a grouped AVP consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. OLD: A description of the semantic of the parameter values can be found in [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for parameter is as follows: NEW: A description of the semantic of the parameter values can be found in [RFC4412]. A description on how to carry the valus within RSVP is provided in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for parameter is as follows: ALRP ::= < AVP Header: TBD > { ALRP-Namespace } { ALRP-Priority } 3.6.1. ALRP-Namespace AVP The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. 3.6.2. ALRP-Priority AVP The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. OLD: [RFC4412] defines a resource priority header and established the initial registry. That registry was later extended by [I-D.ietf-tsvwg-emergency-rsvp]. NEW: [RFC4412] defines a resource priority header and established the corresponding registry. That registry was later converted to allow priorities to be expressed via numerical values by [I-D.ietf-tsvwg-emergency-rsvp]. ---------- ADD to the IANA consideration section: ---------- ALRP Namespace IANA already maintains the Resource-Priority Namespaces registry (under the SIP Parameters) listing all such namespace. However, that registry does not currently allocate a numerical value to each namespace. Hence, this document requests the IANA to extend the Resource-Priority Namespace registry in the following ways: o a new column should be added to the registry o the title of the new column should be "Namespace Numerical Value *" o in the Legend, add a line saying "Namespace Numerical Value = the unique numerical value identifying the namespace" o add a line at the bottom of the registry stating the following "* : [RFCXXX] " where XXX is the RFC number of the present document o allocate an actual numerical value to each namespace in the registry and state that value in the new "Namespace numerical Value *" column. A numerical value should be allocated immediately by IANA to all existing namespace. Then, in the future, IANA should automatically allocate a numerical value to any new namespace added to the registry. ALRP Priority IANA already maintains the Resource-Priority Priority-values registry (under the SIP Parameters) listing all such priorities. However, that registry does not currently allocate a numerical value to each priority-value. Hence, this document requests the IANA to extend the Resource-Priority Priority-Values registry in the following ways: o for each namespace, the registry should be structured with two columns o the title of the first column should read "Priority Values (least to greatest)" o the first column should list all the values currently defined in the registry (e.g. for the drsn namespace: "routine", "priority", "immediate", "flash", "flash-override", "flash-override-override" for the drsn namespace) o the title of the second column should read "Priority Numerical Value *" o At the bottom of the registry, add a "Legend" with a line saying "Priority Numerical Value = the unique numerical value identifying the priority within a namespace" o add a line at the bottom of the registry stating the following "* : [RFCXXX] " where XXX is the RFC number of the present document o allocate an actual numerical value to each and state that value in the new "Priority Numerical Value *" column. A numerical value should be allocated immediately by IANA to all existing priority. Then, in the future, IANA should automatically allocate a numerical value to any new namespace added to the registry. The numerical value must be unique within each namespace. For the initial allocation, within each namespace, values should be allocated in decreasing order ending with 0 (so that the greatest priority is always allocated value 0). For example, in the drsn namespace, "routine" would be allocated numerical value 5 and "flash- override-override" would be allocated numerical value 0. ----- Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >Hannes Tschofenig >Sent: 28 February, 2009 11:25 >To: dime@ietf.org >Subject: [Dime] Diameter QoS Parameter -- DECISION TO MAKE > >Hi all, > >we have a normative reference in the Diameter QoS parameter draft >http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-paramet >ers-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. > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From vfajardo@tari.toshiba.com Mon Mar 2 06:29: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 44F4C3A6821; Mon, 2 Mar 2009 06:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A49Lhyb5WOs; Mon, 2 Mar 2009 06:29:41 -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 C71C53A69FC; Mon, 2 Mar 2009 06:28:34 -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 n22EOE7O043340; Mon, 2 Mar 2009 09:24:14 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49AC9EF5.5060508@tari.toshiba.com> Date: Mon, 02 Mar 2009 22:07:33 -0500 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: OPS ADs , IETF-IESG-Support via RT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: [Dime] PROTO Writeup for 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, 02 Mar 2009 14:29:45 -0000 PROTO WRITEUP for draft-ietf-dime-qos-attributes-11.txt ======================================================= (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Victor Fajardo. I have personally reviewed the document and I believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document defines a set of QoS related AVPs that a Diameter application can use to signal QoS rules and parameters. It is intended to replace the IPFilterRule AVP defined in RFC3588 and therefore has received extensive review within the WG. It has also been review by members of TSVWG, interested SDOs requiring Diameter based QoS signaling as well as folks with in-depth QoS experience. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with this document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns with this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus in the WG behind the document. The problem space is well understood and the solution is acceptable to the WG, as well as other interested SDOs. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There is no opposition to this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has been split into normative and informative references. There are no normative references that are work in progress. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document has an IANA considerations section that is consistent with the body. The document only request allocations of AVP codes in the IETF namespace. Following RFC 3588, IETF consensus is required for the block allocations needed in this doc. The consensus process given to this doc by the DIME WG serves as consensus for IANA allocation requirements. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains ABNF rules specified in RFC 3588. The ABNF content has been validated. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies a set of AVPs that is used to carry QoS rules and parameters so that a Diameteter application that needs QoS support can signal them. Information contained in these AVPs are to be interpreted and consumed by QoS classifying entities. The Rule-Set AVP is intended to replace the IPFilterRule AVP defined in RFC 3588. It provides a clear and more extensible format than the original text based approach provided by IPFilterRule. The AVPs defined in this document are designed to be general enough to fit both PUSH and PULL QoS signalling models. The document provides examples on how both models are accomplished using existing Diameter applications. Working Group Summary There was consensus in the WG to publish the document. Document Quality The document has been sent for review to TSVWG and RADEXT. This document defines a core component of a Network Operators QoS architecture and thus have gone through a long review process both within DIME WG and outside of it. It has also traversed several re-start iteration before its current acceptable state. Personnel Victor Fajardo is the document shepherd for this document. From avi@bridgewatersystems.com Mon Mar 2 13:41: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 336433A68CD for ; Mon, 2 Mar 2009 13:41:05 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1SgpBlJeYMn for ; Mon, 2 Mar 2009 13:41:04 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 25C863A67F3 for ; Mon, 2 Mar 2009 13:41:04 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Mon, 2 Mar 2009 16:41:29 -0500 From: Avi Lior To: "jouni.nospam@gmail.com" , "Lionel.morand@orange-ftgroup.com" , Mark Jones , "tena@huawei.com" Date: Mon, 2 Mar 2009 16:41:28 -0500 Thread-Topic: Dime NAI Routing Thread-Index: Acmbf6SLY3h74xbtRZa+ByDyRI10kg== Message-ID: <8A8CFE8F89C38B41A749C19328C76D6308CE370C8D@exchange02.bridgewatersys.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_8A8CFE8F89C38B41A749C19328C76D6308CE370C8Dexchange02bri_" MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: [Dime] Dime NAI Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:41:05 -0000 --_000_8A8CFE8F89C38B41A749C19328C76D6308CE370C8Dexchange02bri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A couple of comments: 1) The draft should mention something about the presence of Destination-Ho= st AVP. The rule for routing is that the Destination-Host AVP is not looked at unti= l the message reaches the terminal realm as determined by the decorated NAI= . 2) I dont like the way Destination-Realm is being used. The draft states that the destination realm is updated on a hop by hop basi= s together with the decorated NAI. If an intermediary is not compliant with the scheme presented by this draft= it will result in the intermediary consuming the message locally - since t= he message contains the destination realm equal to its realm. Thus the me= ssage is not going to reach the destination. Instead, I propose that the destination realm should be always set to the t= erminal realm, thus: Agents that are compliant with the draft will first look at the NAI to dete= rmine whether the packet has reached the terminal realm or where it should = be routed next; Agents that are not compatible with the draft will use the old rules for ro= uting and would route the message according to the destination-realm only a= nd thus the message will reach the final destintaion albeit not necessarily= according to the decorated NAI. But at least it would work. Did I miss anything? --_000_8A8CFE8F89C38B41A749C19328C76D6308CE370C8Dexchange02bri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A coupl= e of=20 comments:
 
1) = ; The draft=20 should mention something about the presence of Destination-Host=20 AVP.
 
The rul= e for=20 routing is that the Destination-Host AVP is not looked at until the message= =20 reaches the terminal realm as determined by the decorated=20 NAI.
 
2) I do= nt like the=20 way Destination-Realm is being used.
 
The dra= ft states=20 that the destination realm is updated on a hop by hop basis together with t= he=20 decorated NAI.
 
I= f an=20 intermediary is not compliant with the scheme presented by this draft it wi= ll=20 result in the intermediary consuming the message locally - since the messag= e=20 contains the destination realm equal to its realm.   Thus the message is not going to reach th= e=20 destination.
 
Instead= , I propose=20 that the destination realm should be always set to the terminal realm,=20 thus:
 
Agents = that are=20 compliant with the draft will first look at the NAI to determine whether th= e=20 packet has reached the terminal realm or where it should be routed=20 next;
 
Agents = that are=20 not compatible with the draft will use the old rules for routing and would = route=20 the message according to the destination-realm only and thus the message wi= ll=20 reach the final destintaion albeit not necessarily according to the decorat= ed=20 NAI. But at least it would work.
 
 
Did I m= iss=20 anything?
 
 
--_000_8A8CFE8F89C38B41A749C19328C76D6308CE370C8Dexchange02bri_-- From venugr.k@gmail.com Mon Mar 2 17:51:11 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 A8D4A3A6999 for ; Mon, 2 Mar 2009 17:51:11 -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_32=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 W4IacgYFK5DD for ; Mon, 2 Mar 2009 17:51:11 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id EA0443A690B for ; Mon, 2 Mar 2009 17:51:10 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2909686wfd.31 for ; Mon, 02 Mar 2009 17:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=5Nwg6oJ8Yb3Md03XKjkDI3hpYghL3GJMC1j6pEx4nVw=; b=FY79x0Lv9RgWAO2ZCrDNVhBPzxvc7iefOeUhyjQnh87xklzDtyNvxu2Wo4vvRZHIOC iVMXQgHtLCfSjGHSMXddp4BAJ3mcAGPyn1b1T3Aa+nCl/M8lfcdaWHIv48MQk+dimGtc 3t2ly2XOUTiIptlcXr0wKJQ81PJKOn0idavss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ihz5nzNbpEbOA1khDc4k9EXFpSVC5vnEX7K0wPIymvnIAP7bkLQEwruYbcUVHmIoeO T7n4ugzyf6swBZGXw4eev8aZVG6hEtjKiwgmpCtOo2sBJdG0YyW/WmuiMCgAZ7FrVxtv 6yJ90e1FnfIc6Q0s2aImHyDFWRzcwuEeyelmE= MIME-Version: 1.0 Received: by 10.142.51.4 with SMTP id y4mr3324478wfy.199.1236045097463; Mon, 02 Mar 2009 17:51:37 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Mar 2009 07:21:37 +0530 Message-ID: From: Venu K To: dime@ietf.org Content-Type: multipart/alternative; boundary=000e0cd20d86f5ef7304642d2c22 Subject: Re: [Dime] DiME Digest, Vol 33, Issue 21 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, 03 Mar 2009 01:51:11 -0000 --000e0cd20d86f5ef7304642d2c22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Experts, Is there a way to co-relate PNR to corresponding SNR,or is there a way to pass information in SNR andd that is returned back when in PNR is being sent from HSS. for eg: inrequest response scenario a Proxy-Info avp in a request is returned in the response. Regards, Venu --000e0cd20d86f5ef7304642d2c22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Experts,

Is there a way to co-relate=A0 PNR to corresponding S= NR,or is there a way to pass information in SNR andd that is returned back = when in PNR is being sent from HSS.

for eg: inrequest response scena= rio a Proxy-Info=A0 avp in a request is returned in the response.


Regards,
Venu
--000e0cd20d86f5ef7304642d2c22-- From venugr.k@gmail.com Mon Mar 2 21:23:34 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 24F113A6A1F for ; Mon, 2 Mar 2009 21:23:34 -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_32=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 AsoAlZ1Y44kL for ; Mon, 2 Mar 2009 21:23:33 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 8A46C3A6808 for ; Mon, 2 Mar 2009 21:23:33 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3000649wfd.31 for ; Mon, 02 Mar 2009 21:24:00 -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=cLYK/I6t98tquUrrPGoeaIf8LTbsPjdp1KJjsxlrXc0=; b=BvoDzqoHIXfevUOgsUXaMNB475pvTeEVVRh2vFMjQTquOSomJ363zUk2QGFJ/TPR1m gLh8yxBcqbvVpP/ZlOx4tHHWuHn1YHFekWTqs0LUnibHlfGcQwAtS+nRHyeYiJ4kXvRd 2mO3gxEOy3dPWn2T0e3JWedz8oZ8QxmaEKgHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oVy7/8c6Zr4cOGdWFaOblcMtenn4L/IADC1XYFMkAienwzi2nAp6FN5dvpfYWlNNeq B3K8OOUvsHI0TDDtsv+KfgDAHdjTLle28h1ymGxG1Kskib9YQ00PTCPFvc9LVjytovB1 /eScqiP6eflstbQRNV6d/2UnYxHgJc7WJEmbs= MIME-Version: 1.0 Received: by 10.142.144.16 with SMTP id r16mr3410280wfd.214.1236057840271; Mon, 02 Mar 2009 21:24:00 -0800 (PST) Date: Tue, 3 Mar 2009 10:53:59 +0530 Message-ID: From: Venu K To: dime@ietf.org Content-Type: multipart/alternative; boundary=000e0cd327467dc0fd046430248e Subject: [Dime] Co-relate PNR to SNR 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, 03 Mar 2009 05:23:34 -0000 --000e0cd327467dc0fd046430248e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Experts, Is there a way to co-relate PNR to corresponding SNR,or is there a way to pass information in SNR andd that is returned back when in PNR is being sent from HSS. for eg: inrequest response scenario a Proxy-Info avp in a request is returned in the response. Regards, Venu --000e0cd327467dc0fd046430248e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Experts,

Is there a way to co-relate=A0 PNR to corresponding SNR,or is there a way to pass information in SNR andd that is returned back when in PNR is being sent from HSS.

for eg: inrequest response = scenario a Proxy-Info=A0 avp in a request is returned in the response.


Regards,
Venu --000e0cd327467dc0fd046430248e-- From hannes.tschofenig@nsn.com Mon Mar 2 21:47: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 022BD3A6B28 for ; Mon, 2 Mar 2009 21:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.729 X-Spam-Level: X-Spam-Status: No, score=-3.729 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vOmLS8RYjCC for ; Mon, 2 Mar 2009 21:47:40 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F1C7B3A6B2C for ; Mon, 2 Mar 2009 21:47:39 -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 n235laMe013942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2009 06:47:36 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n235lZMx025608; Tue, 3 Mar 2009 06:47:36 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 06:47:35 +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: Tue, 3 Mar 2009 07:47:35 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45011B062A@FIESEXC015.nsn-intra.net> In-Reply-To: <002d01c99ad3$2ae99d60$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Parameter -- DECISION TO MAKE Thread-Index: AcmZhnLBCottasOMTfm0ghEK2rc/lgA9JETQABTPjDAAKe36wA== References: <005c01c99a80$f420ee20$0201a8c0@nsnintra.net> <002d01c99ad3$2ae99d60$7b27460a@china.huawei.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Fortune HUANG" , "Hannes Tschofenig" , , , "Romascanu,Dan (Dan)" X-OriginalArrivalTime: 03 Mar 2009 05:47:35.0340 (UTC) FILETIME=[8D9A56C0:01C99BC3] Subject: Re: [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: Tue, 03 Mar 2009 05:47:42 -0000 Hi Fortune,=20 > Hi Hannes, > >I basically support your proposal of referencing referencing >draft-ietf-tsvwg-emergency-rsvp-11 informatively in stead of=20 >normatively. Thanks for your feedback.=20 >My further question for clarification is: can we just provide=20 >a complete and precise definition to each AVP (e.g. at least=20 >what the AVP indicates) in the section where it is defined,=20 >without redirecting the reader to another document to get his=20 >own version of the definition?=20 I am very reluctant to copy-and-paste text from other RFCs into this document just to avoid having the reader to fetch other documents. So far, in all our documents, we have tried to avoid duplication as much as possible.=20 Ciao Hannes >Best Regards, >Fortune > >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >Behalf Of Hannes Tschofenig >Sent: Sunday, March 01, 2009 11:18 PM >To: dime@ietf.org; magnus.westerlund@ericsson.com; 'Romascanu,=20 >Dan (Dan)' >Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE > >Hi all,=20 > >I just had a chat with Dan and he came up with the following=20 >alternative proposal.=20 > >Instead of referencing draft-ietf-tsvwg-emergency-rsvp-11=20 >normatively we reference it informatively. How can we make=20 >such a simple change? Well. We really only need a part of the=20 >registry in draft-ietf-tsvwg-emergency-rsvp-11. >Then, we copy the text from the IANA consideration section=20 >that creates the numerical registry corresponding to the=20 >registry created by RFC 4412.=20 > >Here are the necessary text changes:=20 > >---------- > >3.5. Admission-Priority AVP > > The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. > >OLD:=20 > > The admission control priority of the flow, in terms of access to > network bandwidth in order to provide higher probability of call > completion to selected flows. Higher values represent higher > priority. Section 3.1 of > [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter) > illustrates how these values are carried in RSVP.=20 > >NEW:=20 > > The admission control priority of the flow, in terms of access to > network bandwidth in order to provide higher probability of call > completion to selected flows. Higher values represent higher > priority. A given admission priority is encoded in this information > element using the same value as when encoded in the Admission- > Priority AVP defined in Section 3.1 of > [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). > >3.6. ALRP AVP > > The Application-Level Resource Priority (ALRP) AVP is a grouped AVP > consisting of two AVPs, the ALRP-Namespace and the=20 >ALRP-Priority AVP. > >OLD: > > A description of the semantic of the parameter values can=20 >be found in > [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for > parameter is as follows: > >NEW:=20 > > A description of the semantic of the parameter values can=20 >be found in > [RFC4412]. A description on how to carry the valus within RSVP is=20 > provided in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for > parameter is as follows: > > ALRP ::=3D < AVP Header: TBD > > { ALRP-Namespace } > { ALRP-Priority } > >3.6.1. ALRP-Namespace AVP > > The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. > >3.6.2. ALRP-Priority AVP > > The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. > >OLD: > > [RFC4412] defines a resource priority header and established the > initial registry. That registry was later extended by > [I-D.ietf-tsvwg-emergency-rsvp]. > >NEW:=20 > > [RFC4412] defines a resource priority header and established the > corresponding registry. That registry was later converted=20 > to allow priorities to be expressed via numerical values by > [I-D.ietf-tsvwg-emergency-rsvp]. > >---------- > >ADD to the IANA consideration section:=20 > > >---------- > >ALRP Namespace > > IANA already maintains the > Resource-Priority Namespaces registry (under the SIP Parameters) > listing all such namespace. However, that registry does not > currently allocate a numerical value to each namespace. Hence, this > document requests the IANA to extend the Resource-Priority Namespace > registry in the following ways: > > o a new column should be added to the registry > > o the title of the new column should be "Namespace Numerical Value > *" > > o in the Legend, add a line saying "Namespace Numerical Value =3D = the > unique numerical value identifying the namespace" > > o add a line at the bottom of the registry stating the following "* > : [RFCXXX] " where XXX is the RFC number of the present document > > o allocate an actual numerical value to each namespace in the > registry and state that value in the new "Namespace numerical > Value *" column. > > A numerical value should be allocated immediately by IANA to all > existing namespace. Then, in the future, IANA should automatically > allocate a numerical value to any new namespace added to the > registry. > >ALRP Priority > > IANA already maintains the Resource-Priority > Priority-values registry (under the SIP Parameters) listing all such > priorities. However, that registry does not currently allocate a > numerical value to each priority-value. Hence, this document > requests the IANA to extend the Resource-Priority Priority-Values > registry in the following ways: > > o for each namespace, the registry should be structured with two > columns > > o the title of the first column should read "Priority Values (least > to greatest)" > > o the first column should list all the values currently defined in > the registry (e.g. for the drsn namespace: "routine", "priority", > "immediate", "flash", "flash-override", "flash-override-override" > for the drsn namespace) > > o the title of the second column should read "Priority Numerical > Value *" > > o At the bottom of the registry, add a "Legend" with a line saying > "Priority Numerical Value =3D the unique numerical value=20 >identifying > the priority within a namespace" > > o add a line at the bottom of the registry stating the following "* > : [RFCXXX] " where XXX is the RFC number of the present document > > o allocate an actual numerical value to each and state=20 >that value in > the new "Priority Numerical Value *" column. > > A numerical value should be allocated immediately by IANA to all > existing priority. Then, in the future, IANA should automatically > allocate a numerical value to any new namespace added to the > registry. The numerical value must be unique within each namespace. > For the initial allocation, within each namespace, values should be > allocated in decreasing order ending with 0 (so that the greatest > priority is always allocated value 0). For example, in the drsn > namespace, "routine" would be allocated numerical value 5=20 >and "flash- > override-override" would be allocated numerical value 0. > >----- > > >Ciao >Hannes > > >=20 > >>-----Original Message----- >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >Behalf Of=20 >>Hannes Tschofenig >>Sent: 28 February, 2009 11:25 >>To: dime@ietf.org >>Subject: [Dime] Diameter QoS Parameter -- DECISION TO MAKE >> >>Hi all, >> >>we have a normative reference in the Diameter QoS parameter draft=20 >>http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-paramet >>ers-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=20 >>draft-ietf-tsvwg-emergency-rsvp-11.txt is having a lot of problems=20 >>getting through the IESG and the document bounced back to the working=20 >>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=20 >>Diameter QoS parameter document as it will be blocked (for=20 >potentially=20 >>a long time). >>Since the Diameter QoS attribute and the Diameter QoS application=20 >>document normatively depend on the QoS parameter document=20 >they will be=20 >>blocked as well. >> >>So, I have been thinking of what we could do to deal with this issue=20 >>and here is a proposal to the group. >> >>*************** >>My proposal is to move the priority parameters (Priority AVP,=20 >>Admission-Priority AVP, and ALRP AVP) into a separate document and to=20 >>progress them independently to get the main part of the Diameter QoS=20 >>parameters document finalized. >>*************** >> >>Please let me know if you find this idea acceptable. Please=20 >respond as=20 >>quickly as possible! >> >>Ciao >>Hannes >> >>PS: We would have to find an editor and authors for that the new=20 >>document that contains the priority parameters but we can worry about=20 >>that part larter. >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www.ietf.org/mailman/listinfo/dime >> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From jouni.nospam@gmail.com Tue Mar 3 00:07:36 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 6A62528C112 for ; Tue, 3 Mar 2009 00:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, 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 x8BpZ-W+5SC3 for ; Tue, 3 Mar 2009 00:07:35 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 1FC5A28C0F2 for ; Tue, 3 Mar 2009 00:07:34 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so529193eya.31 for ; Tue, 03 Mar 2009 00:08:01 -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=AkB9aQomK7GLko+0WQiJYcy1L7ucFOwyjygmXHxPceA=; b=sAEyQQKLVAGzqGUZRbLgi+vlpwsIfEUItjEiFyyt7kQvgdfM85V2lb55hTZLP2wlmH VSTpjzAs4a68SkclxE01rR/v6DBtUTGIfyljo4Z0Hekylpc4QMlbqBE4anA6GRJRCzUJ 7PfHNfOWMAQX2miO6uu/pw72c++QNnoi1K/B4= 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=OCYxr19/fgclw4qcJoQBfmrO5qXo0K+uNR2Yv4ESAWVXP7HhyA6az3g+zd9ciTY0Zy h4d99nmt/pwjpg/pm6un7ZNrWryY1OplU2ZqMsosTVLJtkm3iXxC/dhpNAZDQe+iprie JTkVyj+qn4HfdBlhetZUUt+RsCACsjamLr3ds= Received: by 10.216.4.80 with SMTP id 58mr52076wei.173.1236067681064; Tue, 03 Mar 2009 00:08:01 -0800 (PST) Received: from ?10.183.181.9? ([192.100.124.156]) by mx.google.com with ESMTPS id 5sm5990907eyf.42.2009.03.03.00.08.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Mar 2009 00:08:00 -0800 (PST) Message-Id: <72D5BF85-3093-4781-99CD-9ABC5FAE12E2@gmail.com> From: jouni korhonen To: Hannes Tschofenig In-Reply-To: <07c701c99986$73684350$2ab5b70a@nsnintra.net> 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: Tue, 3 Mar 2009 10:07:58 +0200 References: <07c701c99986$73684350$2ab5b70a@nsnintra.net> X-Mailer: Apple Mail (2.930.3) Cc: dime@ietf.org Subject: Re: [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: Tue, 03 Mar 2009 08:07:36 -0000 Hi all, I would support removing as well. Be done with it and move on with the QoS parameter document. Those features that were in the tsvwg document can be documented later in a separate document, when and if needed. Cheers, Jouni On Feb 28, 2009, at 11:25 AM, Hannes Tschofenig wrote: > 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. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From fqhuang@huawei.com Tue Mar 3 00:21: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 36E9328C10D for ; Tue, 3 Mar 2009 00:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.259 X-Spam-Level: * X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEpV9YJ8fIpP for ; Tue, 3 Mar 2009 00:21:57 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 84AD43A6938 for ; Tue, 3 Mar 2009 00:21:56 -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 <0KFX00CKC8L0RL@szxga01-in.huawei.com> for dime@ietf.org; Tue, 03 Mar 2009 16:22:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFX0060D8L019@szxga01-in.huawei.com> for dime@ietf.org; Tue, 03 Mar 2009 16:22:12 +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 <0KFX00DU68L08B@szxml04-in.huawei.com> for dime@ietf.org; Tue, 03 Mar 2009 16:22:12 +0800 (CST) Date: Tue, 03 Mar 2009 16:22:12 +0800 From: Fortune HUANG In-reply-to: <3D3C75174CB95F42AD6BCC56E5555B45011B062A@FIESEXC015.nsn-intra.net> To: "'Tschofenig, Hannes (NSN - FI/Espoo)'" , 'Hannes Tschofenig' , dime@ietf.org, magnus.westerlund@ericsson.com, "'Romascanu, Dan (Dan)'" Message-id: <006b01c99bd9$27290ce0$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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmZhnLBCottasOMTfm0ghEK2rc/lgA9JETQABTPjDAAKe36wAAXy3Qw Subject: Re: [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: Tue, 03 Mar 2009 08:21:58 -0000 Hi Hannes, But I still think at least we should provide a brief statement about what the AVP indicates. And I also would like to have the detailed location of the relevant reference in this draft because it would be painful to go over another RFC just for the meaning of one AVP. Best Regards, Fortune -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] Sent: Tuesday, March 03, 2009 1:48 PM To: ext Fortune HUANG; Hannes Tschofenig; dime@ietf.org; magnus.westerlund@ericsson.com; Romascanu,Dan (Dan) Subject: RE: [Dime] Diameter QoS Parameter -- DECISION TO MAKE Hi Fortune, > Hi Hannes, > >I basically support your proposal of referencing referencing >draft-ietf-tsvwg-emergency-rsvp-11 informatively in stead of >normatively. Thanks for your feedback. >My further question for clarification is: can we just provide a >complete and precise definition to each AVP (e.g. at least what the AVP >indicates) in the section where it is defined, without redirecting the >reader to another document to get his own version of the definition? I am very reluctant to copy-and-paste text from other RFCs into this document just to avoid having the reader to fetch other documents. So far, in all our documents, we have tried to avoid duplication as much as possible. Ciao Hannes >Best Regards, >Fortune > >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >Hannes Tschofenig >Sent: Sunday, March 01, 2009 11:18 PM >To: dime@ietf.org; magnus.westerlund@ericsson.com; 'Romascanu, Dan >(Dan)' >Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE > >Hi all, > >I just had a chat with Dan and he came up with the following >alternative proposal. > >Instead of referencing draft-ietf-tsvwg-emergency-rsvp-11 >normatively we reference it informatively. How can we make such a >simple change? Well. We really only need a part of the registry in >draft-ietf-tsvwg-emergency-rsvp-11. >Then, we copy the text from the IANA consideration section that creates >the numerical registry corresponding to the registry created by RFC >4412. > >Here are the necessary text changes: > >---------- > >3.5. Admission-Priority AVP > > The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. > >OLD: > > The admission control priority of the flow, in terms of access to > network bandwidth in order to provide higher probability of call > completion to selected flows. Higher values represent higher > priority. Section 3.1 of > [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter) > illustrates how these values are carried in RSVP. > >NEW: > > The admission control priority of the flow, in terms of access to > network bandwidth in order to provide higher probability of call > completion to selected flows. Higher values represent higher > priority. A given admission priority is encoded in this information > element using the same value as when encoded in the Admission- > Priority AVP defined in Section 3.1 of > [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). > >3.6. ALRP AVP > > The Application-Level Resource Priority (ALRP) AVP is a grouped AVP > consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority >AVP. > >OLD: > > A description of the semantic of the parameter values can be found >in > [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for > parameter is as follows: > >NEW: > > A description of the semantic of the parameter values can be found >in > [RFC4412]. A description on how to carry the valus within RSVP is > provided in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for > parameter is as follows: > > ALRP ::= < AVP Header: TBD > > { ALRP-Namespace } > { ALRP-Priority } > >3.6.1. ALRP-Namespace AVP > > The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. > >3.6.2. ALRP-Priority AVP > > The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. > >OLD: > > [RFC4412] defines a resource priority header and established the > initial registry. That registry was later extended by > [I-D.ietf-tsvwg-emergency-rsvp]. > >NEW: > > [RFC4412] defines a resource priority header and established the > corresponding registry. That registry was later converted > to allow priorities to be expressed via numerical values by > [I-D.ietf-tsvwg-emergency-rsvp]. > >---------- > >ADD to the IANA consideration section: > > >---------- > >ALRP Namespace > > IANA already maintains the > Resource-Priority Namespaces registry (under the SIP Parameters) > listing all such namespace. However, that registry does not > currently allocate a numerical value to each namespace. Hence, this > document requests the IANA to extend the Resource-Priority Namespace > registry in the following ways: > > o a new column should be added to the registry > > o the title of the new column should be "Namespace Numerical Value > *" > > o in the Legend, add a line saying "Namespace Numerical Value = the > unique numerical value identifying the namespace" > > o add a line at the bottom of the registry stating the following "* > : [RFCXXX] " where XXX is the RFC number of the present document > > o allocate an actual numerical value to each namespace in the > registry and state that value in the new "Namespace numerical > Value *" column. > > A numerical value should be allocated immediately by IANA to all > existing namespace. Then, in the future, IANA should automatically > allocate a numerical value to any new namespace added to the > registry. > >ALRP Priority > > IANA already maintains the Resource-Priority > Priority-values registry (under the SIP Parameters) listing all such > priorities. However, that registry does not currently allocate a > numerical value to each priority-value. Hence, this document > requests the IANA to extend the Resource-Priority Priority-Values > registry in the following ways: > > o for each namespace, the registry should be structured with two > columns > > o the title of the first column should read "Priority Values (least > to greatest)" > > o the first column should list all the values currently defined in > the registry (e.g. for the drsn namespace: "routine", "priority", > "immediate", "flash", "flash-override", "flash-override-override" > for the drsn namespace) > > o the title of the second column should read "Priority Numerical > Value *" > > o At the bottom of the registry, add a "Legend" with a line saying > "Priority Numerical Value = the unique numerical value >identifying > the priority within a namespace" > > o add a line at the bottom of the registry stating the following "* > : [RFCXXX] " where XXX is the RFC number of the present document > > o allocate an actual numerical value to each and state that value >in > the new "Priority Numerical Value *" column. > > A numerical value should be allocated immediately by IANA to all > existing priority. Then, in the future, IANA should automatically > allocate a numerical value to any new namespace added to the > registry. The numerical value must be unique within each namespace. > For the initial allocation, within each namespace, values should be > allocated in decreasing order ending with 0 (so that the greatest > priority is always allocated value 0). For example, in the drsn > namespace, "routine" would be allocated numerical value 5 and >"flash- > override-override" would be allocated numerical value 0. > >----- > > >Ciao >Hannes > > > > >>-----Original Message----- >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of >>Hannes Tschofenig >>Sent: 28 February, 2009 11:25 >>To: dime@ietf.org >>Subject: [Dime] Diameter QoS Parameter -- DECISION TO MAKE >> >>Hi all, >> >>we have a normative reference in the Diameter QoS parameter draft >>http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-paramet >>ers-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. >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www.ietf.org/mailman/listinfo/dime >> > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From hannes.tschofenig@nsn.com Tue Mar 3 00:28:11 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 530FE3A68A7 for ; Tue, 3 Mar 2009 00:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, J_CHICKENPOX_93=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 RYvofEryN5W7 for ; Tue, 3 Mar 2009 00:28:10 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 88E8C3A6AA5 for ; Tue, 3 Mar 2009 00:28:09 -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 n238SAEu024267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2009 09:28:10 +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 n238SASo018675; Tue, 3 Mar 2009 09:28:10 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 09:28:10 +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: Tue, 3 Mar 2009 10:29:11 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45011B07FC@FIESEXC015.nsn-intra.net> In-Reply-To: <006b01c99bd9$27290ce0$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Parameter -- DECISION TO MAKE Thread-Index: AcmZhnLBCottasOMTfm0ghEK2rc/lgA9JETQABTPjDAAKe36wAAXy3QwAAEhKAA= References: <3D3C75174CB95F42AD6BCC56E5555B45011B062A@FIESEXC015.nsn-intra.net> <006b01c99bd9$27290ce0$7b27460a@china.huawei.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Fortune HUANG" , "Hannes Tschofenig" , , , "Romascanu,Dan (Dan)" X-OriginalArrivalTime: 03 Mar 2009 08:28:10.0409 (UTC) FILETIME=[FC8D3190:01C99BD9] Subject: Re: [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: Tue, 03 Mar 2009 08:28:11 -0000 Hi Fortune,=20 >Hi Hannes, > >But I still think at least we should provide a brief statement=20 >about what the AVP indicates. There is a brief statement about the AVPs in the beginning of the document.=20 >And I also would like to have=20 >the detailed location of the relevant reference in this draft=20 >because it would be painful to go over another RFC just for=20 >the meaning of one AVP. Well. This is somewhat difficult. Think about DiffServ Code Points.=20 Which part of what document would provide you the information you would like to know? Ciao Hannes PS: If we follow Jouni's suggestion then the reader has fewer documents to look at.=20 > >Best Regards, >Fortune > > >-----Original Message----- >From: Tschofenig, Hannes (NSN - FI/Espoo)=20 >[mailto:hannes.tschofenig@nsn.com] > >Sent: Tuesday, March 03, 2009 1:48 PM >To: ext Fortune HUANG; Hannes Tschofenig; dime@ietf.org;=20 >magnus.westerlund@ericsson.com; Romascanu,Dan (Dan) >Subject: RE: [Dime] Diameter QoS Parameter -- DECISION TO MAKE > >Hi Fortune,=20 > >> Hi Hannes, >> >>I basically support your proposal of referencing referencing >>draft-ietf-tsvwg-emergency-rsvp-11 informatively in stead of=20 >>normatively. > >Thanks for your feedback.=20 > >>My further question for clarification is: can we just provide a=20 >>complete and precise definition to each AVP (e.g. at least=20 >what the AVP >>indicates) in the section where it is defined, without =20 >redirecting the=20 >>reader to another document to get his own version of the definition? >I am very reluctant to copy-and-paste text from other RFCs=20 >into this document just to avoid having the reader to fetch=20 >other documents. So far, in all our documents, we have tried=20 >to avoid duplication as much as possible.=20 > >Ciao >Hannes > >>Best Regards, >>Fortune >> >>-----Original Message----- >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >Behalf Of=20 >>Hannes Tschofenig >>Sent: Sunday, March 01, 2009 11:18 PM >>To: dime@ietf.org; magnus.westerlund@ericsson.com; 'Romascanu, Dan=20 >>(Dan)' >>Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE >> >>Hi all, >> >>I just had a chat with Dan and he came up with the following=20 >>alternative proposal. >> >>Instead of referencing draft-ietf-tsvwg-emergency-rsvp-11 >>normatively we reference it informatively. How can we make such a=20 >>simple change? Well. We really only need a part of the registry in=20 >>draft-ietf-tsvwg-emergency-rsvp-11. >>Then, we copy the text from the IANA consideration section=20 >that creates=20 >>the numerical registry corresponding to the registry created by RFC=20 >>4412. >> >>Here are the necessary text changes:=20 >> >>---------- >> >>3.5. Admission-Priority AVP >> >> The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. >> >>OLD:=20 >> >> The admission control priority of the flow, in terms of access to >> network bandwidth in order to provide higher probability of call >> completion to selected flows. Higher values represent higher >> priority. Section 3.1 of >> [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter) >> illustrates how these values are carried in RSVP.=20 >> >>NEW:=20 >> >> The admission control priority of the flow, in terms of access to >> network bandwidth in order to provide higher probability of call >> completion to selected flows. Higher values represent higher >> priority. A given admission priority is encoded in this=20 >information >> element using the same value as when encoded in the Admission- >> Priority AVP defined in Section 3.1 of >> [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). >> >>3.6. ALRP AVP >> >> The Application-Level Resource Priority (ALRP) AVP is a grouped AVP >> consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority=20 >>AVP. >> >>OLD: >> >> A description of the semantic of the parameter values can be found=20 >>in >> [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for >> parameter is as follows: >> >>NEW:=20 >> >> A description of the semantic of the parameter values can be found=20 >>in >> [RFC4412]. A description on how to carry the valus within RSVP is=20 >> provided in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for >> parameter is as follows: >> >> ALRP ::=3D < AVP Header: TBD > >> { ALRP-Namespace } >> { ALRP-Priority } >> >>3.6.1. ALRP-Namespace AVP >> >> The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. >> >>3.6.2. ALRP-Priority AVP >> >> The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. >> >>OLD: >> >> [RFC4412] defines a resource priority header and established the >> initial registry. That registry was later extended by >> [I-D.ietf-tsvwg-emergency-rsvp]. >> >>NEW:=20 >> >> [RFC4412] defines a resource priority header and established the >> corresponding registry. That registry was later converted=20 >> to allow priorities to be expressed via numerical values by >> [I-D.ietf-tsvwg-emergency-rsvp]. >> >>---------- >> >>ADD to the IANA consideration section:=20 >> >> >>---------- >> >>ALRP Namespace >> >> IANA already maintains the >> Resource-Priority Namespaces registry (under the SIP Parameters) >> listing all such namespace. However, that registry does not >> currently allocate a numerical value to each namespace. =20 >Hence, this >> document requests the IANA to extend the Resource-Priority=20 >Namespace >> registry in the following ways: >> >> o a new column should be added to the registry >> >> o the title of the new column should be "Namespace Numerical Value >> *" >> >> o in the Legend, add a line saying "Namespace Numerical=20 >Value =3D the >> unique numerical value identifying the namespace" >> >> o add a line at the bottom of the registry stating the=20 >following "* >> : [RFCXXX] " where XXX is the RFC number of the present document >> >> o allocate an actual numerical value to each namespace in the >> registry and state that value in the new "Namespace numerical >> Value *" column. >> >> A numerical value should be allocated immediately by IANA to all >> existing namespace. Then, in the future, IANA should automatically >> allocate a numerical value to any new namespace added to the >> registry. >> >>ALRP Priority >> >> IANA already maintains the Resource-Priority >> Priority-values registry (under the SIP Parameters)=20 >listing all such >> priorities. However, that registry does not currently allocate a >> numerical value to each priority-value. Hence, this document >> requests the IANA to extend the Resource-Priority Priority-Values >> registry in the following ways: >> >> o for each namespace, the registry should be structured with two >> columns >> >> o the title of the first column should read "Priority=20 >Values (least >> to greatest)" >> >> o the first column should list all the values currently defined in >> the registry (e.g. for the drsn namespace: "routine",=20 >"priority", >> "immediate", "flash", "flash-override",=20 >"flash-override-override" >> for the drsn namespace) >> >> o the title of the second column should read "Priority Numerical >> Value *" >> >> o At the bottom of the registry, add a "Legend" with a line saying >> "Priority Numerical Value =3D the unique numerical value=20 >>identifying >> the priority within a namespace" >> >> o add a line at the bottom of the registry stating the=20 >following "* >> : [RFCXXX] " where XXX is the RFC number of the present document >> >> o allocate an actual numerical value to each and state that value=20 >>in >> the new "Priority Numerical Value *" column. >> >> A numerical value should be allocated immediately by IANA to all >> existing priority. Then, in the future, IANA should automatically >> allocate a numerical value to any new namespace added to the >> registry. The numerical value must be unique within each=20 >namespace. >> For the initial allocation, within each namespace, values should be >> allocated in decreasing order ending with 0 (so that the greatest >> priority is always allocated value 0). For example, in the drsn >> namespace, "routine" would be allocated numerical value 5 and >>"flash- >> override-override" would be allocated numerical value 0. >> >>----- >> >> >>Ciao >>Hannes >> >> >>=20 >> >>>-----Original Message----- >>>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >>Behalf Of >>>Hannes Tschofenig >>>Sent: 28 February, 2009 11:25 >>>To: dime@ietf.org >>>Subject: [Dime] Diameter QoS Parameter -- DECISION TO MAKE >>> >>>Hi all, >>> >>>we have a normative reference in the Diameter QoS parameter draft=20 >>>http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-paramet >>>ers-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=20 >>>draft-ietf-tsvwg-emergency-rsvp-11.txt is having a lot of problems=20 >>>getting through the IESG and the document bounced back to=20 >the working=20 >>>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=20 >>>Diameter QoS parameter document as it will be blocked (for >>potentially >>>a long time). >>>Since the Diameter QoS attribute and the Diameter QoS application=20 >>>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=20 >>>and here is a proposal to the group. >>> >>>*************** >>>My proposal is to move the priority parameters (Priority AVP,=20 >>>Admission-Priority AVP, and ALRP AVP) into a separate=20 >document and to=20 >>>progress them independently to get the main part of the Diameter QoS=20 >>>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=20 >>>document that contains the priority parameters but we can=20 >worry about=20 >>>that part larter. >>> >>>_______________________________________________ >>>DiME mailing list >>>DiME@ietf.org >>>https://www.ietf.org/mailman/listinfo/dime >>> >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www.ietf.org/mailman/listinfo/dime >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www.ietf.org/mailman/listinfo/dime >> > > From vfajardo@tari.toshiba.com Tue Mar 3 05:39:54 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 ABB3F3A69E7 for ; Tue, 3 Mar 2009 05:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vw6-ZKt2oDf for ; Tue, 3 Mar 2009 05:39:54 -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 B3C213A696E for ; Tue, 3 Mar 2009 05:39:53 -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 n23DZRvZ055460; Tue, 3 Mar 2009 08:35:27 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49AC6217.4080401@tari.toshiba.com> Date: Mon, 02 Mar 2009 17:47:51 -0500 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: jouni korhonen References: <07c701c99986$73684350$2ab5b70a@nsnintra.net> <72D5BF85-3093-4781-99CD-9ABC5FAE12E2@gmail.com> In-Reply-To: <72D5BF85-3093-4781-99CD-9ABC5FAE12E2@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [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: Tue, 03 Mar 2009 13:39:54 -0000 I agree. > Hi all, > > I would support removing as well. Be done with it and move on with the > QoS parameter document. Those features that were in the tsvwg document > can be documented later in a separate document, when and if needed. > > Cheers, > Jouni > > > On Feb 28, 2009, at 11:25 AM, Hannes Tschofenig wrote: > >> 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. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From dromasca@avaya.com Tue Mar 3 06:24:13 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 A8E7E3A696E for ; Tue, 3 Mar 2009 06:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 5KzTiq9shM0L for ; Tue, 3 Mar 2009 06:24:12 -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 B5DB03A6948 for ; Tue, 3 Mar 2009 06:24:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,296,1233550800"; d="scan'208";a="163359968" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Mar 2009 09:24:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Mar 2009 09:24:38 -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: Tue, 3 Mar 2009 15:24:17 +0100 Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45011B07FC@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Parameter -- DECISION TO MAKE Thread-Index: AcmZhnLBCottasOMTfm0ghEK2rc/lgA9JETQABTPjDAAKe36wAAXy3QwAAEhKAAADGmLMA== References: <3D3C75174CB95F42AD6BCC56E5555B45011B062A@FIESEXC015.nsn-intra.net> <006b01c99bd9$27290ce0$7b27460a@china.huawei.com> <3D3C75174CB95F42AD6BCC56E5555B45011B07FC@FIESEXC015.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Fortune HUANG" , "Hannes Tschofenig" , , Subject: Re: [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: Tue, 03 Mar 2009 14:24:13 -0000 =20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: Tuesday, March 03, 2009 10:29 AM > To: ext Fortune HUANG; Hannes Tschofenig; dime@ietf.org;=20 > magnus.westerlund@ericsson.com; Romascanu, Dan (Dan) > Subject: RE: [Dime] Diameter QoS Parameter -- DECISION TO MAKE >=20 > Hi Fortune,=20 >=20 > >Hi Hannes, > > > >But I still think at least we should provide a brief statement about=20 > >what the AVP indicates. >=20 > There is a brief statement about the AVPs in the beginning of=20 > the document.=20 >=20 > >And I also would like to have > >the detailed location of the relevant reference in this=20 > draft because=20 > >it would be painful to go over another RFC just for the=20 > meaning of one=20 > >AVP. >=20 > Well. This is somewhat difficult. Think about DiffServ Code Points.=20 > Which part of what document would provide you the information=20 > you would like to know? >=20 Actually I agree with Fortune on this. If I understand him well he is asking for a more exact pointer to the section in the referred documents (e.g. Section 7.3 in [RFC xxxx] instead of [RFC xxxx]). This is good practice and is possible in the majority of the cases. Even in the case of DSCP we can point to the section where the term is defined of first introduced.=20 Dan (speaking as a contributor) From glenzorn@comcast.net Tue Mar 3 13:18:21 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 B6B823A6A16 for ; Tue, 3 Mar 2009 13:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQr1YNyk9mE6 for ; Tue, 3 Mar 2009 13:18:21 -0800 (PST) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id E358E3A69F4 for ; Tue, 3 Mar 2009 13:18:20 -0800 (PST) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id NhsL1b02f0QkzPwA1lJpSk; Tue, 03 Mar 2009 21:18:49 +0000 Received: from gwzPC ([24.18.239.198]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id NlJn1b00b4HXf1k8NlJozc; Tue, 03 Mar 2009 21:18:48 +0000 From: "Glen Zorn" To: Date: Wed, 4 Mar 2009 04:18:45 +0700 Message-ID: <03b601c99c45$a31c57f0$e95507d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 content-language: en-us Thread-Index: AcmcRaJAsYcFpnulTcy1vEP28RtfjQ== Subject: [Dime] Problem with Origin- & Destination-Realm AVPs in 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: Tue, 03 Mar 2009 21:18:21 -0000 I'm pretty sure that I've mentioned this before, but the problematic definitions remain. The Origin-Realm & Destination-Realm AVPs are specified to be of type DiameterIdentity. This is plainly wrong, since DiameterIdentity is defined as an FQDN which is NOT the same as a Diameter realm. I think that it is _very_ important to fix this error in RFC 3588, rather than perpetuating it. ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From jouni.nospam@gmail.com Tue Mar 3 14:44: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 67FDE3A68F0 for ; Tue, 3 Mar 2009 14:44:02 -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 2eWcSm6XQM8L for ; Tue, 3 Mar 2009 14:44:01 -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 2AAD33A67FA for ; Tue, 3 Mar 2009 14:44:01 -0800 (PST) Received: by ewy25 with SMTP id 25so2539020ewy.37 for ; Tue, 03 Mar 2009 14:44:28 -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=AtiDCVC8ILkxHuKLjVxFrwRKJL1r5ESl+WLmAV9UmOo=; b=BScQxyNDpqe2F+r5epBjQ0NMWIr+fYhz7RSg87whaB/n7/IUhkyFsf7yRoAR4lcoAm r1kGc9aBenHoFlczHa2kJw9io2iN6oquq88MieN+TIa/56qOOiukFyWbuQcUdVuR/2j4 X+EyPEScHFIEFmDW8V+dS0fAmI1IFcADherUU= 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=fvp8BRMNz9Xc2khlDZ1/4ZB12wemcLMz3MZZx03ReuD3ypMj8ftwMVSnjfIj0gwvww vLv3JuhuQybprgX7F9y4Ro03xmW1mf6TUMhGICRwbXcMJn9nc0XFOOjgh6LOPri7kA/X EaXEK6b0fYm1/Gf3Zn0TvNXsRyoskCrJ9DV0I= Received: by 10.210.34.19 with SMTP id h19mr4753982ebh.89.1236120267979; Tue, 03 Mar 2009 14:44:27 -0800 (PST) Received: from a83-245-210-82.elisa-laajakaista.fi (a83-245-210-82.elisa-laajakaista.fi [83.245.210.82]) by mx.google.com with ESMTPS id 28sm445838eye.59.2009.03.03.14.44.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Mar 2009 14:44:27 -0800 (PST) Message-Id: <33E4FE18-7715-413B-A029-924F5A1070A2@gmail.com> From: jouni korhonen To: Avi Lior In-Reply-To: <8A8CFE8F89C38B41A749C19328C76D6308CE370C8D@exchange02.bridgewatersys.com> 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, 4 Mar 2009 00:44:25 +0200 References: <8A8CFE8F89C38B41A749C19328C76D6308CE370C8D@exchange02.bridgewatersys.com> X-Mailer: Apple Mail (2.930.3) Cc: "dime@ietf.org" , Mark Jones , "Lionel.morand@orange-ftgroup.com" Subject: Re: [Dime] Dime NAI Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 22:44:02 -0000 Hi Avi, Thanks for reading & commenting the I-D. On Mar 2, 2009, at 11:41 PM, Avi Lior wrote: > A couple of comments: > > 1) The draft should mention something about the presence of > Destination-Host AVP. > > The rule for routing is that the Destination-Host AVP is not looked > at until the message reaches the terminal realm as determined by the > decorated NAI. Where you would suggest to include the clarifying text? In Section 4.2.? > 2) I dont like the way Destination-Realm is being used. > > The draft states that the destination realm is updated on a hop by > hop basis together with the decorated NAI. I assume that is the only way to ensure the request message really goes through all wanted realms. > If an intermediary is not compliant with the scheme presented by > this draft it will result in the intermediary consuming the message > locally - since the message contains the destination realm equal to > its realm. Thus the message is not going to reach the destination. That is the reason why the I-D suggests only using the decoration stuff with a new application that is known to support this I-D. In that way legacy agents can be bypassed. > > Instead, I propose that the destination realm should be always set > to the terminal realm, thus: > > Agents that are compliant with the draft will first look at the NAI > to determine whether the packet has reached the terminal realm or > where it should be routed next; Are you proposing to make the routing decision based on the User-Name (and ignore the Destination-Realm all together) in cases where 1) the agent supports this I-D and 2) the User-Name contains a decorated NAI? Once the decorated NAI would have been "consumed" the checking would be based on the Destination-Realm again..? > Agents that are not compatible with the draft will use the old rules > for routing and would route the message according to the destination- > realm only and thus the message will reach the final destintaion > albeit not necessarily according to the decorated NAI. But at least > it would work. > > > Did I miss anything? What happens if.. the route happens to have some non-compliant agents and when the request reaches its final end (e.g. according to the inter-connection architecture) the User-Name still has decorated NAI? Would the decorated NAI compliant server/proxy send to request back to some other realm pointed by the User-name? This would effectively cause a routing loop, right? Cheers, Jouni > > From fqhuang@huawei.com Tue Mar 3 19:05:59 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 0C76928C29C for ; Tue, 3 Mar 2009 19:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[AWL=1.358, 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 0gnIipAMFcax for ; Tue, 3 Mar 2009 19:05:58 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8B55428C297 for ; Tue, 3 Mar 2009 19:05:53 -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 <0KFY0093SOM61B@szxga04-in.huawei.com> for dime@ietf.org; Wed, 04 Mar 2009 11:06:06 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFY00K0COM6B8@szxga04-in.huawei.com> for dime@ietf.org; Wed, 04 Mar 2009 11:06:06 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFY00909OM68T@szxml05-in.huawei.com> for dime@ietf.org; Wed, 04 Mar 2009 11:06:06 +0800 (CST) Date: Wed, 04 Mar 2009 11:06:06 +0800 From: Fortune HUANG In-reply-to: <03b601c99c45$a31c57f0$e95507d0$@net> To: 'Glen Zorn' , dime@ietf.org Message-id: <002a01c99c76$29002880$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: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcmcRaJAsYcFpnulTcy1vEP28RtfjQAI9Zkg Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in 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: Wed, 04 Mar 2009 03:05:59 -0000 Hi Glen, I would like to support your proposal. Maybe we can simply define the realm AVPs to be of type OctetString with the detailed description of the format, or we can derive a new Derived AVP Data Format for the realm AVPs. The latter would be my preference since realm is a very important concept and realm AVPs are used everywhere in Diameter. Best Regards, Fortune -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, March 04, 2009 5:19 AM To: dime@ietf.org Subject: [Dime] Problem with Origin- & Destination-Realm AVPs in RFC3588bis I'm pretty sure that I've mentioned this before, but the problematic definitions remain. The Origin-Realm & Destination-Realm AVPs are specified to be of type DiameterIdentity. This is plainly wrong, since DiameterIdentity is defined as an FQDN which is NOT the same as a Diameter realm. I think that it is _very_ important to fix this error in RFC 3588, rather than perpetuating it. ~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 From julien.bournelle@gmail.com Tue Mar 3 23:04:37 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 095E828C2C2 for ; Tue, 3 Mar 2009 23:04:37 -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 FtNKXuz2rc5o for ; Tue, 3 Mar 2009 23:04:36 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 1D00F28C2CF for ; Tue, 3 Mar 2009 23:04:36 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so2749469ywh.49 for ; Tue, 03 Mar 2009 23:05:03 -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:content-transfer-encoding; bh=Usr5ptenpPorrcaPccBXm0tQIbpEv0ndTmXS6MWSkqE=; b=c6crILZiiTt0cz7Z0csYIVwWfu50/epuMepQv8aM/4wR/8RYpNNzJzrtM/njydZaww IDU9tZqWcnCHrqlip5x8CGKcMgcNkjXV/ARyPpa6zu70/6i+pedtmODo9XggabtIBZos XJd0pRoehmSx9mEGkeyLsqN9xeObVE0zcTeEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=L14hnZvEwGxJDJR4yrmDmJeUiNFA6o7jctVwzLPQ/WpL8UbXhM74BvpR0cJRlF/JWF u9L8mUV/j/5mE/DWzlWudxZNPZkFn09fM6flbQwz44x5tWi/MGgD5qq7LwSBO1YFNF95 aZalR6d4qZSHAYBUMFP9iS463HtTpNqnfLpcI= MIME-Version: 1.0 Received: by 10.220.76.213 with SMTP id d21mr2663704vck.82.1236150303695; Tue, 03 Mar 2009 23:05:03 -0800 (PST) Date: Wed, 4 Mar 2009 08:05:03 +0100 Message-ID: <5e2406980903032305k48ad83b7r1015e61c6ed983ae@mail.gmail.com> From: Julien Bournelle To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] DiME ERP: new Application ID or not ? (non-roaming case) 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, 04 Mar 2009 07:04:37 -0000 Hi all, we try to solve the issue concerning the need for a new App-Id or not. The ERP protocol (RFC 5296) is to be used along with EAP. It basically defines two new EAP codes and uses keying material derived from a first EAP authentication. To start the discussion, let's take the non-roaming case. In non-roaming, we have first an EAP authentication using Diameter EAP. Then, for reauthentication using ERP, we have two messages (Request/Response) between NAS and the AAA/ERP server carrying EAP packets See (http://tools.ietf.org/html/rfc5296#page-6) So, either we reuse the Diameter EAP Application (DER/DEA) or we define a new Diameter Application. If we use a new Diameter Application, a new Diameter session will be created and eventually a new Diameter server will be reached. What bothers me in this case is that we basically perform a reauthentication for the same session which is primarly handled at the AAA/EAP server. So, i'm wondering what happens concerning Authorization Lifetime session etc.. Note that I still don't have strong opinion and I'll be glad to hear opinions from others. Regards, Julien From Hannes.Tschofenig@gmx.net Wed Mar 4 00:13: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 7BEE23A67F1 for ; Wed, 4 Mar 2009 00:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 61LP04FiDhvr for ; Wed, 4 Mar 2009 00:13:09 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9D2CE3A69C3 for ; Wed, 4 Mar 2009 00:12:55 -0800 (PST) Received: (qmail invoked by alias); 04 Mar 2009 08:13:22 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp071) with SMTP; 04 Mar 2009 09:13:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18EZU4J6c8EGZGww9hFpWL1YCXDnydWrnVPkpDWyB lkikDzVatSfdNP From: "Hannes Tschofenig" To: "'Julien Bournelle'" , References: <5e2406980903032305k48ad83b7r1015e61c6ed983ae@mail.gmail.com> Date: Wed, 4 Mar 2009 10:14:25 +0200 Message-ID: <020e01c99ca1$3b704150$2fb4b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <5e2406980903032305k48ad83b7r1015e61c6ed983ae@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acmcl4yfFb8ciL5dQ46U35p77sP32gACRBKw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Subject: Re: [Dime] DiME ERP: new Application ID or not ? (non-roaming case) 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, 04 Mar 2009 08:13:10 -0000 Hi Julien, When we discussed this at the phone conference call (and the discussion is also captured in the meeting minutes) then I thought that the conclusion was to define a new Diameter application for this exchange: Peer Authenticator Server ==== ============= ====== [<-- EAP-Initiate/ ----- Re-auth-Start] [<-- EAP-Request/ ------ Identity] ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> Re-auth/ Re-auth/ [Bootstrap] [Bootstrap]) <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- Re-auth/ Re-auth/ [Bootstrap] [Bootstrap]) Note: [] brackets indicate optionality. Figure 2: ERP Exchange (The server in the figure above is the HOKEY server, a dedicated entity.) The initial EAP authentication is left untouched and, as Glen explained us, there is the assumption that the AAA entities work together with the HOKEY servers in a non-standardized way. To me that sounded like a good plan. Does this make any sense? The non-HOKEY expert Hannes PS: I never said that this is specific document is going to be trivial :-) >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Julien Bournelle >Sent: 04 March, 2009 09:05 >To: dime@ietf.org >Subject: [Dime] DiME ERP: new Application ID or not ? >(non-roaming case) > >Hi all, > > we try to solve the issue concerning the need for a new App-Id or not. > > The ERP protocol (RFC 5296) is to be used along with EAP. It >basically defines two new EAP codes and uses keying material >derived from a first EAP authentication. > > To start the discussion, let's take the non-roaming case. > > In non-roaming, we have first an EAP authentication using >Diameter EAP. > Then, for reauthentication using ERP, we have two messages >(Request/Response) between NAS and the AAA/ERP server >carrying EAP packets > > See (http://tools.ietf.org/html/rfc5296#page-6) > > So, either we reuse the Diameter EAP Application (DER/DEA) or >we define a new Diameter Application. > > If we use a new Diameter Application, a new Diameter session >will be created and eventually a new Diameter server will be >reached. What bothers me in this case is that we basically >perform a reauthentication for the same session which is >primarly handled at the AAA/EAP server. So, i'm wondering what >happens concerning Authorization Lifetime session etc.. > > Note that I still don't have strong opinion and I'll be glad >to hear opinions from others. > > Regards, > > Julien >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From lionel.morand@orange-ftgroup.com Wed Mar 4 01:56: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 1CD663A6B44 for ; Wed, 4 Mar 2009 01:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 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 Dcic-hUSy+wX for ; Wed, 4 Mar 2009 01:56:44 -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 CC1303A6B84 for ; Wed, 4 Mar 2009 01:56:43 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 10:57:07 +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: Wed, 4 Mar 2009 10:57:06 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02606456C6A@ftrdmel2> In-Reply-To: <03b601c99c45$a31c57f0$e95507d0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Problem with Origin- & Destination-Realm AVPs in RFC3588bis Thread-Index: AcmcRaJAsYcFpnulTcy1vEP28RtfjQAZy2dg References: <03b601c99c45$a31c57f0$e95507d0$@net> From: To: , X-OriginalArrivalTime: 04 Mar 2009 09:57:07.0757 (UTC) FILETIME=[94459DD0:01C99CAF] Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in 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: Wed, 04 Mar 2009 09:56:45 -0000 Hi, Could it be "simply" solved by modifying the definition of the = DiameterIdentity format to reflect that it can be either an FQDN or a = realm? Something like: DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. DiameterIdentity =3D FQDN/realm DiameterIdentity value is used to identify: - either a Diameter node for purposes of duplicate connection and routing loop detection. - either a realm to determine whether messages can be satisfied=20 locally, or whether they must be routed or redirected.=20 When the DiameterIdentity is used to identify a Diameter node, the contents of the string MUST be the FQDN of the Diameter node. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter node can be identified by several FQDNs, a single FQDN should be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it is sent on. Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Glen Zorn > Envoy=E9 : mardi 3 mars 2009 22:19 > =C0 : dime@ietf.org > Objet : [Dime] Problem with Origin- & Destination-Realm AVPs=20 > in RFC3588bis >=20 > I'm pretty sure that I've mentioned this before, but the=20 > problematic definitions remain. The Origin-Realm &=20 > Destination-Realm AVPs are specified to be of type=20 > DiameterIdentity. This is plainly wrong, since=20 > DiameterIdentity is defined as an FQDN which is NOT the same=20 > as a Diameter realm. I think that it is _very_ important to=20 > fix this error in RFC 3588, rather than perpetuating it. >=20 > ~gwz >=20 > Play assigns meaning to human activity--work erases it. > -- P.L. Wilson >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From julien.bournelle@gmail.com Wed Mar 4 02:03:11 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 34C893A684A for ; Wed, 4 Mar 2009 02:03:11 -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 xh9DqJsLVy4A for ; Wed, 4 Mar 2009 02:03:10 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 3B71F3A6876 for ; Wed, 4 Mar 2009 02:02:58 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so2766492ywh.49 for ; Wed, 04 Mar 2009 02:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QT8xha5lScjTRkUtlCdwECGFIMu/g351LgDDWpdoq7g=; b=RVTdT5K9/PVHDl5zdmDeOJG8e4EvFs4sHqlMLzNKGhtpGpOohSjt6bwPk/LPrGaUV/ e+An/SALEAfClsYHjh1Q1jwjRlHnYPLyh2xPRMN+z34gjCo2nlXUVfMZzhsipS5RuEHv GcZ5J4ML1cogQhoT+/slU0JxRAiyayQj9JZHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LVS1liANAml9WX24bydMQGw73K4nPzg2ZOK+ZLrZKITgIpLe9QQbhESWT86Qz0DGVO pqSzfshIPW2rlFVwEpfu445U2cd/wigWZlZsBcBy5dyK9hRKeqmM18eMHt3y4qmRzd+T kX160LOcIZTPxyF7EfQgMnrJLDaPk5mqiouUk= MIME-Version: 1.0 Received: by 10.220.71.130 with SMTP id h2mr2687253vcj.118.1236161005871; Wed, 04 Mar 2009 02:03:25 -0800 (PST) In-Reply-To: <020e01c99ca1$3b704150$2fb4b70a@nsnintra.net> References: <5e2406980903032305k48ad83b7r1015e61c6ed983ae@mail.gmail.com> <020e01c99ca1$3b704150$2fb4b70a@nsnintra.net> Date: Wed, 4 Mar 2009 11:03:25 +0100 Message-ID: <5e2406980903040203i26ab161bs3f221dc4ac03ed7@mail.gmail.com> From: Julien Bournelle To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] DiME ERP: new Application ID or not ? (non-roaming case) 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, 04 Mar 2009 10:03:11 -0000 hi hannes, see inline, On Wed, Mar 4, 2009 at 9:14 AM, Hannes Tschofenig wrote: > Hi Julien, > > When we discussed this at the phone conference call (and the discussion i= s > also captured in the meeting minutes) then I thought that the conclusion = was > to define a new Diameter application for this exchange: > > > =A0 Peer =A0 =A0 =A0 =A0 =A0 =A0 =A0 Authenticator =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0Server > =A0 =3D=3D=3D=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D=3D=3D=3D=3D=3D > > =A0 =A0[<-- EAP-Initiate/ ----- > =A0 =A0 =A0 =A0Re-auth-Start] > =A0 =A0[<-- EAP-Request/ ------ > =A0 =A0 =A0 =A0Identity] > > > =A0 =A0---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> > =A0 =A0 =A0 =A0 =A0Re-auth/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Re-auth/ > =A0 =A0 =A0 =A0 [Bootstrap] =A0 =A0 =A0 =A0 =A0 =A0 =A0[Bootstrap]) > > =A0 =A0<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- > =A0 =A0 =A0 =A0 =A0Re-auth/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Re-auth/ > =A0 =A0 =A0 =A0[Bootstrap] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Bootstrap]) > > =A0 Note: [] brackets indicate optionality. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 2: ERP Exchange > > (The server in the figure above is the HOKEY server, a dedicated entity.) > > > The initial EAP authentication is left untouched and, as Glen explained u= s, > there is the assumption that the AAA entities work together with the HOKE= Y > servers in a non-standardized way. To me that sounded like a good plan. > > Does this make any sense? Taking into accounts that we have one app-id for Diameter EAP (I would say NASREQ-EAP) AND soon another app-id for Diameter MIP6 (which also use EAP for authentication). It certainly make sense to not reuse the same App-ID for ERP if we want to use ERP for the mip6 case. Let's see if others have opinion. Regards, Julien > > > The non-HOKEY expert > Hannes > > PS: I never said that this is specific document is going to be trivial :-= ) > >>-----Original Message----- >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >>Behalf Of Julien Bournelle >>Sent: 04 March, 2009 09:05 >>To: dime@ietf.org >>Subject: [Dime] DiME ERP: new Application ID or not ? >>(non-roaming case) >> >>Hi all, >> >> we try to solve the issue concerning the need for a new App-Id or not. >> >> The ERP protocol (RFC 5296) is to be used along with EAP. It >>basically defines two new EAP codes and uses keying material >>derived from a first EAP authentication. >> >> To start the discussion, let's take the non-roaming case. >> >> In non-roaming, we have first an EAP authentication using >>Diameter EAP. >> Then, for reauthentication using ERP, we have two messages >>(Request/Response) =A0between NAS and the AAA/ERP server >>carrying EAP packets >> >> See (http://tools.ietf.org/html/rfc5296#page-6) >> >> So, either we reuse the Diameter EAP Application (DER/DEA) or >>we define a new Diameter Application. >> >> If we use a new Diameter Application, a new Diameter session >>will be created and eventually a new Diameter server will be >>reached. What bothers me in this case is that we basically >>perform a reauthentication for the same session which is >>primarly handled at the AAA/EAP server. So, i'm wondering what >>happens concerning Authorization Lifetime session etc.. >> >> Note that I still don't have strong opinion and I'll be glad >>to hear opinions from others. >> >> Regards, >> >> Julien >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www.ietf.org/mailman/listinfo/dime >> > > From dromasca@avaya.com Wed Mar 4 04:35:32 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 DC9CB28C2DA; Wed, 4 Mar 2009 04:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 qccIueBb9w3o; Wed, 4 Mar 2009 04:35:32 -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 5FEFB28C173; Wed, 4 Mar 2009 04:35:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,300,1233550800"; d="scan'208";a="139205321" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Mar 2009 07:35:57 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Mar 2009 07:35:56 -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, 4 Mar 2009 13:35:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-jones-dime-3gpp-eps-command-codes-01.txt to Informational RFC Thread-Index: AcmcuMC/ytBhHSQFTZyIKkla5jO//QADN4vA From: "Romascanu, Dan (Dan)" To: , , Subject: [Dime] FW: Evaluation: draft-jones-dime-3gpp-eps-command-codes-01.txt 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, 04 Mar 2009 12:35:33 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-dime-3gpp-eps-command-co des-01.txt Technical Summary This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). These new Diameter applications are defined for MME and SGSN related interfaces in the Release 8 architecture. Working Group Summary This document is not a DIME working group document but has received review from DIME WG members Document Quality The document has been reviewed by Hannes Tschofenig, Victor Fajardo and Glen Zorn from the DIME working group. The main work this document is based on has been developed in the 3GPP and has received a fair amount of review. Personnel Hannes Tschofenig is the document shepherd. Dan Romascanu is the responsible Area Director.=20 RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From lionel.morand@orange-ftgroup.com Wed Mar 4 05:21:12 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 017AD28C254 for ; Wed, 4 Mar 2009 05:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5GRzu6UUxAo for ; Wed, 4 Mar 2009 05:21:11 -0800 (PST) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id BAAE128C237 for ; Wed, 4 Mar 2009 05:21:10 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 14:21:32 +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: Wed, 4 Mar 2009 14:21:29 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02606456D4A@ftrdmel2> In-Reply-To: <00ac01c99cc2$b5d76330$9001a8c0@xxxx87e842e29b> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Problem with Origin- & Destination-Realm AVPs in RFC3588bis Thread-Index: AcmcRaJAsYcFpnulTcy1vEP28RtfjQAZy2dgAATaNmAAAsgQsA== References: <7DBAFEC6A76F3E42817DF1EBE64CB02606456C6A@ftrdmel2> <00ac01c99cc2$b5d76330$9001a8c0@xxxx87e842e29b> From: To: , , X-OriginalArrivalTime: 04 Mar 2009 13:21:32.0620 (UTC) FILETIME=[22B330C0:01C99CCC] Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in 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: Wed, 04 Mar 2009 13:21:12 -0000 I'm not sure to understand but I might have missed something. >From a syntax point of view, what is the difference between a FQDN and a = realm? What would be the "potential" impacts to say that the DiameterIdentity = can be a FQDN or a realm? Lionel > -----Message d'origine----- > De : Fortune HUANG [mailto:fqhuang@huawei.com]=20 > Envoy=E9 : mercredi 4 mars 2009 13:14 > =C0 : MORAND Lionel RD-CORE-ISS; glenzorn@comcast.net; dime@ietf.org > Objet : RE: [Dime] Problem with Origin- & Destination-Realm=20 > AVPs in RFC3588bis >=20 > Hi Lionel, >=20 > Your proposal could probably work, but might challenge the=20 > Diameter parser if a strict check on the data format is needed. > Also, it would be inconvenient for us to apply the=20 > DiameterIdentity type to a AVP, we would also need to specify=20 > the sub-type (FQDN or realm) in addition to the specification=20 > of type DiameterIdentity, or else it would be not clear=20 > enough for the definition of a AVP. >=20 > Best Regards, > Fortune >=20 >=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of lionel.morand@orange-ftgroup.com > Sent: Wednesday, March 04, 2009 5:57 PM > To: glenzorn@comcast.net; dime@ietf.org > Subject: Re: [Dime] Problem with Origin- & Destination-Realm=20 > AVPs in RFC3588bis >=20 > Hi, >=20 > Could it be "simply" solved by modifying the definition of=20 > the DiameterIdentity format to reflect that it can be either=20 > an FQDN or a realm? >=20 > Something like: >=20 > DiameterIdentity > The DiameterIdentity format is derived from the OctetString AVP > Base Format. >=20 > DiameterIdentity =3D FQDN/realm >=20 > DiameterIdentity value is used to identify: > - either a Diameter node for purposes of duplicate=20 > connection and > routing loop detection. > - either a realm to determine whether messages can be satisfied=20 > locally, or whether they must be routed or redirected.=20 >=20 > When the DiameterIdentity is used to identify a Diameter node, > the contents of the string MUST be the FQDN of the=20 > Diameter node. > If multiple Diameter nodes run on the same host, each Diameter > node MUST be assigned a unique DiameterIdentity. If a Diameter > node can be identified by several FQDNs, a single FQDN should be > picked at startup, and used as the only=20 > DiameterIdentity for that > node, whatever the connection it is sent on. >=20 > Lionel >=20 > > -----Message d'origine----- > > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20 > De la part=20 > > de Glen Zorn Envoy=E9 : mardi 3 mars 2009 22:19 =C0 :=20 > dime@ietf.org Objet=20 > > : [Dime] Problem with Origin- & Destination-Realm AVPs in RFC3588bis > >=20 > > I'm pretty sure that I've mentioned this before, but the=20 > problematic=20 > > definitions remain. The Origin-Realm & Destination-Realm AVPs are=20 > > specified to be of type DiameterIdentity. This is plainly wrong,=20 > > since DiameterIdentity is defined as an FQDN which is NOT=20 > the same as=20 > > a Diameter realm. I think that it is _very_ important to fix this=20 > > error in RFC 3588, rather than perpetuating it. > >=20 > > ~gwz > >=20 > > Play assigns meaning to human activity--work erases it. > > -- P.L. Wilson > >=20 > >=20 > >=20 > > _______________________________________________ > > 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 >=20 >=20 From fbrockne@cisco.com Wed Mar 4 08:17: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 405583A691A for ; Wed, 4 Mar 2009 08:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-nPDWdlWaSI for ; Wed, 4 Mar 2009 08:17:38 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9268F28C34A for ; Wed, 4 Mar 2009 08:17:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208,217";a="35374175" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Mar 2009 16:18:04 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n24GI4uQ006554; Wed, 4 Mar 2009 17:18:04 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n24GI4bm020666; Wed, 4 Mar 2009 16:18:04 GMT Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 17:18:04 +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_01C99CE4.CBF07F8D" Date: Wed, 4 Mar 2009 17:18:03 +0100 Message-ID: <693E0961C9EFD946AC7067D6774636250784861D@xmb-ams-336.emea.cisco.com> In-Reply-To: <8A8CFE8F89C38B41A749C19328C76D6308AE2281F6@exchange02.bridgewatersys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Dime rechartering: Include Carrier-Grade NAT ControlApplication? Thread-Index: AckwX8T3ySFkqEURSt+aixgVjkUpmAAQLsRAGxDsECA= References: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com> <9cf5ced20810170653j4dd39b3dy851e21eb5da8e27f@mail.gmail.com> <8A8CFE8F89C38B41A749C19328C76D6308AE2281F6@exchange02.bridgewatersys.com> From: "Frank Brockners (fbrockne)" To: "Avi Lior" , "David Frascone" X-OriginalArrivalTime: 04 Mar 2009 16:18:04.0620 (UTC) FILETIME=[CC0620C0:01C99CE4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10301; t=1236183484; x=1237047484; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fbrockne@cisco.com; z=From:=20=22Frank=20Brockners=20(fbrockne)=22=20 |Subject:=20RE=3A=20[Dime]=20Dime=20rechartering=3A=20Inclu de=20Carrier-Grade=20NAT=20ControlApplication? |Sender:=20; bh=pmo4/Somlnt7xDkX6BbOm1bMMurLwIeqETzmANz0uNQ=; b=Bs3vdIwt9+Ql7drRfr0MKtzS1Ulxv7Uce0pSg8uh4YynDbn6m/FxwxsXfz UiJMVEvaXvoKRxWmraiAlCpb3KHnZgUKmNFH5OzOmDOcZT701a+Yc7RhV/Vt R3pGxbvAHV; Authentication-Results: ams-dkim-2; header.From=fbrockne@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT ControlApplication? 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, 04 Mar 2009 16:17:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99CE4.CBF07F8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Quick follow-up on the discussion we've had a while back: The just recently posted draft http://tools.ietf.org/html/draft-brockners-diameter-nat-control-00 outlines a new Diameter application for NAT control. =20 Appreciate your comments. =20 Thanks, Frank ________________________________ From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Friday, October 17, 2008 11:42 PM To: David Frascone; Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: RE: [Dime] Dime rechartering: Include Carrier-Grade NAT ControlApplication? =09 =09 David, =20 I agree with Frank that having such an application is required and now is the time to work on it. =20 I have been engaged with several wireless operators that are planning to deploy a CGN in the next year. I have been developing a set of AAA requirements to support such deployements over the past month. =20 It would be good to develop those as the CGN draft is being progressed. =20 Avi=20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone Sent: October 17, 2008 9:53 AM To: Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? =09 =09 Do you think we could have a draft before the meeting? =09 =09 On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne) wrote: =09 Hi, =09 while re-chartering DIME, could we consider a new application for Carrier-Grade NAT (CGN) control? CGN has become an important topic within the IPv4-completion/exhaustion debate - also proven by the significant number of drafts on this particular topic. Consequently, per endpoint control of a CGN is an important question to be addressed. Please find an abstract of a forthcoming draft below. I'm working on the full draft, but wanted to get the abstract out asap so that the work can be considered as part of the new charter. =09 Thanks, Frank =09 -- =09 Title =09 Diameter Carrier-Grade NAT Control Application =09 Abstract =09 The document will describe the framework, messages and procedures for the Diameter Carrier-Grade NAT Control (CGNC) application. The Diameter CGNC application allows gateways (e.g. Network Access Server (NAS)) to interact with Carrier-Grade NAT (CGN) devices. The interaction is to establish a context to commonly identify and manage endpoints on gateway and CGN. It is to allow the gateway to control and manage the =09 behavior of a CGN on a per-endpoint basis (e.g. control the total number of bindings for a particular endpoint, request the allocation of a binding for a particular endpoint). In addition, it allows the CGN to provide information relevant to accounting purposes to the gateway =09 (e.g. allocated NAT bindings etc.). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =09 ------_=_NextPart_001_01C99CE4.CBF07F8D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Quick follow-up on the discussion we've had a = while=20 back: The just recently posted draft http://tools.ietf.org/html/draft-brockners-diameter-nat-control-00=  outlines=20 a new Diameter application for NAT control.
 
Appreciate your comments.
 
Thanks, Frank

From: Avi Lior=20 [mailto:avi@bridgewatersystems.com]
Sent: Friday, October = 17, 2008=20 11:42 PM
To: David Frascone; Frank Brockners=20 (fbrockne)
Cc: dime@ietf.org
Subject: RE: [Dime] = Dime=20 rechartering: Include Carrier-Grade NAT=20 ControlApplication?

David,
 
I=20 agree with Frank that having such an application is required and now = is the=20 time to work on it.
 
I=20 have been engaged with several wireless operators that are planning to = deploy=20 a CGN in the next year.  I have been developing a set of AAA = requirements=20 to support such deployements over the past month.
 
It=20 would be good to develop those as the CGN draft is being=20 progressed.
 
Avi 

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of David=20 Frascone
Sent: October 17, 2008 9:53 AM
To: = Frank=20 Brockners (fbrockne)
Cc: dime@ietf.org
Subject: = Re:=20 [Dime] Dime rechartering: Include Carrier-Grade NAT Control=20 Application?

Do you think we could have a draft before the = meeting?

On Fri, Oct 17, 2008 at 4:19 AM, Frank = Brockners=20 (fbrockne) <fbrockne@cisco.com> = wrote:
Hi,

while re-chartering DIME, could we = consider a=20 new application for
Carrier-Grade NAT (CGN) control? CGN has = become an=20 important topic
within the IPv4-completion/exhaustion debate - = also=20 proven by the
significant number of drafts on this particular = topic.=20 Consequently, per
endpoint control of a CGN is an important = question to=20 be addressed.
Please find an abstract of a forthcoming draft = below. I'm=20 working on the
full draft, but wanted to get the abstract out = asap so=20 that the work can
be considered as part of the new=20 charter.

Thanks, Frank

--

Title

  = Diameter Carrier-Grade NAT Control=20 Application

Abstract

  The document will = describe the=20 framework, messages and procedures for
  the Diameter=20 Carrier-Grade NAT Control (CGNC) application.=20  The
Diameter
  CGNC application allows gateways = (e.g.=20 Network Access Server (NAS))
to
  interact with = Carrier-Grade=20 NAT (CGN) devices. The interaction is to
  establish a = context to=20 commonly identify and manage endpoints on
  gateway and = CGN. It is=20 to allow the gateway to control and manage the

  = behavior of a=20 CGN on a per-endpoint basis (e.g. control the = total
number
  of=20 bindings for a particular endpoint, request the allocation = of
  a=20 binding for a particular endpoint). In addition, it allows the=20 CGN
  to provide information relevant to accounting = purposes to=20 the gateway

  (e.g. allocated NAT bindings=20 etc.).
_______________________________________________
DiME = mailing=20 list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

------_=_NextPart_001_01C99CE4.CBF07F8D-- From Mark.Jones@bridgewatersystems.com Wed Mar 4 10:18: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 A1D343A6B6F for ; Wed, 4 Mar 2009 10:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-ja6hRt5cMJ for ; Wed, 4 Mar 2009 10:18:21 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id A9E5428C419 for ; Wed, 4 Mar 2009 10:18:04 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Wed, 4 Mar 2009 13:18:31 -0500 From: Mark Jones To: "dime@ietf.org" Date: Wed, 4 Mar 2009 13:18:30 -0500 Thread-Topic: [Dime] Diameter QoS Parameter -- DECISION TO MAKE Thread-Index: AcmcBaTaDMAVqRaFRn6FRU/yJWMIggA7pxtg Message-ID: References: <07c701c99986$73684350$2ab5b70a@nsnintra.net> <72D5BF85-3093-4781-99CD-9ABC5FAE12E2@gmail.com> <49AC6217.4080401@tari.toshiba.com> In-Reply-To: <49AC6217.4080401@tari.toshiba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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: Wed, 04 Mar 2009 18:18:22 -0000 I also support removing these parameters in order to move forward with the = QoS drafts. The Diameter QoS parameters draft is defining one possible QoS = template but the QoS attributes draft allows a set of supported QoS profile= s to be negotiated. So a new QoS profile template can be defined later for = the tsvwg parameters when they are stable.=20 Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Victor Fajardo > Sent: March 2, 2009 17:48 > To: jouni korhonen > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE >=20 > I agree. >=20 > > Hi all, > > > > I would support removing as well. Be done with it and move=20 > on with the > > QoS parameter document. Those features that were in the=20 > tsvwg document > > can be documented later in a separate document, when and if needed. > > > > Cheers, > > Jouni > > > > > > On Feb 28, 2009, at 11:25 AM, Hannes Tschofenig wrote: > > > >> Hi all, > >> > >> we have a normative reference in the Diameter QoS parameter draft > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parame > ters-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=20 > 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=20 > potentially a long > >> time). > >> Since the Diameter QoS attribute and the Diameter QoS application > >> document > >> normatively depend on the QoS parameter document they will=20 > be blocked as > >> well. > >> > >> So, I have been thinking of what we could do to deal with=20 > 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=20 > document and to > >> progress them independently to get the main part of the=20 > Diameter QoS > >> parameters document finalized. > >> *************** > >> > >> Please let me know if you find this idea acceptable.=20 > 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=20 > about that part > >> larter. > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = From vfajardo@tari.toshiba.com Wed Mar 4 14:02:36 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 8CC3F3A6C50 for ; Wed, 4 Mar 2009 14:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.530, 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 vkfruUnnb26p for ; Wed, 4 Mar 2009 14:02:35 -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 E46523A6CAB for ; Wed, 4 Mar 2009 14:02:25 -0800 (PST) Received: from [127.0.0.1] (mail.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n24LvZih080519; Wed, 4 Mar 2009 16:57:38 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <49AEFA71.9070608@tari.toshiba.com> Date: Wed, 04 Mar 2009 17:02:25 -0500 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <7DBAFEC6A76F3E42817DF1EBE64CB02606456C6A@ftrdmel2> <00ac01c99cc2$b5d76330$9001a8c0@xxxx87e842e29b> <7DBAFEC6A76F3E42817DF1EBE64CB02606456D4A@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02606456D4A@ftrdmel2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in 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: Wed, 04 Mar 2009 22:02:36 -0000 Hi Fortune, > I'm not sure to understand but I might have missed something. > >From a syntax point of view, what is the difference between a FQDN and a realm? > What would be the "potential" impacts to say that the DiameterIdentity can be a FQDN or a realm? > I have the same question as Lionel. Syntactically, FQDN and realm are the same from the parsers point of view. The difference is in semantics which is already specified by the AVP having that type. regards, victor From glenzorn@comcast.net Wed Mar 4 15:15: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 43D2828C34A for ; Wed, 4 Mar 2009 15:15:43 -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 dFibUNgFf7IM for ; Wed, 4 Mar 2009 15:15:42 -0800 (PST) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 63F5628C330 for ; Wed, 4 Mar 2009 15:15:42 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id Nzut1b0050x6nqcA6BGBGr; Wed, 04 Mar 2009 23:16:11 +0000 Received: from gwzPC ([24.18.239.198]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id PBGA1b00X4HXf1k8YBGBpE; Wed, 04 Mar 2009 23:16:11 +0000 From: "Glen Zorn" To: "'Victor Fajardo'" , References: <7DBAFEC6A76F3E42817DF1EBE64CB02606456C6A@ftrdmel2> <00ac01c99cc2$b5d76330$9001a8c0@xxxx87e842e29b> <7DBAFEC6A76F3E42817DF1EBE64CB02606456D4A@ftrdmel2> <49AEFA71.9070608@tari.toshiba.com> In-Reply-To: <49AEFA71.9070608@tari.toshiba.com> Date: Wed, 4 Mar 2009 15:15:57 -0800 Message-ID: <01f401c99d1f$2d25f8a0$8771e9e0$@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: AcmdFOq+QmJApq+0Q/i5N93lPP56FQAChEOw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in 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: Wed, 04 Mar 2009 23:15:43 -0000 Victor Fajardo [mailto:vfajardo@tari.toshiba.com] writes: > Hi Fortune, > > I'm not sure to understand but I might have missed something. > > >From a syntax point of view, what is the difference between a FQDN > and a realm? > > What would be the "potential" impacts to say that the > DiameterIdentity can be a FQDN or a realm? > > > I have the same question as Lionel. Syntactically, FQDN and realm are > the same from the parsers point of view. Yes. > The difference is in semantics > which is already specified by the AVP having that type. ??? > > regards, > victor From glenzorn@comcast.net Wed Mar 4 15:18:53 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 2757A28C1F8 for ; Wed, 4 Mar 2009 15:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJTpcYqYt-sK for ; Wed, 4 Mar 2009 15:18:52 -0800 (PST) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 57B6A28C3C9 for ; Wed, 4 Mar 2009 15:18:29 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id P7fe1b00A0lTkoCA1BJyQn; Wed, 04 Mar 2009 23:18:58 +0000 Received: from gwzPC ([24.18.239.198]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id PBJx1b00N4HXf1k8QBJyju; Wed, 04 Mar 2009 23:18:58 +0000 From: "Glen Zorn" To: Date: Wed, 4 Mar 2009 15:18:44 -0800 Message-ID: <020701c99d1f$90c0c7f0$b24257d0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0208_01C99CDC.829D87F0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcmdH0aNdWhaqUzCRYulwr8b7XpfKwAAD53g Content-Language: en-us Subject: [Dime] FW: I-D Action:draft-zorn-dime-capablities-update-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:18:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0208_01C99CDC.829D87F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, March 04, 2009 3:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-zorn-dime-capablities-update-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Diameter Capabilities Update Application Author(s) : G. Zorn, J. Kang Filename : draft-zorn-dime-capablities-update-00.txt Pages : 7 Date : 2009-03-04 This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zorn-dime-capablities-update-00.tx t 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_000_0208_01C99CDC.829D87F0 Content-Type: Message/External-body; name="draft-zorn-dime-capablities-update-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-zorn-dime-capablities-update-00.txt" Content-Type: text/plain Content-ID: <2009-03-04150441.I-D@ietf.org> ------=_NextPart_000_0208_01C99CDC.829D87F0 Content-Type: text/plain; name="ATT00511.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00511.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_0208_01C99CDC.829D87F0-- From fqhuang@huawei.com Wed Mar 4 18:45: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 AE6163A6B43 for ; Wed, 4 Mar 2009 18:45:51 -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=3.305, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+3cAdempoWp for ; Wed, 4 Mar 2009 18:45:50 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 91E163A6A40 for ; Wed, 4 Mar 2009 18:45:45 -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 <0KG000E95ID08C@szxga03-in.huawei.com> for dime@ietf.org; Thu, 05 Mar 2009 10:46:12 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KG0004U5ID09U@szxga03-in.huawei.com> for dime@ietf.org; Thu, 05 Mar 2009 10:46:12 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KG000MEHID0SE@szxml05-in.huawei.com> for dime@ietf.org; Thu, 05 Mar 2009 10:46:12 +0800 (CST) Date: Thu, 05 Mar 2009 10:46:12 +0800 From: Fortune HUANG In-reply-to: <49AEFA71.9070608@tari.toshiba.com> To: 'Victor Fajardo' , lionel.morand@orange-ftgroup.com Message-id: <008c01c99d3c$8bb36c00$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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmdGPOwer0ysEwxSU6RQedtiODYGwAGBwuQ Cc: dime@ietf.org Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in 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: Thu, 05 Mar 2009 02:45:51 -0000 Hi all, In section 1.3 of 3588bis, "Realm The string in the NAI that immediately follows the '@' character. NAI realm names are required to be unique, and are piggybacked on the administration of the DNS namespace. Diameter makes use of the realm, also loosely referred to as domain, to determine whether messages can be satisfied locally, or whether they must be routed or redirected. In RADIUS, realm names are not necessarily piggybacked on the DNS namespace but may be independent of it. " So I think the format of realm shoud be compliant with RFC4282. In section 2.1 of RFC4282, the grammar for the realm is an updated version of [RFC1035]. " realm = 1*( label "." ) label label = let-dig *(ldh-str) ldh-str = *( alpha / digit / "-" ) let-dig let-dig = alpha / digit alpha = %x41-5A ; 'A'-'Z' alpha =/ %x61-7A ; 'a'-'z' digit = %x30-39 ; '0'-'9' " In section 9 of RFC4566 "FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified ; in RFC 1035 (and updates) " Section 2.3.1 of RFC1035 " ::= | " " ::=