From dime-bounces@ietf.org Wed Sep 3 03:42:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612643A6CAD; Wed, 3 Sep 2008 03:42:55 -0700 (PDT) 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 1A4143A6CAD for ; Wed, 3 Sep 2008 03:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[AWL=1.997, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx43vHX17256 for ; Wed, 3 Sep 2008 03:42:52 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 91ABC3A6CB5 for ; Wed, 3 Sep 2008 03:42:35 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Sep 2008 12:42:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 12:42:06 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A210A@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD Review of draft-ietf-dime-mip6-integrated-09.txt Thread-Index: AckHi/kUHwUKg114TlmodMPLK18zlQGG9lgw References: From: To: , X-OriginalArrivalTime: 03 Sep 2008 10:42:06.0978 (UTC) FILETIME=[B5F38E20:01C90DB1] Subject: Re: [Dime] AD Review of draft-ietf-dime-mip6-integrated-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dan, See proposed text for the points you raised. [snip] > [1] is RFC 3775 which says nothing about a registry for mobility > capability, and does not recommend Expert Review policy for any other > registry. The document needs to find another reference, or synchronize > the policy with what is recommended in 3775. > > In any case, if Expert Review policy is applied, I do not see the need > to involve the O&M area directors or the DIME or successors of DIME in > initiating a review. As in many other cases I expect that > requests will > be sent to IANA for new entries in the capabilities registry, and IANA > will forward them to the designated expert. Following standard > procedures is always better unless there are good reasons to invent > something new. New text to section 7.2: Following the example policies described in [11] new values for the MIP6-Feature-Vector AVP will be assigned based on the "Specification Required" policy. No mechanism to mark entries as "deprecated" is envisioned. > 2. Section 2 mentions reference [8] as the source for the additional > terms. In reality only the first four terms are borrowed from > [8] (which > is RFC 4640) while the rest may have different sources or are defined > here. Please correct this. New text to section 2: General mobility terminology can be found in [RFC3753]. The following additional terms below are either borrowed from [RFC4640][RFC5026] or introduced in this document: Cheers, Jouni > > Thanks and Regards, > > Dan > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 3 03:45:36 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DD33A6C7E; Wed, 3 Sep 2008 03:45:36 -0700 (PDT) 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 5D0103A6B1F for ; Wed, 3 Sep 2008 03:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, 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 bVmCGKeaseeE for ; Wed, 3 Sep 2008 03:45:33 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A71B73A6889 for ; Wed, 3 Sep 2008 03:45:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217822400"; d="scan'208";a="142084548" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 03 Sep 2008 06:45:23 -0400 X-IronPort-AV: E=Sophos;i="4.32,320,1217822400"; d="scan'208";a="264956107" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Sep 2008 06:45:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 12:45:21 +0200 Message-ID: In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3031A210A@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD Review of draft-ietf-dime-mip6-integrated-09.txt Thread-Index: AckHi/kUHwUKg114TlmodMPLK18zlQGG9lgwAAKQIRA= References: <59D7431DE2527D4CB0F1EFEDA5683ED3031A210A@SEHAN021MB.tcad.telia.se> From: "Romascanu, Dan (Dan)" To: , Subject: Re: [Dime] AD Review of draft-ietf-dime-mip6-integrated-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, The proposed changes seem fine to me. Regards, Dan > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Wednesday, September 03, 2008 1:42 PM > To: Romascanu, Dan (Dan); dime@ietf.org > Subject: RE: [Dime] AD Review of > draft-ietf-dime-mip6-integrated-09.txt > > Hi Dan, > > See proposed text for the points you raised. > > [snip] > > > [1] is RFC 3775 which says nothing about a registry for mobility > > capability, and does not recommend Expert Review policy for > any other > > registry. The document needs to find another reference, or > synchronize > > the policy with what is recommended in 3775. > > > > In any case, if Expert Review policy is applied, I do not > see the need > > to involve the O&M area directors or the DIME or successors > of DIME in > > initiating a review. As in many other cases I expect that requests > > will be sent to IANA for new entries in the capabilities > registry, and > > IANA will forward them to the designated expert. Following standard > > procedures is always better unless there are good reasons to invent > > something new. > > New text to section 7.2: > > Following the example policies described in [11] new values for the > MIP6-Feature-Vector AVP will be assigned based on the > "Specification > Required" policy. No mechanism to mark entries as "deprecated" is > envisioned. > > > 2. Section 2 mentions reference [8] as the source for the > additional > > terms. In reality only the first four terms are borrowed from [8] > > (which is RFC 4640) while the rest may have different > sources or are > > defined here. Please correct this. > > New text to section 2: > > General mobility terminology can be found in [RFC3753]. > The following > additional terms below are either borrowed from > [RFC4640][RFC5026] or > introduced in this document: > > > > Cheers, > Jouni > > > > > Thanks and Regards, > > > > Dan > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 3 23:42:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9A33A6809; Wed, 3 Sep 2008 23:42:34 -0700 (PDT) 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 49C7E3A6809 for ; Wed, 3 Sep 2008 23:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.675 X-Spam-Level: X-Spam-Status: No, score=-4.675 tagged_above=-999 required=5 tests=[AWL=1.924, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS4Rj1PhkQ4w for ; Wed, 3 Sep 2008 23:42:31 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A78863A67F5 for ; Wed, 3 Sep 2008 23:42:30 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m846fb9O018037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 08:41:37 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m846fXOP004609; Thu, 4 Sep 2008 08:41:37 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 08:41:34 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 08:41:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 09:41:15 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Design Team on Diameter Routing Thread-Index: AckOWTrbDliLjk97Ss6g9vo24qVgmA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 04 Sep 2008 06:41:17.0814 (UTC) FILETIME=[3BFDD960:01C90E59] Cc: diameter-routing@googlegroups.com Subject: [Dime] Design Team on Diameter 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The DIME chairs in discussion with Dan decided to create a design team with the intention to investigate extensions to the RFC 3588bis Diameter routing. More specifically, we had discussions about this subject triggered by the publication of http://tools.ietf.org/id/draft-tsou-dime-base-routing-ext-04.txt that never got resolved and the impression of folks at the IETF#72 meeting was that we have to investigate the usage scenarios and to develop a problem statement before we focus on the solution components. The first product of the group will be a problem statement and usage scenarios description that will be presented to the DIME group. Other necessary activity will be decided based on the outcome of the above-mentioned deliverable. The design team members are: - Tena Tsou - Victor Fajardo - Jouni Korhonen - Tolga Asveren - Mark Jones - Avi Lior - Glen Zorn - Steve Norreys - Lionel Morand The design team is lead by the working group chairs: Dave Frascone and Hannes Tschofenig Mailing List archive: http://groups.google.com/group/diameter-routing Ciao Hannes & Dave PS: The rules for design teams are described in http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 7 21:09:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75BD3A6999; Sun, 7 Sep 2008 21:09:46 -0700 (PDT) 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 3AEA53A6999 for ; Sun, 7 Sep 2008 21:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBBJbneTlLwI for ; Sun, 7 Sep 2008 21:09:44 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id ED2AC3A6859 for ; Sun, 7 Sep 2008 21:09:43 -0700 (PDT) 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 <0K6U00M2BZK011@szxga03-in.huawei.com> for dime@ietf.org; Mon, 08 Sep 2008 12:09:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K6U00LKEZK0K1@szxga03-in.huawei.com> for dime@ietf.org; Mon, 08 Sep 2008 12:09:36 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K6U0043UZJZCW@szxml03-in.huawei.com> for dime@ietf.org; Mon, 08 Sep 2008 12:09:36 +0800 (CST) Date: Mon, 08 Sep 2008 12:09:35 +0800 From: Tina TSOU To: dime@ietf.org, "Tschofenig, Hannes (NSN - FI/Espoo)" Message-id: <001f01c91168$b4842580$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: Cc: diameter-routing@googlegroups.com Subject: Re: [Dime] Design Team on Diameter 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: , Content-Type: multipart/mixed; boundary="===============1195194375==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1195194375== Content-type: multipart/alternative; boundary="Boundary_(ID_NJ076yrwvcyViBPzz2glqw)" This is a multi-part message in MIME format. --Boundary_(ID_NJ076yrwvcyViBPzz2glqw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Hannes, When I tried to reply in google, it asked me to join first. When I tried to joined it, it said that Sorry... This group is invite only. Please return to the group home page or the Groups main page. I suppose you could invite us in. I would just like to say that Jouni used to summarize 3 scenarios for this issue, especially those in 3GPP PCC, charging etc. I would like to invite him to post them again. B. R. Tina ----- Original Message ----- From: Tschofenig, Hannes (NSN - FI/Espoo) To: dime@ietf.org Cc: diameter-routing@googlegroups.com Sent: Thursday, September 04, 2008 2:41 PM Subject: [Dime] Design Team on Diameter Routing The DIME chairs in discussion with Dan decided to create a design team with the intention to investigate extensions to the RFC 3588bis Diameter routing. More specifically, we had discussions about this subject triggered by the publication of http://tools.ietf.org/id/draft-tsou-dime-base-routing-ext-04.txt that never got resolved and the impression of folks at the IETF#72 meeting was that we have to investigate the usage scenarios and to develop a problem statement before we focus on the solution components. The first product of the group will be a problem statement and usage scenarios description that will be presented to the DIME group. Other necessary activity will be decided based on the outcome of the above-mentioned deliverable. The design team members are: - Tena Tsou - Victor Fajardo - Jouni Korhonen - Tolga Asveren - Mark Jones - Avi Lior - Glen Zorn - Steve Norreys - Lionel Morand The design team is lead by the working group chairs: Dave Frascone and Hannes Tschofenig Mailing List archive: http://groups.google.com/group/diameter-routing Ciao Hannes & Dave PS: The rules for design teams are described in http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_NJ076yrwvcyViBPzz2glqw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Hannes,
When I tried to reply in google, it asked me to join first. When I tried to joined it, it said that

Sorry...

This group is invite only. Please return to the group home page or the Groups main page.

 
I suppose you could invite us in.
 
I would just like to say that Jouni used to summarize 3 scenarios for this issue, especially those in 3GPP PCC, charging etc.
I would like to invite him to post them again.
 
B. R.
Tina
----- Original Message -----
Sent: Thursday, September 04, 2008 2:41 PM
Subject: [Dime] Design Team on Diameter Routing

The DIME chairs in discussion with Dan decided to create a design team
with the intention to investigate extensions to the RFC 3588bis Diameter
routing. More specifically, we had discussions about this subject
triggered by the publication of
http://tools.ietf.org/id/draft-tsou-dime-base-routing-ext-04.txt that
never got resolved and the impression of folks at the IETF#72 meeting
was that we have to investigate the usage scenarios and to develop a
problem statement before we focus on the solution components.

The first product of the group will be a problem statement and usage
scenarios description that will be presented to the DIME group.
Other necessary activity will be decided based on the outcome of the
above-mentioned deliverable.

The design team members are:
- Tena Tsou
- Victor Fajardo
- Jouni Korhonen
- Tolga Asveren
- Mark Jones
- Avi Lior
- Glen Zorn
- Steve Norreys
- Lionel Morand

The design team is lead by the working group chairs: Dave Frascone and
Hannes Tschofenig

Mailing List archive:
http://groups.google.com/group/diameter-routing

Ciao
Hannes & Dave

PS: The rules for design teams are described in
http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--Boundary_(ID_NJ076yrwvcyViBPzz2glqw)-- --===============1195194375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1195194375==-- From dime-bounces@ietf.org Mon Sep 8 06:45:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7133A6A41; Mon, 8 Sep 2008 06:45:08 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E51BA3A69B5; Mon, 8 Sep 2008 06:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080908134501.E51BA3A69B5@core3.amsl.com> Date: Mon, 8 Sep 2008 06:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-12.txt Pages : 160 Date : 2008-09-08 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-09-08063341.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Sep 8 14:18:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31513A6A74; Mon, 8 Sep 2008 14:18:57 -0700 (PDT) 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 DD7893A6971 for ; Mon, 8 Sep 2008 14:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.25 X-Spam-Level: X-Spam-Status: No, score=-5.25 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkpZps9+BROH for ; Mon, 8 Sep 2008 14:18:56 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id D19223A6A6D for ; Mon, 8 Sep 2008 14:18:55 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 23:18:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Sep 2008 23:16:34 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A21C0@SEHAN021MB.tcad.telia.se> In-Reply-To: <20080908134501.E51BA3A69B5@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About draft-ietf-dime-rfc3588bis-12.txt Thread-Index: AckRuSZrQrmZVRF8SiKvX+HH/ZLjJwAPOGIQ References: <20080908134501.E51BA3A69B5@core3.amsl.com> From: To: X-OriginalArrivalTime: 08 Sep 2008 21:18:54.0950 (UTC) FILETIME=[7FBE2860:01C911F8] Subject: [Dime] About draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Few quick notes on -12: o Section 4.4 I don't recall an agreement of replacing the: "..MAY simply be ignored if the Grouped AVP itself is unrecognized. However, the encapsulated AVPs with 'M' (mandatory) bit set MUST belong to the Diameter application the Grouped APV is used in. The rule applies even if the encapsulated AVP with its 'M' (mandatory).. " with "..MAY simply be ignored if the Grouped AVP itself is unrecognized. The rule applies even if the encapsulated AVP with its 'M' (mandatory).. " The new text allows me "legally" send AVPs with 'M'-bit set that do not belong to the application. I don't want such functionality! o Section 7.1.5 s/recognize or doest not support/recognize or does not support Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 9 01:31:33 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FF03A6A69; Tue, 9 Sep 2008 01:31:33 -0700 (PDT) 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 B75C83A69A5 for ; Tue, 9 Sep 2008 01:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcI8WaYCyTiI for ; Tue, 9 Sep 2008 01:31:32 -0700 (PDT) Received: from mail-gx0-f29.google.com (mail-gx0-f29.google.com [209.85.217.29]) by core3.amsl.com (Postfix) with ESMTP id A91913A69CE for ; Tue, 9 Sep 2008 01:31:31 -0700 (PDT) Received: by gxk10 with SMTP id 10so6976889gxk.13 for ; Tue, 09 Sep 2008 01:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=TghJHmwImvfexIdfx2zXDq5LXDdlkJXAnWYklPc+G6k=; b=d2sGn2i83tyUEb0Ikhd7Q1YLUSAMAs0i6cny9wuj/w23nU5XGXmcreOIelz/q0B8oV ZgXWyEmqMXQ+MetXFtEoHt2TV3mZS9uc70dCl3mSK3ktcHZE/sA0w8deoZRmzeNGfjHb 9TUsPr7U9swus8FQDVpdYQDToELkQErwzfG3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=aOn6I4Dz6cI11yK1+Ff9d5AGzWWzMAGPdDc6xBf/PXMbMl1xgp9gqTXbHOy1bODy6w BitBKoM+VtLWMNBWo7eEskSJBQVNTBsqXrLd8WIRlaMfiL8UmLDJ8SrNM72lw4ztz3US V5iiyWMoToIW/LMKczD8hbTwaOMsU0fLriZwg= Received: by 10.70.50.6 with SMTP id x6mr20413459wxx.48.1220948096322; Tue, 09 Sep 2008 01:14:56 -0700 (PDT) Received: by 10.70.9.11 with HTTP; Tue, 9 Sep 2008 01:14:56 -0700 (PDT) Message-ID: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> Date: Tue, 9 Sep 2008 13:44:56 +0530 From: "Jacob Martin" To: dime@ietf.org MIME-Version: 1.0 Subject: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1302501003==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1302501003== Content-Type: multipart/alternative; boundary="----=_Part_11500_21753874.1220948096280" ------=_Part_11500_21753874.1220948096280 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am a bit confused about the feasibility of one specific configuration in Diameter. Please look at the diagram below: | | | | Local Node | | +----+ +-------+ | |NAS | | Wm | +--------+ +--------+ | +----+ +-------+ | | | | | | --- |NASREQ | | Wm | | | --- +----\---+ +---/----+ | +----- -- \ // | //// \\\\\ \ // | |/ | \ // | | PEER | +---\-/------+ | | | | | | |\ | |Diameter | | \\\\ ///// |Base process| | ------ +----+-------+ | | | | | | | | +------------------+-------------+ I wish to provide support for two applications on my local node i.e NASREQ and Wm. As per Wm specifications, Wm should reuse the application identifier of EAP/NASREQ. So, in CEA, I have advertised '1' and '5' as the applications supported. Assume that peer node also has the same configuration as of mine i.e it also support Wm and NAS applications. Now, peer Wm application issues an AAR. After receiving this AAR, how could my Diameter base process determine that this AAR is for local Wm application, but not for local NASREQ application? Thanks in anticipation, Martin ------=_Part_11500_21753874.1220948096280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi,
 
    I am a bit confused= about the feasibility of one specific configuration in Diameter.
 = ;
    Please look at the diagram below:   =        
 
 
       &nbs= p;            &= nbsp;           |
            &nb= sp;            =        |
     &nb= sp;            =             &nb= sp; |
           = ;            &n= bsp;        |    &nb= sp;
   Local Node       &n= bsp;           |
 = ;            &n= bsp;            = ;      |       = +----+       +-------+
            &nb= sp;            =        |      &= nbsp; |NAS |       |  Wm   |    +--------+   +--------+   &nb= sp; |        +----+   &nb= sp;   +-------+
    |    &n= bsp;   |   |        = |     |        =     |         &= nbsp;  ---
    |NASREQ  |   |  W= m    |     |    &nbs= p;        |     = ;   ---
    +----\---+   +---/----+    = ; |            = +----- --
          \ = ;       //      = ;     |        = ////      \\\\\
 &nbs= p;        \     = ; //            = ; |       |/     &nb= sp;         |
           \   = //            &= nbsp;  |      |     =    PEER     |
    &nbs= p;   +---\-/------+       &nbs= p;  |      |     &nb= sp;            |
=         |     &= nbsp;      |      &n= bsp;   |       |\   =             |
&nb= sp;       |Diameter    | =          |    &= nbsp;    \\\\=     &nb= sp; /////
        |Base process|   =        |      &= nbsp;      ------
     = ;   +----+-------+        = ;  |           =   |
          &nb= sp;  |          &nbs= p;       |      = ;       |
     &n= bsp;       |     &nb= sp;            |&nbs= p;            |
&= nbsp;            +--= ----------------+-------------+
            &nb= sp;            =       
   I wish to provide sup= port for two applications on my local node i.e NASREQ and Wm. As per Wm spe= cifications, Wm should reuse the application identifier of EAP/NASREQ. So, = in CEA, I have advertised '1' and '5' as the applications s= upported.
 
   Assume that peer node also has the same configuratio= n as of mine i.e it also support Wm and NAS applications.
 
&nb= sp; Now, peer Wm application issues an AAR. After receiving this AAR, how c= ould my Diameter base process determine that this AAR is for local Wm appli= cation, but not for local NASREQ application?
 

  Thanks in anticipation,
  Martin    &= nbsp;           &nbs= p;             =
            = ;            &n= bsp;      
     =             &nb= sp;            =  

------=_Part_11500_21753874.1220948096280-- --===============1302501003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1302501003==-- From dime-bounces@ietf.org Tue Sep 9 04:07:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53093A695F; Tue, 9 Sep 2008 04:07:16 -0700 (PDT) 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 E3F8E3A6957 for ; Tue, 9 Sep 2008 04:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.324 X-Spam-Level: ** X-Spam-Status: No, score=2.324 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVef7E2Iv1yH for ; Tue, 9 Sep 2008 04:07:14 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by core3.amsl.com (Postfix) with ESMTP id 724013A695F for ; Tue, 9 Sep 2008 04:07:14 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id m89B3SOv008116; Tue, 9 Sep 2008 20:03:28 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m89B3SBr013616; Tue, 9 Sep 2008 20:03:28 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m89B3SUe013613; Tue, 9 Sep 2008 20:03:28 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 1ED3B438E; Tue, 9 Sep 2008 20:03:28 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id F2E1C4372; Tue, 9 Sep 2008 20:03:27 +0900 (JST) Message-ID: <48C657BB.4050103@nict.go.jp> Date: Tue, 09 Sep 2008 20:02:19 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jacob Martin References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> In-Reply-To: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, I think the Application Id in the command header will contain the = appropriate identifier to route the message to the correct handler... Best regards, Sebastien. Jacob Martin a =E9crit : > > Hi, > = > I am a bit confused about the feasibility of one specific = > configuration in Diameter. > = > Please look at the diagram below: = > = > = > | > | > | > | = > Local Node | > | +----+ +-------+ > | |NAS | | Wm | > +--------+ +--------+ | +----+ +-------+ > | | | | | | --- > |NASREQ | | Wm | | | --- > +----\---+ +---/----+ | +----- -- > \ // | //// \\\\\ > \ // | |/ | > \ // | | PEER | > +---\-/------+ | | | > | | | |\ | > |Diameter | | \\\\ ///// > |Base process| | ------ > +----+-------+ | | > | | | > | | | > +------------------+-------------+ > = > I wish to provide support for two applications on my local node i.e = > NASREQ and Wm. As per Wm specifications, Wm should reuse the = > application identifier of EAP/NASREQ. So, in CEA, I have advertised = > '1' and '5' as the applications supported. > = > Assume that peer node also has the same configuration as of mine = > i.e it also support Wm and NAS applications. > = > Now, peer Wm application issues an AAR. After receiving this AAR, = > how could my Diameter base process determine that this AAR is for = > local Wm application, but not for local NASREQ application? > = > > Thanks in anticipation, > Martin = > = > = > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = -- = Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 9 09:03:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79E43A6D27; Tue, 9 Sep 2008 09:03:37 -0700 (PDT) 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 C2D513A6D2A for ; Tue, 9 Sep 2008 09:03:36 -0700 (PDT) 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 WffElH7nCe4C for ; Tue, 9 Sep 2008 09:03:36 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id 98F843A6D27 for ; Tue, 9 Sep 2008 09:03:35 -0700 (PDT) Received: from [88.112.206.46] (a88-112-206-46.elisa-laajakaista.fi [88.112.206.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 2B82C216A61; Tue, 9 Sep 2008 19:03:29 +0300 (EEST) In-Reply-To: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Jouni Korhonen Date: Tue, 9 Sep 2008 19:02:55 +0300 To: "Jacob Martin" X-Mailer: Apple Mail (2.753.1) Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jacob, I assume by Wm you mean the 3GPP TS 29.234 specified Wm interface? Btw, Wm is not an "application", rather a name of a specific reference point between two nodes. You can also see it as a "profile" compliant with NASREQ or EAP. Anyway, you NAS device, i.e. the PDG knows that it wants to authorize a certain user to a specific APN and adds required AVPs to the AAR to accomplish this. The AAA server receiving the AAR needs to do "further checking" against the message it received. So it falls back to dictionary type of matching of AVPs. There are Wm specific AVPs such as 3GPP-WLAN-APN-ID. Once the server finds one in the AAR it can be sure this is about WM and authorizing the user to a specific APN. For other possible uses of Wm you need to do similar checking of AVPs in the received message. Hope this helps. Cheers, Jouni On Sep 9, 2008, at 11:14 AM, Jacob Martin wrote: > Hi, > > I am a bit confused about the feasibility of one specific > configuration in Diameter. > > Please look at the diagram below: > > > | > | > | > | > Local Node | > | +----+ +-------+ > | |NAS | | Wm | > +--------+ +--------+ | +----+ +-------+ > | | | | | | --- > |NASREQ | | Wm | | | --- > +----\---+ +---/----+ | +----- -- > \ // | //// \\\\\ > \ // | |/ | > \ // | | PEER | > +---\-/------+ | | | > | | | |\ | > |Diameter | | \\\\ ///// > |Base process| | ------ > +----+-------+ | | > | | | > | | | > +------------------+-------------+ > > I wish to provide support for two applications on my local node > i.e NASREQ and Wm. As per Wm specifications, Wm should reuse the > application identifier of EAP/NASREQ. So, in CEA, I have advertised > '1' and '5' as the applications supported. > > Assume that peer node also has the same configuration as of mine > i.e it also support Wm and NAS applications. > > Now, peer Wm application issues an AAR. After receiving this AAR, > how could my Diameter base process determine that this AAR is for > local Wm application, but not for local NASREQ application? > > > Thanks in anticipation, > Martin > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 9 10:03:54 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3586628C1CD; Tue, 9 Sep 2008 10:03:54 -0700 (PDT) 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 6250628C1BC for ; Tue, 9 Sep 2008 10:03:53 -0700 (PDT) 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 wAbeRGliQYvk for ; Tue, 9 Sep 2008 10:03:52 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 79E4528C1CD for ; Tue, 9 Sep 2008 10:03:52 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id CbJa1a0040S2fkCA7h3wmg; Tue, 09 Sep 2008 17:03:56 +0000 Received: from gwzPC ([12.189.117.131]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id Ch3K1a00V2qAnck8Vh3kJj; Tue, 09 Sep 2008 17:03:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=dTz7hSLLoMyeyrlgxbsA:9 a=1MDW4kl21G8-5Kn_ykEA:7 a=WdCqI1-h8BiY81wpacWTs0DipfQA:4 a=lZB815dzVvQA:10 a=BDXKcin-EtgA:10 From: "Glen Zorn" To: "'Sebastien Decugis'" , "'Jacob Martin'" References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> In-Reply-To: <48C657BB.4050103@nict.go.jp> Date: Tue, 9 Sep 2008 10:02:52 -0700 Message-ID: <000001c9129d$f1dc4580$d594d080$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckSbDt0iFoJIgJUScuXOEt5yVDdbQALcdPw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > Hello, > = > I think the Application Id in the command header will contain the > appropriate identifier to route the message to the correct handler... The Application Identifiers are specified to be identical. What are you talking about? > = > Best regards, > Sebastien. > = > Jacob Martin a =E9crit : > > > > Hi, > > > > I am a bit confused about the feasibility of one specific > > configuration in Diameter. > > > > Please look at the diagram below: > > > > > > | > > | > > | > > | > > Local Node | > > | +----+ +-------+ > > | |NAS | | Wm | > > +--------+ +--------+ | +----+ +-------+ > > | | | | | | --- > > |NASREQ | | Wm | | | --- > > +----\---+ +---/----+ | +----- -- > > \ // | //// \\\\\ > > \ // | |/ | > > \ // | | PEER | > > +---\-/------+ | | | > > | | | |\ | > > |Diameter | | \\\\ ///// > > |Base process| | ------ > > +----+-------+ | | > > | | | > > | | | > > +------------------+-------------+ > > > > I wish to provide support for two applications on my local node > i.e > > NASREQ and Wm. As per Wm specifications, Wm should reuse the > > application identifier of EAP/NASREQ. So, in CEA, I have advertised > > '1' and '5' as the applications supported. > > > > Assume that peer node also has the same configuration as of mine > > i.e it also support Wm and NAS applications. > > > > Now, peer Wm application issues an AAR. After receiving this AAR, > > how could my Diameter base process determine that this AAR is for > > local Wm application, but not for local NASREQ application? > > > > > > Thanks in anticipation, > > Martin > > > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > = > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > = > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 9 18:29:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CBB3A69C4; Tue, 9 Sep 2008 18:29:52 -0700 (PDT) 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 0385C3A6882 for ; Tue, 9 Sep 2008 18:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.417 X-Spam-Level: ** X-Spam-Status: No, score=2.417 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5NHegqi9w+Q for ; Tue, 9 Sep 2008 18:29:50 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by core3.amsl.com (Postfix) with ESMTP id CA6BE3A69C4 for ; Tue, 9 Sep 2008 18:29:49 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id m8A1PoG4003961; Wed, 10 Sep 2008 10:25:50 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m8A1PoV1019926; Wed, 10 Sep 2008 10:25:50 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m8A1PnH5019921; Wed, 10 Sep 2008 10:25:49 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 8C69844CB; Wed, 10 Sep 2008 10:25:49 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id 468A444A7; Wed, 10 Sep 2008 10:25:49 +0900 (JST) Message-ID: <48C721D8.1030401@nict.go.jp> Date: Wed, 10 Sep 2008 10:24:40 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Glen Zorn References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <000001c9129d$f1dc4580$d594d080$@net> In-Reply-To: <000001c9129d$f1dc4580$d594d080$@net> X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > The Application Identifiers are specified to be identical. What are you > talking about? > I didn't know what 'Wm' refers to, and since in the original post it was specified as " two applications i.e NASREQ and Wm" I assumed the application-id would be different... I guess I was mistaken, sorry! Sebastien. (still learning about Diameter...) -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 9 22:03:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10A83A68BA; Tue, 9 Sep 2008 22:03:07 -0700 (PDT) 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 2965C3A68BA for ; Tue, 9 Sep 2008 22:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 8Cky1rP2-Nvw for ; Tue, 9 Sep 2008 22:03:05 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.249]) by core3.amsl.com (Postfix) with ESMTP id 1586B3A687B for ; Tue, 9 Sep 2008 22:03:05 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so6365355agb.12 for ; Tue, 09 Sep 2008 22:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2Wwu+/q15DnxfJuM8dDRwVUHNtRriWyTp882wMVBazU=; b=OUEyDJs7NBDDLjQIuXxS9lsgdpRAgya20fUKpMic96EiSoV4sb7TexNuT4oxukF9fp 6pdgC99qwaKUJ0DevO3ECFsmsPkfYh8oev7+B0K29Goe3SST8MnwhYVSTyHmOQeF2hJt Mtzq1GOaX5S+zZWx9f/hoY/AlDfW+KSKMepOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=V3gkpTBboRWx+0LnCYrbf+fiSTgsNU363f2lvLdwEShBOmDyaM71hvCRp3wBvH7g09 UbQ9vy59ZFqm6LwDJo7Ql0sb/wDOFiIvq8fFPPRoN+GYMaYx9v0FI14LZK5bfbINYV5g dIe+Z9s2q6tabdiHATXSs5yg+Igo3QRgh7Hwg= Received: by 10.70.66.18 with SMTP id o18mr691312wxa.66.1221022982626; Tue, 09 Sep 2008 22:03:02 -0700 (PDT) Received: by 10.70.9.11 with HTTP; Tue, 9 Sep 2008 22:03:02 -0700 (PDT) Message-ID: <9ad5b0030809092203h2c93ce05paa7185f59cefa089@mail.gmail.com> Date: Wed, 10 Sep 2008 10:33:02 +0530 From: "Jacob Martin" To: "Jouni Korhonen" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jouni, On 9/9/08, Jouni Korhonen wrote: > Hi Jacob, > > I assume by Wm you mean the 3GPP TS 29.234 specified Wm interface? Yes, I meant the same > Btw, Wm is not an "application", rather a name of a specific > reference point between two nodes. You can also see it as a > "profile" compliant with NASREQ or EAP. Ok. > > Anyway, you NAS device, i.e. the PDG knows that it wants to > authorize a certain user to a specific APN and adds required AVPs > to the AAR to accomplish this. The AAA server receiving the AAR > needs to do "further checking" against the message it received. So > it falls back to dictionary type of matching of AVPs. There are > Wm specific AVPs such as 3GPP-WLAN-APN-ID. Once the server finds > one in the AAR it can be sure this is about WM and authorizing the > user to a specific APN. For other possible uses of Wm you need to > do similar checking of AVPs in the received message. hmm...It makes sense to follow this approach. I would look at the AVPs which could clearly distinguish Wm/NAS/EAP requests/responses. > > Hope this helps. > > Cheers, > Jouni > > > On Sep 9, 2008, at 11:14 AM, Jacob Martin wrote: > >> Hi, >> >> I am a bit confused about the feasibility of one specific >> configuration in Diameter. >> >> Please look at the diagram below: >> >> >> | >> | >> | >> | >> Local Node | >> | +----+ +-------+ >> | |NAS | | Wm | >> +--------+ +--------+ | +----+ +-------+ >> | | | | | | --- >> |NASREQ | | Wm | | | --- >> +----\---+ +---/----+ | +----- -- >> \ // | //// \\\\\ >> \ // | |/ | >> \ // | | PEER | >> +---\-/------+ | | | >> | | | |\ | >> |Diameter | | \\\\ ///// >> |Base process| | ------ >> +----+-------+ | | >> | | | >> | | | >> +------------------+-------------+ >> >> I wish to provide support for two applications on my local node >> i.e NASREQ and Wm. As per Wm specifications, Wm should reuse the >> application identifier of EAP/NASREQ. So, in CEA, I have advertised >> '1' and '5' as the applications supported. >> >> Assume that peer node also has the same configuration as of mine >> i.e it also support Wm and NAS applications. >> >> Now, peer Wm application issues an AAR. After receiving this AAR, >> how could my Diameter base process determine that this AAR is for >> local Wm application, but not for local NASREQ application? >> >> >> Thanks in anticipation, >> Martin >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > Cheers, Martin _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 10 06:57:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA103A6D8B; Wed, 10 Sep 2008 06:57:48 -0700 (PDT) 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 7A7203A6D8A for ; Wed, 10 Sep 2008 06:57:47 -0700 (PDT) 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 x3shwASQS5Cc for ; Wed, 10 Sep 2008 06:57:42 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 164533A6D81 for ; Wed, 10 Sep 2008 06:57:41 -0700 (PDT) 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 m8ADvjeU079773; Wed, 10 Sep 2008 09:57:46 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48C7D253.4010908@tari.toshiba.com> Date: Wed, 10 Sep 2008 09:57:39 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <20080908134501.E51BA3A69B5@core3.amsl.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A21C0@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3031A21C0@SEHAN021MB.tcad.telia.se> Cc: dime@ietf.org Subject: Re: [Dime] About draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, Sorry for the late reply. > Hi, > > Few quick notes on -12: > > o Section 4.4 > > I don't recall an agreement of replacing the: > > "..MAY simply be ignored if the Grouped AVP itself is unrecognized. > However, the encapsulated AVPs with 'M' (mandatory) bit set MUST > belong to the Diameter application the Grouped APV is used in. The > rule applies even if the encapsulated AVP with its 'M' (mandatory).. > " > > with > > "..MAY simply be ignored if the Grouped AVP itself is unrecognized. > The > rule applies even if the encapsulated AVP with its 'M' (mandatory).. > " > > The new text allows me "legally" send AVPs with 'M'-bit set that do > not > belong to the application. I don't want such functionality! > Agree. It make sense to keep this rule. > o Section 7.1.5 > > s/recognize or doest not support/recognize or does not support > Ok. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 11 06:51:22 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185FF3A6B6A; Thu, 11 Sep 2008 06:51:22 -0700 (PDT) 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 D7D1B3A6959 for ; Thu, 11 Sep 2008 06:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[AWL=-1.424, BAYES_40=-0.185, J_CHICKENPOX_73=0.6, RCVD_IN_SORBS_WEB=0.619, URI_HEX=0.368] 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 w9W5jBg8baCy for ; Thu, 11 Sep 2008 06:51:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9088E3A6907 for ; Thu, 11 Sep 2008 06:51:19 -0700 (PDT) Received: (qmail invoked by alias); 11 Sep 2008 13:51:24 -0000 Received: from unknown (EHLO [10.183.181.140]) [192.100.124.156] by mail.gmx.net (mp040) with SMTP; 11 Sep 2008 15:51:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19h+TxU6wJhmboLPZOlfIYZUEHv/xDxfnvCFz9e5/ x0MPVcMWJ/THci Message-ID: <48C92258.6050008@gmx.net> Date: Thu, 11 Sep 2008 16:51:20 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Subject: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --- I noticed that my mail did not make it to the list because it is too large. Hi Victor, as I am the PROTO shepherd for this document I had todo a review of the document before it leaves the working group. I did it based on the -11 version but I noticed that you just published -12. Still, I wanted to submit my first round of comments. Many aspects are very easy to address since they are just editorial. I split my comments into three parts; this is the first part. Section 1.1: All data delivered by the protocol is in the form of an AVP. Some of these AVP values are used by the Diameter protocol itself, while Diameter base protocol others deliver data associated with particular applications that employ Diameter. AVPs may be added arbitrarily to Diameter messages, so long as the requirements of a message's ABNF are met and the ABNF allows for it. AVPs are used by the base Diameter protocol to Diameter base protocol support the following required features: o Exchanging resource usage information, which MAY be used for accounting purposes, capacity planning, etc. s/MAY/may A Diameter node MAY act as an agent for certain requests while acting as a server for others. s/MAY/may Section 1.1.1. I would shorten this section and just say the following: 1.1.1. Description of the Document Set The Diameter specification consists of an updated version of the base protocol specification (this document), Transport Profile [RFC3539] and various document defining new Diameter applications or extending existing applications. Note that this document obsoletes [RFC3588]. A summary of the base protocol updates included in this document can be found in Section 1.1.3. The Transport Profile document [RFC3539] discusses transport layer issues that arise with AAA protocols and recommendations on how to overcome these issues. This document also defines the Diameter failover algorithm and state machine. Since standardization efforts on Diameters are being entertained in various standardization organizations the list of Diameter applications is increasing steadily and providing a list of all Diameter applications is not provided in this document. Example applications can be found with Mobile IPv4 [RFC4004], NASREQ [RFC4005], Credit Control [RFC4006], EAP [RFC4072] and SIP [RFC4740]. 1.1.3. Changes from RFC3588 This document deprecates [RFC3588] but is fully backward compatible with that document. The changes introduced in this document focuses on fixing issues that has surfaced during implementation of s/has/have [RFC3588]. An overview of some the major changes are shown below. o Simplified Security Requirements. The use of a secured transport for exchanging diameter messages remains mandatory. However, TLS has become the primary method of securing diameter and IPSec is a secondary alternative. See Section 13 for details. Along with this, support for the End-to-End security framework (E2ESequence AVP and 'P'-bit in the AVP header) has also been deprecated. s/IPSec/IPsec s/support for/the support for o Diameter Extensibility Changes. This includes fixes to the diameter extensibility specification (Section 1.2 and others) to better aid diameter application designers. It also includes allocation of vendor specific command code space. The new specification relaxes the allocation of command codes for vendor specific uses. See Section 11.2.1 for details. s/diameter extensibility specification/Diameter extensibility description s/diameter application designers/Diameter application designers o Application Id Usage. Clarify the proper use of Application Id information which can be found in multiple places within a diameter message. This includes co-relating Application Ids found in the message headers and AVPs. These changes also clearly specifies the proper Application Id value to use for specific base protocol messages (ASR/ASA, STR/STA) as well as clarifying the content and use of Vendor-Specific-Application-Id. s/Clarify the proper use of Application Id information which can be found in multiple places within a diameter message. /Clarify the proper use of Application Id information, which can be found in multiple places within a Diameter message. o Simplification of Diameter Peer Discovery. The diameter discovery process now supports only well known discovery schemes. The rest has been deprecated. (See Section 5.2 for details). s/diameter/Diameter 1.3. Terminology Broker A broker is a business term commonly used in AAA infrastructures. A broker is either a relay, proxy or redirect agent, and MAY be operated by roaming consortiums. Depending on the business model, a broker may either choose to deploy relay agents or proxy agents. s/MAY/may Diameter Server A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. By its very nature, a Diameter Server MUST support Diameter server applications in addition to the base protocol. s/MUST/must Diameter Client A Diameter Client is a device at the edge of the network that performs access control. An example of a Diameter client is a Network Access Server (NAS) or a Foreign Agent (FA). By its very nature, a Diameter Client MUST support Diameter client applications in addition to the base protocol. s/MUST/must Local Realm A local realm is the administrative domain providing services to a user. An administrative domain MAY act as a local realm for certain users, while being a home realm for others. s/MAY/may Real-time Accounting Real-time accounting involves the processing of information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk. I would include a pointer to the DCCA spec here as it provides the real-time accounting functionality. Session A session is a related progression of events devoted to a particular activity. Each application SHOULD provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Identifier are considered to be part of the same session. s/Each application SHOULD provide guidelines as to when a session begins and ends. /Diameter application documents provide guidelines as to when ... User The entity requesting or using some resource, in support of which a Diameter client has generated a request. It might be worth noting that it does not necessary have to be a human. Instead, the NAI refers to some entity and this document refers to it as user. 2. Protocol Overview This section starts a bit strange. Here is my proposal on how to re-write it: The Diameter base protocol concerns itself with capabilities negotiation, how messages are sent and how peers may eventually be abandoned. The base protocol also defines certain rules that apply to all exchanges of messages between Diameter nodes. Communication between Diameter peers begins with one peer sending a message to another Diameter peer. The set of AVPs included in the message is determined by a particular Diameter application. One AVP that is included to reference a user's session is the Session-Id. The initial request for authentication and/or authorization of a user would include the Session-Id. The Session-Id is then used in all subsequent messages to identify the user's session (see Section 8 for more information). The communicating party may accept the request, or reject it by returning an answer message with the Result-Code AVP set to indicate an error occurred. The specific behavior of the Diameter server or client receiving a request depends on the Diameter application employed. Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination- Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular Diameter application. The base Diameter protocol, which includes accounting functionality, may be used by itself to offer accounting functionality to applications, but for use in authentication and authorization always requires a particular application. Diameter Clients MUST support the base protocol. In addition, they MUST fully support each Diameter application that is needed to implement the client's service, e.g., NASREQ. A Diameter Client that does not support both Application X and Application Y, MUST be referred to as "Diameter X Client" where X is the application which it supports, and not a "Diameter Client". Diameter Servers MUST support the base protocol. In addition, they MUST fully support each Diameter application that is needed to implement the intended service, e.g., NASREQ. A Diameter Server that does not support both Application X and Application Y, MUST be referred to as "Diameter X Server" where X is the application which it supports, and not a "Diameter Server". Diameter Relays and redirect agents are, by definition, protocol transparent, and MUST support the Diameter base protocol. Diameter proxies MUST support the base protocol. In addition, they MUST fully support each Diameter application that is needed to implement proxied services, e.g., NASREQ. A Diameter proxy which does not support also both Application X and Application Y, MUST be referred to as "Diameter X Proxy" where X is the application which it supports, and not a "Diameter Proxy". 2.1. Transport s/ Transport profile is defined in [RFC3539]./The Diameter Transport profile is defined in [RFC3539]./ s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] and SCTP [RFC2960] transport protocols./The base Diameter protocol is run on port 3868 of both TCP [RFC793] and SCTP [RFC2960]. Delete "Future versions of this specification MAY mandate that clients support SCTP." I also do not understand why we require that agents and servers must support SCTP. That does not sound realistic if I consider our interop testing experience. 2.2. Securing Diameter Messages s/IPSec/IPsec 2.3. Diameter Application Compliance For a given application, advertising support of an application implies that the sender supports all command codes, and the AVPs specified in the associated ABNFs, described in the specification. I don't think that this is true. Whether a specific AVP has to be implemented by either the sender is essentially up to the definition of the application specification. As such, I would rather say: For a given application, advertising support of an application implies that the sender supports the functionality specified in the respective Diameter application specification. 2.4. Application Identifiers The following Application Id values are defined: Diameter Common Messages 0 NASREQ 1 [RFC4005] Mobile-IP 2 [RFC4004] Diameter Base Accounting 3 Relay 0xffffffff I don't understand why the Diameter base protocol spec needs to list the application Ids of NASREQ and Mobile-IP. I suggest to delete them in the above table to something like this: The following Application Id values are defined in this document: Diameter Common Messages 0 Diameter Base Accounting 3 Relay 0xffffffff 2.5. Connections vs. Sessions s/ A connection is a transport level connection between two peers, used to send and receive Diameter messages. / A connection refers to a transport level connection between two peers that is used to send and receive Diameter messages. s/ A session is a logical concept at the application layer, and is shared between an access device and a server, and is identified via the Session-Id AVP. / A session is a logical concept at the application layer, it spawns from the Diameter client to the Diameter server and is identified via the Session-Id AVP. s/ In the example provided in Figure 1, peer connection A is established between the Client and its local Relay. / In the example provided in Figure 1, peer connection A is established between the Client and the Relay. 2.7. Routing Table s/ 1. LOCAL - Diameter messages that resolve to a route entry with the Local Action set to Local can be satisfied locally, and do not need to be routed to another server. / 1. LOCAL - Diameter messages that can be satisfied locally, and do not need to be routed to another Diameter entity. s/ 2. RELAY - All Diameter messages that fall within this category MUST be routed to a next hop server, without modifying any non-routing AVPs. See Section 6.1.9 for relaying guidelines / 2. RELAY - All Diameter messages that fall within this category MUST be routed to a next hop Diameter entity that is indicated by the identifier described below, without modifying any non-routing AVPs. See Section 6.1.9 for relaying guidelines s/ 3. PROXY - All Diameter messages that fall within this category MUST be routed to a next hop server. The local server MAY apply its local policies to the message by including new AVPs to the message prior to routing. See Section 6.1.9 for proxying guidelines. / 3. PROXY - All Diameter messages that fall within this category MUST be routed to a next Diameter entity that is indicated by the identifier described below. The local server MAY apply its local policies to the message by including new AVPs to the message prior to routing. See Section 6.1.9 for proxying guidelines. Server Identifier One or more servers the message is to be routed to. These servers MUST also be present in the Peer table. When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) the message must be routed to. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers the message should be redirected to. Shouldn't it say ".. the message MUST be routed to." and why is there a should and not a MUST in the last sentence? s/ Relay agents MUST NOT reorder AVPs, and proxies MUST NOT reorder AVPs. / Relay agents and proxies MUST NOT reorder AVPs. 2.8. Role of Diameter Agents s/ Maintaining session state MAY be useful in certain applications, such as: / Maintaining session state may be useful in certain applications, such as: 2.8.1. Relay Agents s/ Relays MAY be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (POP). / Relays may, for example, be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (POP). I think we can delete this sentence since it essentially reflects the definition of a relay: Relays SHOULD NOT maintain session state but MUST maintain transaction state. 2.8.2. Proxy Agents s/ Proxies MAY be used in call control centers or access ISPs that provide outsourced connections, they can monitor the number and types of ports in use, and make allocation and admission decisions according to their configuration. / Proxies may, for example, be used in call control centers or access ISPs that provide outsourced connections, they can monitor the number and types of ports in use, and make allocation and admission decisions according to their configuration. Proxies that wish to limit resources MUST maintain session state. All proxies MUST maintain transaction state. I don't really understand what the first sentence should tell us and the 2nd one is essentially already described with the definition of the proxy. 2.8.3. Redirect Agents s/ Since redirect agents do not receive answer messages, they cannot maintain session state. Further, since redirect agents never relay requests, they are not required to maintain transaction state. / Since redirect agents do not receive answer messages, they cannot maintain session and transaction state. 3.2. Command Code ABNF specification s/ Every Command Code defined MUST include a corresponding ABNF specification, which is used to define the AVPs that MUST or MAY be present. / Every Command Code defined MUST include a corresponding ABNF specification, which is used to define the AVPs that MUST or MAY be present when sending the message. 3.3. Diameter Command Naming Conventions o An additional request MUST be sent to provide information the peer requires prior to returning a successful or failed answer. s/MUST/has to be Additional information, encoded within AVPs, MAY also be included in answer messages. s/MAY/may Some AVPs MAY be listed more than once. The effect of such an AVP is specific, and is specified in each case by the AVP description. There is something wrong with this sentence. 4.1. AVP Header AVP Flags The 'P' bit indicates the need for encryption for end-to-end security. Note that the 'P' bit has been deprecated and MUST be to zero(0) when sending an AVP and ingnored on receipt of an AVP. Instead of the above, I think it should say: The 'P' bit has been reserved for future usage of end-to-end security. At the time of writing there are no end-to-end security mechanisms specified. The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. We changed this already. New text proposal: The 'M' Bit, known as the Mandatory bit, indicates whether the receiver of the AVP MUST understand the received AVP and the content of the AVP. When the receiving entity MUST return an appropriate error message if it receives an AVP that has the M-bit set but does not understand it. AVP Length If a message is received with an invalid attribute length, the message SHOULD be rejected. Why is this only a SHOULD level recommendation? What should the receiver do otherwise? 4.1.1. Optional Header Elements Vendor-ID Any vendor wishing to implement a vendor-specific Diameter AVP MUST use their own Vendor-ID along with their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-specific AVP(s), nor with future IETF applications. s/Any vendor .../Any vendor or standardization organization that are also treated like vendors in the IANA managed"SMI Network Management Private Enterprise Codes" space ... s/nor with future IETF applications./nor with future IETF AVPs. 4.3. Derived AVP Data Formats In addition to using the Basic AVP Data Formats, applications may define data formats derived from the Basic AVP Data Formats. An application that defines new AVP Derived Data Formats MUST include them in a section entitled "AVP Derived Data Formats", using the same format as the definitions below. Each new definition MUST be either defined or listed with a reference to the RFC that defines the format. This is sort of interesting, particularly when you look at the IPFilterRule, as the boundary between Derived AVP Data Formats and AVP definitions is sort of fuzzy. Does any other Diameter document ever tried to define new derived Data Formats? Time The Time format is derived from the OctetString AVP Base Format. The string MUST contain four octets, in the same format as the first four bytes are in the NTP timestamp format. The NTP Timestamp format is defined in chapter 3 of [RFC4330]. s/chapter/Chapter This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. SNTP [RFC4330] describes a procedure to extend the time to 2104. This procedure MUST be supported by all DIAMETER nodes. s/DIAMETER/Diameter 4.4. Grouped AVP Values However, the encapsulated AVPs with 'M' (mandatory) bit set MUST belong to the Diameter application the Grouped APV is used in. I don't quite understand that sentence. Could you explain it a bit? 5.1. Peer Connections Delete the following paragraph since it does not say anything In order to promote interoperable implementations of Diameter peer discovery, the following mechanisms are described. These are based on existing IETF standards. The first option (manual configuration) MUST be supported by all DIAMETER nodes, while the latter option (DNS) MAY be supported. s/DIAMETER/Diameter 5.2. Diameter Peer Discovery s/ We also establish an IANA registry for NAPTR service name to transport protocol mappings. / An IANA registry for NAPTR service name to transport protocol mappings is defined in Section 11.6. 3. If no NAPTR records are found, the requester queries for those address records for the destination address, '_diameter._sctp'.realm or '_diameter._tcp'.realm. Why is it necessary to specify two mechanisms to query the DNS? I will distribute a separate mail about the domain certificate stuff. 5.3.5. Host-IP-Address AVP The Host-IP-Address AVP (AVP Code 257) is of type Address and is used to inform a Diameter peer of the sender's IP address. All source addresses that a Diameter node expects to use with SCTP [RFC2960] MUST be advertised in the CER and CEA messages by including a Host-IP- Address AVP for each address. This AVP MUST ONLY be used in the CER and CEA messages. s/Host-IP- Address/Host-IP-Address I wonder why there is the last sentence in there? It is fine to use the AVP in the CER and CEA message but why is there a need to say that it must only be used there? That does not make a lot of sense. 5.3.6. Supported-Vendor-Id AVP Multiple instances of this AVP containing the same value SHOULD NOT be sent. Why not MUST NOT be sent? I was also wondering why only a selection of AVPs is listed in Section 5.3 instead of all of them? Any special reason? 5.5.4. Failover and Failback Procedures Shouldn't it actually read "Fallback" instead of failback? 6.1. Diameter Request Routing Overview I would change text a bit by modifying this paragraph: o a request that needs to be sent to a home server serving a specific realm, but not to a specific server (such as the first request of a series of round-trips), MUST contain a Destination- Realm AVP, but MUST NOT contain a Destination-Host AVP. For Diameter clients, the value of the Destination-Realm AVP MAY be extracted from the User-Name AVP, or other methods. and by deleting this paragraph: The Destination-Realm AVP MUST be present if the message is proxiable. A message that MUST NOT be forwarded by Diameter agents (proxies, redirects or relays) MUST NOT include the Destination-Realm in its ABNF. For Diameter clients, the value of the Destination- Realm AVP MAY be extracted from the User-Name AVP, or other application-specific methods. 6.1.2. Sending a Request When sending a request, originated either locally, or as the result of a forwarding or routing operation, the following procedures MUST be followed: o the Hop-by-Hop Identifier should be set to a locally unique value. s/should/SHOULD o The message should be saved in the list of pending requests. s/should/SHOULD Given that the introductory sentence says "MUST be followed" I was wondering whether SHOULD is actually too weak here. 6.1.6. Request Routing Diameter request message routing is done via realms and applications. A Diameter message that may be forwarded by Diameter agents (proxies, redirects or relays) MUST include the target realm in the Destination-Realm AVP. s/applications/application identifiers s/redirects/redirect agents Realm names and Application Ids are the minimum supported routing criteria, additional routing information maybe needed to support redirect semantics. s/routing information/information s/maybe/may be 6.1.8. Redirecting requests s/Redirecting requests/ Redirecting Requests In such a case, a routing precedence rule MUST be used againt the redirect usage value to resolve the contention. s/againt/against 6.1.9. Relaying and Proxying Requests Proxy-Info AVP has certain security implications and SHOULD contain an embedded HMAC with a node-local key. I suspect that you mean protecting the content in similar fashion as it is done with a cookie. Maybe something like " The Proxy-Info AVP has security implications as state information is distribute to other entities. As such, it is RECOMMMENDED to protect the content of the Proxy-Info AVP with cryptographic mechanisms, for example by using a keyed message digest. Such a mechanism, however, requires the management of keys, although only locally at the Diameter server. Still, a full description of the management of the keys used to protect the Proxy-Info AVP is beyond the scope of this document. Below is a list of commonly recommended: o The keys should be generated securely following the randomness recommendations in [RFC4086]. o The keys and cryptographic protection algorithms should be at least 128 bits in strength. o The keys should not be used for any other purpose than generating and verifying tickets. o The keys should be changed regularly. o The keys should be changed if the ticket format or cryptographic protection algorithms change. " would be more appropriate. 6.1.9. Relaying and Proxying Requests Relay and proxy agents are not required to perform full validation of incoming messages. s/validation/inspection 6.2.2. Relaying and Proxying Answers If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST modify the Result-Code AVP to contain the appropriate error in the message destined towards the access device as well as include the Error-Reporting-Host AVP and it MUST issue an STR on behalf of the access device. extend the sentence by saying ".. towards the Diameter server." 6.7.2. Proxy-Info AVP The description for the AVP does not describe the semantic. 6.7.4. Proxy-State AVP s/ The Proxy-State AVP (AVP Code 33) is of type OctetString, and contains state local information, and MUST be treated as opaque data. / The Proxy-State AVP (AVP Code 33) is of type OctetString, and is created by the Diameter server and passed on to the Diameter client. It contains state information that would otherwise be stored at the Diameter. As such, this AVP MUST be treated as opaque data by entities other than the Diameter server that created it. 6.8. Auth-Application-Id AVP The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used in order to advertise support of the Authentication and Authorization portion of an application (see Section 2.4). If present in a message other than CER and CEA, the value of the Auth- Application-Id AVP MUST match the Application Id present in the Diameter message header. If it always matches then does it make a lot of sense? 6.10. Inband-Security-Id AVP The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and is used in order to advertise support of the Security portion of the application. s/Security/security 6.11. Vendor-Specific-Application-Id AVP The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one instance of either Auth- Application-Id or Acct-Application-Id AVP MUST be present. We should say where it must be present. The Application Id carried by either Auth-Application-Id or Acct- Application-Id AVP MUST comply with vendor specific Application Id assignment described in Sec 11.3. It MUST also match the Application Id present in the diameter header except when used in a CER or CEA messages. s/diameter/Diameter This AVP MUST also be present as the first AVP in all experimental commands defined in the vendor-specific application. This AVP SHOULD be placed as close to the Diameter header as possible. "This" in the above two sentences refers to the Vendor-Specific-Application-Id AVP. Right? If a Vendor-Specific-Application-Id is received that contains both Auth-Application-Id and Acct-Application-Id, then the recipient SHOULD issue an answer with Result-Code set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer SHOULD also include a Failed-AVP which MUST contain the received Auth-Application-Id AVP and Acct-Application-Id AVP. Why are these only SHOULD level requirements? What happens in the other cases? 6.13. Redirect-Host-Usage AVP When present, this AVP dictates how the routing entry resulting from the Redirect-Host is to be used. The following values are supported: s/dictates/provides a hint about Dictate is really not the right term given that everything below is fluffy. Another term that would come to my mind is "provides a suggestion about" DONT_CACHE 0 The host specified in the Redirect-Host AVP should not be cached. This is the default value. s/should not/SHOULD NOT?? ALL_SESSION 1 All messages within the same session, as defined by the same value of the Session-ID AVP MAY be sent to the host specified in the Redirect-Host AVP. s/MAY/SHOULD ALL_REALM 2 All messages destined for the realm requested MAY be sent to the host specified in the Redirect-Host AVP. s/MAY/SHOULD REALM_AND_APPLICATION 3 All messages for the application requested to the realm specified MAY be sent to the host specified in the Redirect-Host AVP. s/MAY/SHOULD ALL_APPLICATION 4 All messages for the application requested MAY be sent to the host specified in the Redirect-Host AVP. s/MAY/SHOULD ALL_HOST 5 All messages that would be sent to the host that generated the Redirect-Host MAY be sent to the host specified in the Redirect- Host AVP. s/MAY/SHOULD ALL_USER 6 All messages for the user requested MAY be sent to the host specified in the Redirect-Host AVP. s/MAY/SHOULD 6.14. Redirect-Max-Cache-Time AVP This AVP contains the maximum number of seconds the peer and route table entries, created as a result of the Redirect-Host, will be cached. Note that once a host created due to a redirect indication is no longer reachable, any associated peer and routing table entries MUST be deleted. "will be cached" does not provide a good indication how the value provided by this AVP should actually be treated. Is this * MUST be cached * SHOULD cached * MAY be cached I think that the semantic is a bit weak. What can the sender really expect when it provides a value with AVP to the receiver? 7. Error Handling Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application (e.g., user authentication, Missing AVP). s/Missing AVP/missing AVP o A command is received with an AVP that is omitted, yet is mandatory according to the command's ABNF. s/mandatory/required 7.1. Result-Code AVP The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a particular request was completed successfully or whether an error occurred. All Diameter answer messages defined in IETF applications MUST include one Result-Code AVP. s/IETF applications/IETF defined Diameter application specifications 7.1.2. Success DIAMETER_SUCCESS 2001 The Request was successfully completed. s/Request/request 7.1.3. Protocol Errors s/ To provide backward compatibility with existing implementations that follow [RFC3588], some of the error values that have previously been used in this category by [RFC3588] will not be re-used. Therefore the error values enumerated here may be non-sequential. / This document omits some error codes defined in RFC 3588 [RFC3588]. To provide backward compatibility with RFC 3588 implementations these error code values are not re-used and hence the error codes values enumerated below are non-sequential. DIAMETER_REDIRECT_INDICATION 3006 A redirect agent has determined that the request could not be satisfied locally and the initiator of the request should direct the request directly to the server, whose contact information has been added to the response. When set, the Redirect-Host AVP MUST be present. s/should/SHOULD DIAMETER_NO_COMMON_APPLICATION 5010 This error is returned by a Diameter node that is not acting as a relay when it receives a CER which advertises a set of applications that it does not support. Why not saying something like: " This error is returned by a Diameter node that receives a CER whereby no applications are common between the CER sending peer and the CER receiving peer. DIAMETER_INVALID_AVP_LENGTH 5014 The request contained an AVP with an invalid length. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. In cases where the erroneous avp length value exceeds the message length or is less than the minimum AVP header length, it is sufficient to include the offending AVP header and a zero filled payload of the minimum required length for the payloads data type. If the AVP is a grouped AVP, the grouped AVP header with an empty payload would be sufficient to indicate the offending AVP. In the case where the offending AVP header cannot be fully decoded when avp length is less than the minimum AVP header length, it is sufficient to include an offending AVP header that is formulated by padding the incomplete AVP header with zero up to the minimum AVP header length. s/avp/AVP s/when avp length/when the AVP length DIAMETER_COMMAND_UNSUPPORTED 5019 The Request contained a Command-Code that the receiver did not recognize or support. This MUST be used when a Diameter node receives an experimental command that it does not understand. What about: " This error code is used when a Diameter entity receives a message with a Command Code that it does not support. " 7.3. Error-Message AVP s/ The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY accompany a Result-Code AVP as a human readable error message. The Error-Message AVP is not intended to be useful in real-time, and SHOULD NOT be expected to be parsed by network entities. / .. to be useful in an environment where error messages are processed automatically. It SHOULD NOT be expected that the content of this AVP is parsed by network entities. 7.6. Experimental-Result AVP The Experimental-Result AVP (AVP Code 297) is of type Grouped, and indicates whether a particular vendor-specific request was completed successfully or whether an error occurred. Its Data field has the following ABNF grammar: s/ Its Data field has the following ABNF grammar: / This AVP has the following structure: 8. Diameter User Sessions However, the base protocol does define a set of messages that is used to terminate user sessions. These are used to allow servers that maintain state information to free resources. s/is used/are used Diameter may also be used for services that cannot be easily categorized as authentication, authorization or accounting (e.g., certain 3GPP IMS interfaces). In such cases, the finite state machine defined in subsequent sections may not be applicable. Therefore, the applications itself MAY need to define its own finite state machine. However, such application specific state machines MUST comply with general Diameter user session requirements such co- relating all message exchanges via Session-Id AVP. What specifically is meant by saying that such applications must comply with the general Diameter user session requirements? 8.2. Accounting Session State Machine s/ Implementations of Diameter MAY perform checking, ordering, correlation, fraud detection, and other tasks based on these records. Both base Diameter AVPs as well as application specific AVPs MAY be inspected as a part of these tasks. / Implementations of Diameter may perform checking, ordering, correlation, fraud detection, and other tasks based on these records. AVPs may need to be inspected as a part of these tasks. 8.4.1. Session-Termination-Request The Session-Termination-Request (STR), indicated by the Command-Code set to 275 and the Command Flags' 'R' bit set, is sent by the access device to inform the Diameter Server that an authenticated and/or authorized session is being terminated. s/access device/the Diameter client or by a Diameter proxy 8.5. Aborting a Session s/ For example, the Diameter server that originally authorized the session may be required to cause that session to be stopped for credit or other reasons that were not anticipated when the session was first authorized. On the other hand, an operator may maintain a management server for the purpose of issuing ASRs to administratively remove users from the network. / For example, the Diameter server that originally authorized the session may be required to cause that session to be stopped for lack of credit or other reasons that were not anticipated when the session was first authorized. I would delete the following paragraph: " Note that if the access device does stop the session upon receipt of an ASR, it issues an STR to the authorizing server (which may or may not be the agent issuing the ASR) just as it would if the session were terminated for any other reason. " 8.5.1. Abort-Session-Request The Abort-Session-Request (ASR), indicated by the Command-Code set to 274 and the message flags' 'R' bit set, may be sent by any server to the access device that is providing session service, to request that the session identified by the Session-Id be stopped. The text talks about "any server". I guess it is more saying "Diameter server or Diameter proxy" 8.6. Inferring Session Termination from Origin-State-Id this section is a bit confusing as it talks about CER/CEA and the hop-by-hop processing but then refers to end-to-end processing as well. 8.7. Auth-Request-Type AVP The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is included in application-specific auth requests to inform the peers whether a user is to be authenticated only, authorized only or both. Note any value other than both MAY cause RADIUS interoperability issues. What are the RADIUS interoperability issues? 8.8. Session-Id AVP accesspoint7.acme.com;1876543210;523 Example, in which there is an optional value: accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88 I believe examples now have to use something like "example.com" rather than the above. The Session-Id is created by the Diameter application initiating the session, which in most cases is done by the client. Note that a Session-Id MAY be used for both the authorization and accounting commands of a given application. Shouldn't it say ... be used for the authentication, authorization and accounting commands of a given app. 8.9. Authorization-Lifetime AVP This is typically used in cases where multiple authentication methods are used, and a successful auth response with this AVP set to zero is used to signal that the next authentication method is to be immediately initiated. Where is this used? This AVP MAY be provided by the client as a hint of the maximum lifetime that it is willing to accept. However, the server MAY return a value that is equal to, or smaller, than the one provided by the client. There are many MAYs in there. Does it mean that a value that is larger can also be provided by the server? If not, then shouldn't the second sentence say MUST? 8.17. Session-Binding AVP s/ The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY be present in application-specific authorization answer messages. If present, this AVP MAY inform the Diameter client that all future application-specific re-auth messages for this session MUST be sent to the same authorization server. This AVP MAY also specify that a Session-Termination-Request message for this session MUST be sent to the same authorizing server. / The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY be present in application-specific authorization answer messages. If present, this AVP MAY inform the Diameter client that all future application-specific re-auth and Session-Termination-Request messages for this session MUST be sent to the same authorization server. --- stop here ---- more later. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 00:33:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3AF28C18D; Fri, 12 Sep 2008 00:33:17 -0700 (PDT) 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 EAD3228C18D for ; Fri, 12 Sep 2008 00:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 f9Kla7OQcMCb for ; Fri, 12 Sep 2008 00:33:16 -0700 (PDT) Received: from mail-gx0-f29.google.com (mail-gx0-f29.google.com [209.85.217.29]) by core3.amsl.com (Postfix) with ESMTP id C281F28C183 for ; Fri, 12 Sep 2008 00:33:15 -0700 (PDT) Received: by gxk10 with SMTP id 10so10307725gxk.13 for ; Fri, 12 Sep 2008 00:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=WYZ07UZJaKpbTbxHpHwWMzds5a5NjD9DUmA3lqrSxgo=; b=Ma67n0SIhDDF8PjQPW43k1+bsEDvuyC+os+63kZ/vy1kKZdeLfPb9Gh7rLLqRPYKnZ AHWVXi3jIkxBcKKtrA5IRr5FhlxQh/irCmsA1xVazW9+/F/XAHJRzS+1PrEQwJLPMBvS o20DFWbdif0d4sX84hHC+mLfYOurJW1Xw/DcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=dCVF90S/Vw6pC/NCkYTMWVy7tFDUYyDTBP9WvZsx7I6NhvGv1jhCnTFe8MDcfYEuV9 4a12BTV+I0p5gT6WEKoelJfEvdY2Q0ZcRJEn/iplp4uEV68St5lUON8rSmNUqBzAj1ag fg7MbBTR9aEheL12TclX43eIUO8yj3LiSWipo= Received: by 10.70.113.5 with SMTP id l5mr4072181wxc.69.1221204791716; Fri, 12 Sep 2008 00:33:11 -0700 (PDT) Received: by 10.70.19.2 with HTTP; Fri, 12 Sep 2008 00:33:11 -0700 (PDT) Message-ID: <9ad5b0030809120033q6fcc86b3pcea6b3274da7c296@mail.gmail.com> Date: Fri, 12 Sep 2008 13:03:11 +0530 From: "Jacob Martin" To: "Jouni Korhonen" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jouni, On 9/9/08, Jouni Korhonen wrote: > Hi Jacob, > > I assume by Wm you mean the 3GPP TS 29.234 specified Wm interface? > Btw, Wm is not an "application", rather a name of a specific > reference point between two nodes. You can also see it as a > "profile" compliant with NASREQ or EAP. > > Anyway, you NAS device, i.e. the PDG knows that it wants to > authorize a certain user to a specific APN and adds required AVPs > to the AAR to accomplish this. The AAA server receiving the AAR > needs to do "further checking" against the message it received. So > it falls back to dictionary type of matching of AVPs. There are > Wm specific AVPs such as 3GPP-WLAN-APN-ID. Once the server finds > one in the AAR it can be sure this is about WM and authorizing the > user to a specific APN. For other possible uses of Wm you need to > do similar checking of AVPs in the received message. I could identify AAR for Wm by looking at W-APN-ID or Routing Policy AVPs, but I am not able to find any such AVPs in DER command. In DER for Wm, "Visited Network Identifier" AVP is a new one, but its a conditional AVP. If PDG is in WLAN-UE's home network then this AVP would be absent. > > Hope this helps. > > Cheers, > Jouni > > > On Sep 9, 2008, at 11:14 AM, Jacob Martin wrote: > >> Hi, >> >> I am a bit confused about the feasibility of one specific >> configuration in Diameter. >> >> Please look at the diagram below: >> >> >> | >> | >> | >> | >> Local Node | >> | +----+ +-------+ >> | |NAS | | Wm | >> +--------+ +--------+ | +----+ +-------+ >> | | | | | | --- >> |NASREQ | | Wm | | | --- >> +----\---+ +---/----+ | +----- -- >> \ // | //// \\\\\ >> \ // | |/ | >> \ // | | PEER | >> +---\-/------+ | | | >> | | | |\ | >> |Diameter | | \\\\ ///// >> |Base process| | ------ >> +----+-------+ | | >> | | | >> | | | >> +------------------+-------------+ >> >> I wish to provide support for two applications on my local node >> i.e NASREQ and Wm. As per Wm specifications, Wm should reuse the >> application identifier of EAP/NASREQ. So, in CEA, I have advertised >> '1' and '5' as the applications supported. >> >> Assume that peer node also has the same configuration as of mine >> i.e it also support Wm and NAS applications. >> >> Now, peer Wm application issues an AAR. After receiving this AAR, >> how could my Diameter base process determine that this AAR is for >> local Wm application, but not for local NASREQ application? >> >> >> Thanks in anticipation, >> Martin >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > Cheers, Martin _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 00:37:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447ED28C129; Fri, 12 Sep 2008 00:37:01 -0700 (PDT) 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 6E1833A6BAE for ; Fri, 12 Sep 2008 00:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=-0.626, 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 0Hl6W0p7eQAm for ; Fri, 12 Sep 2008 00:36:58 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 078B23A6B57 for ; Fri, 12 Sep 2008 00:36:57 -0700 (PDT) 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 m8C7amix022883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 09:36:48 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8C7ajPr016744; Fri, 12 Sep 2008 09:36:48 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Sep 2008 09:36:42 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Sep 2008 09:36:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 10:36:39 +0300 Message-ID: In-Reply-To: <48C657BB.4050103@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Application-id reuse Thread-Index: AckSbD9/5tH0uKg3QaqR0ryNxP73twABcbgA References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sebastien Decugis" , "Jacob Martin" X-OriginalArrivalTime: 12 Sep 2008 07:36:41.0966 (UTC) FILETIME=[4CA530E0:01C914AA] Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jacob, = Your question addresses different aspects, namely * How does Diameter routing work in general? = This is described in Section 6.1 and Section 6.2 of = http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt This should give you an idea how the right node is found and how messages t= ravel back and forth. = * How does Diameter routing work with a Diameter application like Wm? This very much depends on how the protocol designers of Wm want it to work.= I have to read Wm again to recall the details but based on what you descri= be it seems that the protocol designers of Wm did not want to create a new = Diameter application and hence the additionally specified AVPs are just opt= ional extensions to Diameter EAP and Diameter NASREQ. As such, they should = be routed to the respective EAP/NASREQ code and the optional AVPs are inter= preted in case that they are understood. = Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On = >Behalf Of ext Sebastien Decugis >Sent: 09 September, 2008 14:02 >To: Jacob Martin >Cc: dime@ietf.org >Subject: Re: [Dime] Application-id reuse > >Hello, > >I think the Application Id in the command header will contain = >the appropriate identifier to route the message to the correct = >handler... > >Best regards, >Sebastien. > >Jacob Martin a =E9crit : >> >> Hi, >> = >> I am a bit confused about the feasibility of one specific = >> configuration in Diameter. >> = >> Please look at the diagram below: = >> = >> = >> | >> | >> | >> | = >> Local Node | >> | +----+ +-------+ >> | |NAS | | Wm | >> +--------+ +--------+ | +----+ +-------+ >> | | | | | | --- >> |NASREQ | | Wm | | | --- >> +----\---+ +---/----+ | +----- -- >> \ // | //// \\\\\ >> \ // | |/ | >> \ // | | PEER | >> +---\-/------+ | | | >> | | | |\ | >> |Diameter | | \\\\ ///// >> |Base process| | ------ >> +----+-------+ | | >> | | | >> | | | >> +------------------+-------------+ >> = >> I wish to provide support for two applications on my = >local node i.e = >> NASREQ and Wm. As per Wm specifications, Wm should reuse the = >> application identifier of EAP/NASREQ. So, in CEA, I have advertised = >> '1' and '5' as the applications supported. >> = >> Assume that peer node also has the same configuration as of mine = >> i.e it also support Wm and NAS applications. >> = >> Now, peer Wm application issues an AAR. After receiving this AAR, = >> how could my Diameter base process determine that this AAR is for = >> local Wm application, but not for local NASREQ application? >> = >> >> Thanks in anticipation, >> Martin = >> = >> = >> >> = >---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> = > >-- >Sebastien Decugis >Research fellow >Network Architecture Group >NICT (nict.go.jp) > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 00:39:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8741B3A6B59; Fri, 12 Sep 2008 00:39:49 -0700 (PDT) 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 AF0843A6912 for ; Fri, 12 Sep 2008 00:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.65 X-Spam-Level: X-Spam-Status: No, score=-5.65 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4Ea185stmWL for ; Fri, 12 Sep 2008 00:39:47 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 6B3173A6BE1 for ; Fri, 12 Sep 2008 00:39:47 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 09:39:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 09:39:39 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A225E@SEHAN021MB.tcad.telia.se> In-Reply-To: <9ad5b0030809120033q6fcc86b3pcea6b3274da7c296@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Application-id reuse Thread-Index: AckUqePHcpskFVgsT3u6zx2h+of8PQAABiaA References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <9ad5b0030809120033q6fcc86b3pcea6b3274da7c296@mail.gmail.com> From: To: , X-OriginalArrivalTime: 12 Sep 2008 07:39:41.0227 (UTC) FILETIME=[B77E3FB0:01C914AA] Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jacob, > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Jacob Martin > Sent: 12. syyskuuta 2008 10:33 > To: Jouni Korhonen > Cc: dime@ietf.org > Subject: Re: [Dime] Application-id reuse > > > Jouni, > On 9/9/08, Jouni Korhonen wrote: > > Hi Jacob, > > > > I assume by Wm you mean the 3GPP TS 29.234 specified Wm interface? > > Btw, Wm is not an "application", rather a name of a specific > > reference point between two nodes. You can also see it as a > > "profile" compliant with NASREQ or EAP. > > > > Anyway, you NAS device, i.e. the PDG knows that it wants to > > authorize a certain user to a specific APN and adds required AVPs > > to the AAR to accomplish this. The AAA server receiving the AAR > > needs to do "further checking" against the message it received. So > > it falls back to dictionary type of matching of AVPs. There are > > Wm specific AVPs such as 3GPP-WLAN-APN-ID. Once the server finds > > one in the AAR it can be sure this is about WM and authorizing the > > user to a specific APN. For other possible uses of Wm you need to > > do similar checking of AVPs in the received message. > > I could identify AAR for Wm by looking at W-APN-ID or Routing Policy > AVPs, but I am not able to find any such AVPs in DER command. The Wm uses "two phase" approach. First the EAP is used to authenticate the WLAN-UE. This is standard EAP application use, except the optional Visited-Network-Identifier AVP. Here, you just follow what EAP application is supposed to do. During the second phase the NASREQ is used to authorize the WLAN-UE. And for that case, the earlier dictionary stuff applies. > In DER for Wm, "Visited Network Identifier" AVP is a new one, but its > a conditional AVP. If PDG is in WLAN-UE's home network then this AVP > would be absent. Cheers, Jouni > > > > > Hope this helps. > > > > Cheers, > > Jouni > > > > > > On Sep 9, 2008, at 11:14 AM, Jacob Martin wrote: > > > >> Hi, > >> > >> I am a bit confused about the feasibility of one specific > >> configuration in Diameter. > >> > >> Please look at the diagram below: > >> > >> > >> | > >> | > >> | > >> | > >> Local Node | > >> | +----+ +-------+ > >> | |NAS | | Wm | > >> +--------+ +--------+ | +----+ +-------+ > >> | | | | | | --- > >> |NASREQ | | Wm | | | --- > >> +----\---+ +---/----+ | +----- -- > >> \ // | //// \\\\\ > >> \ // | |/ | > >> \ // | | PEER | > >> +---\-/------+ | | | > >> | | | |\ | > >> |Diameter | | \\\\ ///// > >> |Base process| | ------ > >> +----+-------+ | | > >> | | | > >> | | | > >> +------------------+-------------+ > >> > >> I wish to provide support for two applications on my local node > >> i.e NASREQ and Wm. As per Wm specifications, Wm should reuse the > >> application identifier of EAP/NASREQ. So, in CEA, I have advertised > >> '1' and '5' as the applications supported. > >> > >> Assume that peer node also has the same configuration as of mine > >> i.e it also support Wm and NAS applications. > >> > >> Now, peer Wm application issues an AAR. After receiving this AAR, > >> how could my Diameter base process determine that this AAR is for > >> local Wm application, but not for local NASREQ application? > >> > >> > >> Thanks in anticipation, > >> Martin > >> > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > > > > > Cheers, > Martin > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 02:39:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B513A6B39; Fri, 12 Sep 2008 02:39:20 -0700 (PDT) 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 036053A6B39 for ; Fri, 12 Sep 2008 02:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Cxx-4qg9HXSO for ; Fri, 12 Sep 2008 02:39:18 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.247]) by core3.amsl.com (Postfix) with ESMTP id A5A573A6A73 for ; Fri, 12 Sep 2008 02:39:18 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so2349083agb.12 for ; Fri, 12 Sep 2008 02:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qkhsGrMbqji6d/6IKrEMVja969iq5FRVFiFrEdFfGIA=; b=cHuJpNGcNRRhJsRWu9lXMl/CMANS+wvG1rNWstbgkwzKHp94s1gQNrqa5wWQD9/duE WXX0JrFsDd4V4h9Gw8Bm4j/BAG/H+xUNYOMbXWKbHyq7tmCeJpNVvD30xpWWATs2qDyr DyhWz7dgpgcCX02xqkOOIHPpIy9UXImvZdB0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=mOIobr4eRMavxvYlctX3FOLPilNMO2nKuejV45QPQKyN2yo4Vvf8UdRv6GpkeThM6N V1j/P1CkvOEoyw1YPC47QyWm2LG0FLmejYvr2jCzodvE6kHx248Tc6LG8lC93Rj/AAST jxc1St4ePWyFi5zoV5I4ODAcg1LhmHtWB7uaI= Received: by 10.100.140.10 with SMTP id n10mr4832388and.100.1221212349441; Fri, 12 Sep 2008 02:39:09 -0700 (PDT) Received: by 10.70.19.2 with HTTP; Fri, 12 Sep 2008 02:39:09 -0700 (PDT) Message-ID: <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> Date: Fri, 12 Sep 2008 15:09:09 +0530 From: "Jacob Martin" To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, My problem relates to the second question which you have raised i.e "How does Diameter routing work with a Diameter application like Wm?" From the implementor's point of view, it is difficult to keep one process(Wm) for WLAN activities, and other for traditional EAP/NASREQ requests(Please look at the diagram in my initial post). This problem could be avoided if we have a seperate app-id for Wm. As per section 1.2.3 of RFC 3588, =3D=3D=3D=3D=3D " .........it may be desirable to create a new Diameter application. Major changes to an application include: - Adding new AVPs to the command, which have the "M" bit set. " =3D=3D=3D=3D=3D In Wm, protocol designers have added AVPs which have M bit 'on' ex: 3GPP-WLAN-APN-Id, Routing-Policy etc. Cheers, Jacob On 9/12/08, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Jacob, > > Your question addresses different aspects, namely > > * How does Diameter routing work in general? > > This is described in Section 6.1 and Section 6.2 of > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt > > This should give you an idea how the right node is found and how messages > travel back and forth. > > * How does Diameter routing work with a Diameter application like Wm? > > This very much depends on how the protocol designers of Wm want it to wor= k. > I have to read Wm again to recall the details but based on what you descr= ibe > it seems that the protocol designers of Wm did not want to create a new > Diameter application and hence the additionally specified AVPs are just > optional extensions to Diameter EAP and Diameter NASREQ. As such, they > should be routed to the respective EAP/NASREQ code and the optional AVPs = are > interpreted in case that they are understood. > > Ciao > Hannes > >>-----Original Message----- >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >>Behalf Of ext Sebastien Decugis >>Sent: 09 September, 2008 14:02 >>To: Jacob Martin >>Cc: dime@ietf.org >>Subject: Re: [Dime] Application-id reuse >> >>Hello, >> >>I think the Application Id in the command header will contain >>the appropriate identifier to route the message to the correct >>handler... >> >>Best regards, >>Sebastien. >> >>Jacob Martin a =E9crit : >>> >>> Hi, >>> >>> I am a bit confused about the feasibility of one specific >>> configuration in Diameter. >>> >>> Please look at the diagram below: >>> >>> >>> | >>> | >>> | >>> | >>> Local Node | >>> | +----+ +-------+ >>> | |NAS | | Wm | >>> +--------+ +--------+ | +----+ +-------+ >>> | | | | | | --- >>> |NASREQ | | Wm | | | --- >>> +----\---+ +---/----+ | +----- -- >>> \ // | //// \\\\\ >>> \ // | |/ | >>> \ // | | PEER | >>> +---\-/------+ | | | >>> | | | |\ | >>> |Diameter | | \\\\ ///// >>> |Base process| | ------ >>> +----+-------+ | | >>> | | | >>> | | | >>> +------------------+-------------+ >>> >>> I wish to provide support for two applications on my >>local node i.e >>> NASREQ and Wm. As per Wm specifications, Wm should reuse the >>> application identifier of EAP/NASREQ. So, in CEA, I have advertised >>> '1' and '5' as the applications supported. >>> >>> Assume that peer node also has the same configuration as of mine >>> i.e it also support Wm and NAS applications. >>> >>> Now, peer Wm application issues an AAR. After receiving this AAR, >>> how could my Diameter base process determine that this AAR is for >>> local Wm application, but not for local NASREQ application? >>> >>> >>> Thanks in anticipation, >>> Martin >>> >>> >>> >>> >>---------------------------------------------------------------------- >>> -- >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> >>-- >>Sebastien Decugis >>Research fellow >>Network Architecture Group >>NICT (nict.go.jp) >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 02:58:35 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0EBF3A6C07; Fri, 12 Sep 2008 02:58:35 -0700 (PDT) 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 488343A6C03 for ; Fri, 12 Sep 2008 02:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkVKSIOCEJqw for ; Fri, 12 Sep 2008 02:58:33 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 8B2D53A6C07 for ; Fri, 12 Sep 2008 02:58:32 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 11:58:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 11:58:36 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> In-Reply-To: <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Application-id reuse Thread-Index: AckUu3j7jxf4zCSGTPWB9qGxZ0Q4+AAAONbw References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com><48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> From: To: , X-OriginalArrivalTime: 12 Sep 2008 09:58:37.0607 (UTC) FILETIME=[205CE370:01C914BE] Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jacob, > Hi Hannes, > = > My problem relates to the second question which you have raised i.e > "How does Diameter routing work with a Diameter application like Wm?" > = > From the implementor's point of view, it is difficult to keep one > process(Wm) for WLAN activities, and other for traditional EAP/NASREQ > requests(Please look at the diagram in my initial post). Dictionaries.. > This problem could be avoided if we have a seperate app-id for Wm. > = > As per section 1.2.3 of RFC 3588, > =3D=3D=3D=3D=3D > " > .........it may be desirable to create a new Diameter > application. Major changes to an application include: > = > - Adding new AVPs to the command, which have the "M" bit set. > " > =3D=3D=3D=3D=3D > = > In Wm, protocol designers have added AVPs which have M bit 'on' ex: > 3GPP-WLAN-APN-Id, Routing-Policy etc. These are known deficiencies in TS29.234 and will stay there until someone makes a CR to fix them. Anyway, the Information Element with a category 'M' means that the said AVP must be present in the Diameter message.. thus defining the exact "profile". It does not say anything about the M-bit setting. See section 10.2 of TS 29.234. You can send 3GPP-WLAN-APN-Id with M-bit unset and still assume the other end understands the AVP. (you are now entering into a gray area in 3GPP, which has recently been tried to fix with clear guidelines..) Cheers, Jouni > = > Cheers, > Jacob > = > On 9/12/08, Tschofenig, Hannes (NSN - FI/Espoo) > wrote: > > Hi Jacob, > > > > Your question addresses different aspects, namely > > > > * How does Diameter routing work in general? > > > > This is described in Section 6.1 and Section 6.2 of > > = > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt > > > > This should give you an idea how the right node is found = > and how messages > > travel back and forth. > > > > * How does Diameter routing work with a Diameter = > application like Wm? > > > > This very much depends on how the protocol designers of Wm = > want it to work. > > I have to read Wm again to recall the details but based on = > what you describe > > it seems that the protocol designers of Wm did not want to = > create a new > > Diameter application and hence the additionally specified = > AVPs are just > > optional extensions to Diameter EAP and Diameter NASREQ. As = > such, they > > should be routed to the respective EAP/NASREQ code and the = > optional AVPs are > > interpreted in case that they are understood. > > > > Ciao > > Hannes > > > >>-----Original Message----- > >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > >>Behalf Of ext Sebastien Decugis > >>Sent: 09 September, 2008 14:02 > >>To: Jacob Martin > >>Cc: dime@ietf.org > >>Subject: Re: [Dime] Application-id reuse > >> > >>Hello, > >> > >>I think the Application Id in the command header will contain > >>the appropriate identifier to route the message to the correct > >>handler... > >> > >>Best regards, > >>Sebastien. > >> > >>Jacob Martin a =E9crit : > >>> > >>> Hi, > >>> > >>> I am a bit confused about the feasibility of one specific > >>> configuration in Diameter. > >>> > >>> Please look at the diagram below: > >>> > >>> > >>> | > >>> | > >>> | > >>> | > >>> Local Node | > >>> | +----+ +-------+ > >>> | |NAS | | Wm | > >>> +--------+ +--------+ | +----+ +-------+ > >>> | | | | | | --- > >>> |NASREQ | | Wm | | | --- > >>> +----\---+ +---/----+ | +----- -- > >>> \ // | //// \\\\\ > >>> \ // | |/ | > >>> \ // | | PEER | > >>> +---\-/------+ | | | > >>> | | | |\ | > >>> |Diameter | | \\\\ ///// > >>> |Base process| | ------ > >>> +----+-------+ | | > >>> | | | > >>> | | | > >>> +------------------+-------------+ > >>> > >>> I wish to provide support for two applications on my > >>local node i.e > >>> NASREQ and Wm. As per Wm specifications, Wm should reuse the > >>> application identifier of EAP/NASREQ. So, in CEA, I have = > advertised > >>> '1' and '5' as the applications supported. > >>> > >>> Assume that peer node also has the same configuration = > as of mine > >>> i.e it also support Wm and NAS applications. > >>> > >>> Now, peer Wm application issues an AAR. After receiving = > this AAR, > >>> how could my Diameter base process determine that this AAR is for > >>> local Wm application, but not for local NASREQ application? > >>> > >>> > >>> Thanks in anticipation, > >>> Martin > >>> > >>> > >>> > >>> > >>------------------------------------------------------------ > ---------- > >>> -- > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dime > >>> > >> > >>-- > >>Sebastien Decugis > >>Research fellow > >>Network Architecture Group > >>NICT (nict.go.jp) > >> > >>_______________________________________________ > >>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 dime-bounces@ietf.org Fri Sep 12 03:27:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FAE73A6AA5; Fri, 12 Sep 2008 03:27:10 -0700 (PDT) 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 43C213A6A73 for ; Fri, 12 Sep 2008 03:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 ygLc5ha1Q41E for ; Fri, 12 Sep 2008 03:27:07 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F08243A6B04 for ; Fri, 12 Sep 2008 03:27:06 -0700 (PDT) Received: (qmail invoked by alias); 12 Sep 2008 10:27:12 -0000 Received: from unknown (EHLO [10.183.181.140]) [192.100.124.156] by mail.gmx.net (mp003) with SMTP; 12 Sep 2008 12:27:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/2535t3zv225xoTUzu37/d5zzvuAESbqh6QEU+Zc HNMyve9G1U1iw9 Message-ID: <48CA43FB.5060502@gmx.net> Date: Fri, 12 Sep 2008 13:27:07 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com><48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jacob, jouni.korhonen@teliasonera.com wrote: > Hi Jacob, > > = >> Hi Hannes, >> >> My problem relates to the second question which you have raised i.e >> "How does Diameter routing work with a Diameter application like Wm?" >> >> From the implementor's point of view, it is difficult to keep one >> process(Wm) for WLAN activities, and other for traditional EAP/NASREQ >> requests(Please look at the diagram in my initial post). >> = > > Dictionaries.. > > = There are many ways todo so from an implementation point of view. = Typically, you are going to have some business logic at the AAA server. = Could you be more specific about the problems you see? >> This problem could be avoided if we have a seperate app-id for Wm. >> >> As per section 1.2.3 of RFC 3588, >> =3D=3D=3D=3D=3D >> " >> .........it may be desirable to create a new Diameter >> application. Major changes to an application include: >> >> - Adding new AVPs to the command, which have the "M" bit set. >> " >> =3D=3D=3D=3D=3D >> >> In Wm, protocol designers have added AVPs which have M bit 'on' ex: >> 3GPP-WLAN-APN-Id, Routing-Policy etc. >> = > > These are known deficiencies in TS29.234 and will stay there until > someone makes a CR to fix them. Anyway, the Information Element with > a category 'M' means that the said AVP must be present in the Diameter > message.. thus defining the exact "profile". It does not say anything > about the M-bit setting. See section 10.2 of TS 29.234. You can send > 3GPP-WLAN-APN-Id with M-bit unset and still assume the other end > understands the AVP. (you are now entering into a gray area in 3GPP, > which has recently been tried to fix with clear guidelines..) > > = I would like to reinforce what Jouni said. If the application designer = does not want to create new application then all the functionality they = define has to be optional. If there is mandatory and required = functionality in the extension then a Diameter application should have = been defined. This wasn't done in the 3GPP and I hope that someone is = going to fix it. Ciao Hannes > Cheers, > Jouni > > = >> Cheers, >> Jacob >> >> On 9/12/08, Tschofenig, Hannes (NSN - FI/Espoo) >> wrote: >> = >>> Hi Jacob, >>> >>> Your question addresses different aspects, namely >>> >>> * How does Diameter routing work in general? >>> >>> This is described in Section 6.1 and Section 6.2 of >>> >>> = >> http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt >> = >>> This should give you an idea how the right node is found = >>> = >> and how messages >> = >>> travel back and forth. >>> >>> * How does Diameter routing work with a Diameter = >>> = >> application like Wm? >> = >>> This very much depends on how the protocol designers of Wm = >>> = >> want it to work. >> = >>> I have to read Wm again to recall the details but based on = >>> = >> what you describe >> = >>> it seems that the protocol designers of Wm did not want to = >>> = >> create a new >> = >>> Diameter application and hence the additionally specified = >>> = >> AVPs are just >> = >>> optional extensions to Diameter EAP and Diameter NASREQ. As = >>> = >> such, they >> = >>> should be routed to the respective EAP/NASREQ code and the = >>> = >> optional AVPs are >> = >>> interpreted in case that they are understood. >>> >>> Ciao >>> Hannes >>> >>> = >>>> -----Original Message----- >>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >>>> Behalf Of ext Sebastien Decugis >>>> Sent: 09 September, 2008 14:02 >>>> To: Jacob Martin >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Application-id reuse >>>> >>>> Hello, >>>> >>>> I think the Application Id in the command header will contain >>>> the appropriate identifier to route the message to the correct >>>> handler... >>>> >>>> Best regards, >>>> Sebastien. >>>> >>>> Jacob Martin a =E9crit : >>>> = >>>>> Hi, >>>>> >>>>> I am a bit confused about the feasibility of one specific >>>>> configuration in Diameter. >>>>> >>>>> Please look at the diagram below: >>>>> >>>>> >>>>> | >>>>> | >>>>> | >>>>> | >>>>> Local Node | >>>>> | +----+ +-------+ >>>>> | |NAS | | Wm | >>>>> +--------+ +--------+ | +----+ +-------+ >>>>> | | | | | | --- >>>>> |NASREQ | | Wm | | | --- >>>>> +----\---+ +---/----+ | +----- -- >>>>> \ // | //// \\\\\ >>>>> \ // | |/ | >>>>> \ // | | PEER | >>>>> +---\-/------+ | | | >>>>> | | | |\ | >>>>> |Diameter | | \\\\ ///// >>>>> |Base process| | ------ >>>>> +----+-------+ | | >>>>> | | | >>>>> | | | >>>>> +------------------+-------------+ >>>>> >>>>> I wish to provide support for two applications on my >>>>> = >>>> local node i.e >>>> = >>>>> NASREQ and Wm. As per Wm specifications, Wm should reuse the >>>>> application identifier of EAP/NASREQ. So, in CEA, I have = >>>>> = >> advertised >> = >>>>> '1' and '5' as the applications supported. >>>>> >>>>> Assume that peer node also has the same configuration = >>>>> = >> as of mine >> = >>>>> i.e it also support Wm and NAS applications. >>>>> >>>>> Now, peer Wm application issues an AAR. After receiving = >>>>> = >> this AAR, >> = >>>>> how could my Diameter base process determine that this AAR is for >>>>> local Wm application, but not for local NASREQ application? >>>>> >>>>> >>>>> Thanks in anticipation, >>>>> Martin >>>>> >>>>> >>>>> >>>>> >>>>> = >>>> ------------------------------------------------------------ >>>> = >> ---------- >> = >>>>> -- >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>>> = >>>> -- >>>> Sebastien Decugis >>>> Research fellow >>>> Network Architecture Group >>>> NICT (nict.go.jp) >>>> >>>> _______________________________________________ >>>> 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 > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 03:29:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B1F3A690E; Fri, 12 Sep 2008 03:29:02 -0700 (PDT) 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 2A1F73A690E for ; Fri, 12 Sep 2008 03:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 PJ2Us2ZfOYdh for ; Fri, 12 Sep 2008 03:29:00 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.243]) by core3.amsl.com (Postfix) with ESMTP id 63A563A68AD for ; Fri, 12 Sep 2008 03:28:59 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so2394523agb.12 for ; Fri, 12 Sep 2008 03:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oF1WtETQH9b0tuNWM/oFqyHvS2D/2olPtikKtK+7yhw=; b=V+AjO+dU5N1Zp4Idu4tEtuoqJIFV4eidVYT5Bn1Va+7mZdxCCethtfkucSY36XzHJ3 X/CU8ja27KRfrNWDv146ktdqxJbuIUF6c4Ww5gWDVioStkBH/i67jWpShaEBbGW6uReG 8jqjLm58t20W3XFmRsB179Vr6yBb/KBhBnisg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BhQpD9XeiYHjb0w/SJ6LLjuzAjuT6RX3V/2NF+kL+uh2DKKM0v8UT5rRh6XcwVVUlP +9t0G5h0hm8eiIcq2DrWWYcaKFLjInurbmCk06ZzHwfYhTLoKmLDLFN8jKUJ4izUu7ru V9Qou76k9p+cyljPSvBAcnZgiBxmloM7CQLiU= Received: by 10.90.70.15 with SMTP id s15mr4836973aga.110.1221215346025; Fri, 12 Sep 2008 03:29:06 -0700 (PDT) Received: by 10.70.19.2 with HTTP; Fri, 12 Sep 2008 03:29:05 -0700 (PDT) Message-ID: <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> Date: Fri, 12 Sep 2008 15:59:05 +0530 From: "Jacob Martin" To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jouni, On 9/12/08, jouni.korhonen@teliasonera.com wrote: > Hi Jacob, > >> Hi Hannes, >> >> My problem relates to the second question which you have raised i.e >> "How does Diameter routing work with a Diameter application like Wm?" >> >> From the implementor's point of view, it is difficult to keep one >> process(Wm) for WLAN activities, and other for traditional EAP/NASREQ >> requests(Please look at the diagram in my initial post). > > Dictionaries.. How? If my base Diameter process has received a DER request from peer for WLAN application, then how could it be routed to Wm application. Please refer the diagram in my initial post. > >> This problem could be avoided if we have a seperate app-id for Wm. >> >> As per section 1.2.3 of RFC 3588, >> =3D=3D=3D=3D=3D >> " >> .........it may be desirable to create a new Diameter >> application. Major changes to an application include: >> >> - Adding new AVPs to the command, which have the "M" bit set. >> " >> =3D=3D=3D=3D=3D >> >> In Wm, protocol designers have added AVPs which have M bit 'on' ex: >> 3GPP-WLAN-APN-Id, Routing-Policy etc. > > These are known deficiencies in TS29.234 and will stay there until > someone makes a CR to fix them. Anyway, the Information Element with > a category 'M' means that the said AVP must be present in the Diameter > message.. thus defining the exact "profile". It does not say anything > about the M-bit setting. See section 10.2 of TS 29.234. You can send > 3GPP-WLAN-APN-Id with M-bit unset and still assume the other end > understands the AVP. (you are now entering into a gray area in 3GPP, > which has recently been tried to fix with clear guidelines..) I think table 10.1.1 in TS29.234 has the AVP flag details for all the AVPs. > > Cheers, > Jouni > >> >> Cheers, >> Jacob >> >> On 9/12/08, Tschofenig, Hannes (NSN - FI/Espoo) >> wrote: >> > Hi Jacob, >> > >> > Your question addresses different aspects, namely >> > >> > * How does Diameter routing work in general? >> > >> > This is described in Section 6.1 and Section 6.2 of >> > >> http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt >> > >> > This should give you an idea how the right node is found >> and how messages >> > travel back and forth. >> > >> > * How does Diameter routing work with a Diameter >> application like Wm? >> > >> > This very much depends on how the protocol designers of Wm >> want it to work. >> > I have to read Wm again to recall the details but based on >> what you describe >> > it seems that the protocol designers of Wm did not want to >> create a new >> > Diameter application and hence the additionally specified >> AVPs are just >> > optional extensions to Diameter EAP and Diameter NASREQ. As >> such, they >> > should be routed to the respective EAP/NASREQ code and the >> optional AVPs are >> > interpreted in case that they are understood. >> > >> > Ciao >> > Hannes >> > >> >>-----Original Message----- >> >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >> >>Behalf Of ext Sebastien Decugis >> >>Sent: 09 September, 2008 14:02 >> >>To: Jacob Martin >> >>Cc: dime@ietf.org >> >>Subject: Re: [Dime] Application-id reuse >> >> >> >>Hello, >> >> >> >>I think the Application Id in the command header will contain >> >>the appropriate identifier to route the message to the correct >> >>handler... >> >> >> >>Best regards, >> >>Sebastien. >> >> >> >>Jacob Martin a =E9crit : >> >>> >> >>> Hi, >> >>> >> >>> I am a bit confused about the feasibility of one specific >> >>> configuration in Diameter. >> >>> >> >>> Please look at the diagram below: >> >>> >> >>> >> >>> | >> >>> | >> >>> | >> >>> | >> >>> Local Node | >> >>> | +----+ +-------+ >> >>> | |NAS | | Wm | >> >>> +--------+ +--------+ | +----+ +-------+ >> >>> | | | | | | --- >> >>> |NASREQ | | Wm | | | --- >> >>> +----\---+ +---/----+ | +----- -- >> >>> \ // | //// \\\\\ >> >>> \ // | |/ | >> >>> \ // | | PEER | >> >>> +---\-/------+ | | | >> >>> | | | |\ | >> >>> |Diameter | | \\\\ ///// >> >>> |Base process| | ------ >> >>> +----+-------+ | | >> >>> | | | >> >>> | | | >> >>> +------------------+-------------+ >> >>> >> >>> I wish to provide support for two applications on my >> >>local node i.e >> >>> NASREQ and Wm. As per Wm specifications, Wm should reuse the >> >>> application identifier of EAP/NASREQ. So, in CEA, I have >> advertised >> >>> '1' and '5' as the applications supported. >> >>> >> >>> Assume that peer node also has the same configuration >> as of mine >> >>> i.e it also support Wm and NAS applications. >> >>> >> >>> Now, peer Wm application issues an AAR. After receiving >> this AAR, >> >>> how could my Diameter base process determine that this AAR is for >> >>> local Wm application, but not for local NASREQ application? >> >>> >> >>> >> >>> Thanks in anticipation, >> >>> Martin >> >>> >> >>> >> >>> >> >>> >> >>------------------------------------------------------------ >> ---------- >> >>> -- >> >>> >> >>> _______________________________________________ >> >>> DiME mailing list >> >>> DiME@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/dime >> >>> >> >> >> >>-- >> >>Sebastien Decugis >> >>Research fellow >> >>Network Architecture Group >> >>NICT (nict.go.jp) >> >> >> >>_______________________________________________ >> >>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 dime-bounces@ietf.org Fri Sep 12 03:38:22 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658A43A6A7F; Fri, 12 Sep 2008 03:38:22 -0700 (PDT) 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 2A8EF3A6B04 for ; Fri, 12 Sep 2008 03:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 muJibrsm7Bfm for ; Fri, 12 Sep 2008 03:38:20 -0700 (PDT) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.247]) by core3.amsl.com (Postfix) with ESMTP id C6D253A69FA for ; Fri, 12 Sep 2008 03:38:19 -0700 (PDT) Received: by ag-out-0708.google.com with SMTP id 26so2403088agb.12 for ; Fri, 12 Sep 2008 03:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=XBlKrKMBK6hJnBisFsRWKsKIOekq167SyEqv1lXuS4U=; b=tuAGzmY5wLL+I+D8QMMKlQqwAm8J01W2wUs0Jv2xzB3DlpuRSlFcVO3q4MtAhFBfE/ Vcqh9wYE5+HxwjBH43PABmAbeXIohzi017iqH1VIQUjDFbx83moS4masyu14uOD1ZRdt X0QfMy+npqnZr5IulJCIwnjQ0Bu75AponD7TI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=W/lsMZFE+R45wGUpwObVdaLixhizc27VJm622SC5Djooaji0kzWqbjwn6JQVJkDqu4 NlBKAHxKElaEa9+rkyK1w4GegcNAb29u1Q69A3x57F9d3EKg4rCzXAyZhSq7E9ffdqTQ Mop0eyAp4HKCt4vhlDo9w42TUh+eO18D1igEE= Received: by 10.90.99.3 with SMTP id w3mr4898577agb.55.1221215904316; Fri, 12 Sep 2008 03:38:24 -0700 (PDT) Received: by 10.70.19.2 with HTTP; Fri, 12 Sep 2008 03:38:24 -0700 (PDT) Message-ID: <9ad5b0030809120338m2c80e642x26f228ad876dae03@mail.gmail.com> Date: Fri, 12 Sep 2008 16:08:24 +0530 From: "Jacob Martin" To: "Hannes Tschofenig" In-Reply-To: <48CA43FB.5060502@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <48CA43FB.5060502@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, On 9/12/08, Hannes Tschofenig wrote: > Hi Jacob, > > jouni.korhonen@teliasonera.com wrote: >> Hi Jacob, >> >> >>> Hi Hannes, >>> >>> My problem relates to the second question which you have raised i.e >>> "How does Diameter routing work with a Diameter application like Wm?" >>> >>> From the implementor's point of view, it is difficult to keep one >>> process(Wm) for WLAN activities, and other for traditional EAP/NASREQ >>> requests(Please look at the diagram in my initial post). >>> >> >> Dictionaries.. >> >> > There are many ways todo so from an implementation point of view. > Typically, you are going to have some business logic at the AAA server. > Could you be more specific about the problems you see? I have explained it in my previous post. Please have a look. > > >>> This problem could be avoided if we have a seperate app-id for Wm. >>> >>> As per section 1.2.3 of RFC 3588, >>> =3D=3D=3D=3D=3D >>> " >>> .........it may be desirable to create a new Diameter >>> application. Major changes to an application include: >>> >>> - Adding new AVPs to the command, which have the "M" bit set. >>> " >>> =3D=3D=3D=3D=3D >>> >>> In Wm, protocol designers have added AVPs which have M bit 'on' ex: >>> 3GPP-WLAN-APN-Id, Routing-Policy etc. >>> >> >> These are known deficiencies in TS29.234 and will stay there until >> someone makes a CR to fix them. Anyway, the Information Element with >> a category 'M' means that the said AVP must be present in the Diameter >> message.. thus defining the exact "profile". It does not say anything >> about the M-bit setting. See section 10.2 of TS 29.234. You can send >> 3GPP-WLAN-APN-Id with M-bit unset and still assume the other end >> understands the AVP. (you are now entering into a gray area in 3GPP, >> which has recently been tried to fix with clear guidelines..) >> >> > I would like to reinforce what Jouni said. If the application designer > does not want to create new application then all the functionality they > define has to be optional. If there is mandatory and required > functionality in the extension then a Diameter application should have > been defined. This wasn't done in the 3GPP and I hope that someone is > going to fix it. This problem has been captured in 3GPP TR 29.909. In section 5.5, it has few proposals to avoid such problem. Cheers, Jacob > > Ciao > Hannes > >> Cheers, >> Jouni >> >> >>> Cheers, >>> Jacob >>> >>> On 9/12/08, Tschofenig, Hannes (NSN - FI/Espoo) >>> wrote: >>> >>>> Hi Jacob, >>>> >>>> Your question addresses different aspects, namely >>>> >>>> * How does Diameter routing work in general? >>>> >>>> This is described in Section 6.1 and Section 6.2 of >>>> >>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt >>> >>>> This should give you an idea how the right node is found >>>> >>> and how messages >>> >>>> travel back and forth. >>>> >>>> * How does Diameter routing work with a Diameter >>>> >>> application like Wm? >>> >>>> This very much depends on how the protocol designers of Wm >>>> >>> want it to work. >>> >>>> I have to read Wm again to recall the details but based on >>>> >>> what you describe >>> >>>> it seems that the protocol designers of Wm did not want to >>>> >>> create a new >>> >>>> Diameter application and hence the additionally specified >>>> >>> AVPs are just >>> >>>> optional extensions to Diameter EAP and Diameter NASREQ. As >>>> >>> such, they >>> >>>> should be routed to the respective EAP/NASREQ code and the >>>> >>> optional AVPs are >>> >>>> interpreted in case that they are understood. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>>> -----Original Message----- >>>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >>>>> Behalf Of ext Sebastien Decugis >>>>> Sent: 09 September, 2008 14:02 >>>>> To: Jacob Martin >>>>> Cc: dime@ietf.org >>>>> Subject: Re: [Dime] Application-id reuse >>>>> >>>>> Hello, >>>>> >>>>> I think the Application Id in the command header will contain >>>>> the appropriate identifier to route the message to the correct >>>>> handler... >>>>> >>>>> Best regards, >>>>> Sebastien. >>>>> >>>>> Jacob Martin a =E9crit : >>>>> >>>>>> Hi, >>>>>> >>>>>> I am a bit confused about the feasibility of one specific >>>>>> configuration in Diameter. >>>>>> >>>>>> Please look at the diagram below: >>>>>> >>>>>> >>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>>> Local Node | >>>>>> | +----+ +-------+ >>>>>> | |NAS | | Wm | >>>>>> +--------+ +--------+ | +----+ +-------+ >>>>>> | | | | | | --- >>>>>> |NASREQ | | Wm | | | --- >>>>>> +----\---+ +---/----+ | +----- -- >>>>>> \ // | //// \\\\\ >>>>>> \ // | |/ | >>>>>> \ // | | PEER | >>>>>> +---\-/------+ | | | >>>>>> | | | |\ | >>>>>> |Diameter | | \\\\ ///// >>>>>> |Base process| | ------ >>>>>> +----+-------+ | | >>>>>> | | | >>>>>> | | | >>>>>> +------------------+-------------+ >>>>>> >>>>>> I wish to provide support for two applications on my >>>>>> >>>>> local node i.e >>>>> >>>>>> NASREQ and Wm. As per Wm specifications, Wm should reuse the >>>>>> application identifier of EAP/NASREQ. So, in CEA, I have >>>>>> >>> advertised >>> >>>>>> '1' and '5' as the applications supported. >>>>>> >>>>>> Assume that peer node also has the same configuration >>>>>> >>> as of mine >>> >>>>>> i.e it also support Wm and NAS applications. >>>>>> >>>>>> Now, peer Wm application issues an AAR. After receiving >>>>>> >>> this AAR, >>> >>>>>> how could my Diameter base process determine that this AAR is for >>>>>> local Wm application, but not for local NASREQ application? >>>>>> >>>>>> >>>>>> Thanks in anticipation, >>>>>> Martin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------ >>>>> >>> ---------- >>> >>>>>> -- >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> >>>>> -- >>>>> Sebastien Decugis >>>>> Research fellow >>>>> Network Architecture Group >>>>> NICT (nict.go.jp) >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 03:38:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8753A6BB8; Fri, 12 Sep 2008 03:38:50 -0700 (PDT) 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 3071F3A6BB8 for ; Fri, 12 Sep 2008 03:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE4-A6-XA--n for ; Fri, 12 Sep 2008 03:38:48 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 334AC3A69FA for ; Fri, 12 Sep 2008 03:38:47 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 12:38:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 12:38:52 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A2277@SEHAN021MB.tcad.telia.se> In-Reply-To: <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Application-id reuse Thread-Index: AckUwmY2wt97TgK+RSeTeJ2Z7XpdbwAAH1uw References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> From: To: X-OriginalArrivalTime: 12 Sep 2008 10:38:54.0343 (UTC) FILETIME=[C0D98970:01C914C3] Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jacob, > >> In Wm, protocol designers have added AVPs which have M bit 'on' ex: > >> 3GPP-WLAN-APN-Id, Routing-Policy etc. > > > > These are known deficiencies in TS29.234 and will stay there until > > someone makes a CR to fix them. Anyway, the Information Element with > > a category 'M' means that the said AVP must be present in > the Diameter > > message.. thus defining the exact "profile". It does not > say anything > > about the M-bit setting. See section 10.2 of TS 29.234. You can send > > 3GPP-WLAN-APN-Id with M-bit unset and still assume the other end > > understands the AVP. (you are now entering into a gray area in 3GPP, > > which has recently been tried to fix with clear guidelines..) > > I think table 10.1.1 in TS29.234 has the AVP flag details for > all the AVPs. Oh yes, correct ;) Anyway, as I said, it is a known deficiency (well that does not help you though) that no one has bothered to fix. Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 03:52:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1A93A6C23; Fri, 12 Sep 2008 03:52:25 -0700 (PDT) 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 B0F0C3A6C23 for ; Fri, 12 Sep 2008 03:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 a7kq6OklFlAw for ; Fri, 12 Sep 2008 03:52:23 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 740E428B23E for ; Fri, 12 Sep 2008 03:52:22 -0700 (PDT) Received: (qmail invoked by alias); 12 Sep 2008 10:52:30 -0000 Received: from unknown (EHLO [10.183.181.140]) [192.100.124.156] by mail.gmx.net (mp010) with SMTP; 12 Sep 2008 12:52:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Lpc9LJTWLxSxCUcVNl96gRpr8DeIwjtpyg1+Hws omlcnsobeOKNQO Message-ID: <48CA49E8.1000606@gmx.net> Date: Fri, 12 Sep 2008 13:52:24 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jacob Martin References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> In-Reply-To: <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jacob, Jacob Martin wrote: > Jouni, > On 9/12/08, jouni.korhonen@teliasonera.com > wrote: > >> Hi Jacob, >> >> >>> Hi Hannes, >>> >>> My problem relates to the second question which you have raised i.e >>> "How does Diameter routing work with a Diameter application like Wm?" >>> >>> From the implementor's point of view, it is difficult to keep one >>> process(Wm) for WLAN activities, and other for traditional EAP/NASREQ >>> requests(Please look at the diagram in my initial post). >>> >> Dictionaries.. >> > How? If my base Diameter process has received a DER request from peer > for WLAN application, then how could it be routed to Wm application. > Please refer the diagram in my initial post. > I believe the terminology would be rather "... how could it be handed over to the Wm application within ." This is largely an implementation specific issue. You need to enhance your existing application logical to handle the additional AVPs that are defined on top of EAP/NASREQ. Does this help? > >>> This problem could be avoided if we have a seperate app-id for Wm. >>> >>> As per section 1.2.3 of RFC 3588, >>> ===== >>> " >>> .........it may be desirable to create a new Diameter >>> application. Major changes to an application include: >>> >>> - Adding new AVPs to the command, which have the "M" bit set. >>> " >>> ===== >>> >>> In Wm, protocol designers have added AVPs which have M bit 'on' ex: >>> 3GPP-WLAN-APN-Id, Routing-Policy etc. >>> >> These are known deficiencies in TS29.234 and will stay there until >> someone makes a CR to fix them. Anyway, the Information Element with >> a category 'M' means that the said AVP must be present in the Diameter >> message.. thus defining the exact "profile". It does not say anything >> about the M-bit setting. See section 10.2 of TS 29.234. You can send >> 3GPP-WLAN-APN-Id with M-bit unset and still assume the other end >> understands the AVP. (you are now entering into a gray area in 3GPP, >> which has recently been tried to fix with clear guidelines..) >> > > I think table 10.1.1 in TS29.234 has the AVP flag details for all the AVPs. > > Someone should fix this. >> Cheers, >> Jouni >> Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 04:11:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913BC3A6AA9; Fri, 12 Sep 2008 04:11:12 -0700 (PDT) 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 D0BF13A6ABC for ; Fri, 12 Sep 2008 04:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 rRaZlhgzkSlX for ; Fri, 12 Sep 2008 04:11:11 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id CA5223A6A8A for ; Fri, 12 Sep 2008 04:11:10 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so143459and.122 for ; Fri, 12 Sep 2008 04:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HF0Oi+IijfaTQ/IOuFHILMVBIV5DxvHK8Wk35s77IRE=; b=nihDR0ABkNwwbuGvw0Tb+gkE9NJTERTLnRFb+SA13MTCQF7nCv9KuxqXb8uqwWu7eb nm3+YyuPJApLmp6DF5UWaJfO6F9B1Ex6yF3cBV3MD69fgexhw6jJrBireOMCzZug/41b l8KzDbGxTped9oLqLLGY+ojBsUFVyYldTz9Do= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ixQ9062p/6ZYRCDvCg10yLcxnf/cvP5YmO9DrOpr35jbi2T8VWPZuf1qEc00MtuVmG +TlMS9LDmigOSKlKaY4qVTp1dQvUtj3bffpwFuvfpmFQVhrbdYOr3wwXilcBLJ0V0aZ6 ECRxvXdUt8Tk8mKY8/cxi+aOwhM14FwX1469I= Received: by 10.100.13.2 with SMTP id 2mr5000438anm.46.1221217865696; Fri, 12 Sep 2008 04:11:05 -0700 (PDT) Received: by 10.70.19.2 with HTTP; Fri, 12 Sep 2008 04:11:05 -0700 (PDT) Message-ID: <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> Date: Fri, 12 Sep 2008 16:41:05 +0530 From: "Jacob Martin" To: "Hannes Tschofenig" In-Reply-To: <48CA49E8.1000606@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> <48CA49E8.1000606@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, On 9/12/08, Hannes Tschofenig wrote: > Hi Jacob, > > Jacob Martin wrote: >> Jouni, >> On 9/12/08, jouni.korhonen@teliasonera.com >> wrote: >> >>> Hi Jacob, >>> >>> >>>> Hi Hannes, >>>> >>>> My problem relates to the second question which you have raised i.e >>>> "How does Diameter routing work with a Diameter application like Wm?" >>>> >>>> From the implementor's point of view, it is difficult to keep one >>>> process(Wm) for WLAN activities, and other for traditional EAP/NASREQ >>>> requests(Please look at the diagram in my initial post). >>>> >>> Dictionaries.. >>> >> How? If my base Diameter process has received a DER request from peer >> for WLAN application, then how could it be routed to Wm application. >> Please refer the diagram in my initial post. >> > > I believe the terminology would be rather "... how could it be handed > over to the Wm application within ." > > This is largely an implementation specific issue. You need to enhance > your existing application logical to handle the additional AVPs that are > defined on top of EAP/NASREQ. > > Does this help? Anything could be done in software :), but I was just trying to get the answer for "Why Wm protocol designers did not opt for new app-id for Wm?" Cheers, Jacob > >> >>>> This problem could be avoided if we have a seperate app-id for Wm. >>>> >>>> As per section 1.2.3 of RFC 3588, >>>> ===== >>>> " >>>> .........it may be desirable to create a new Diameter >>>> application. Major changes to an application include: >>>> >>>> - Adding new AVPs to the command, which have the "M" bit set. >>>> " >>>> ===== >>>> >>>> In Wm, protocol designers have added AVPs which have M bit 'on' ex: >>>> 3GPP-WLAN-APN-Id, Routing-Policy etc. >>>> >>> These are known deficiencies in TS29.234 and will stay there until >>> someone makes a CR to fix them. Anyway, the Information Element with >>> a category 'M' means that the said AVP must be present in the Diameter >>> message.. thus defining the exact "profile". It does not say anything >>> about the M-bit setting. See section 10.2 of TS 29.234. You can send >>> 3GPP-WLAN-APN-Id with M-bit unset and still assume the other end >>> understands the AVP. (you are now entering into a gray area in 3GPP, >>> which has recently been tried to fix with clear guidelines..) >>> >> >> I think table 10.1.1 in TS29.234 has the AVP flag details for all the >> AVPs. >> >> > Someone should fix this. > >>> Cheers, >>> Jouni >>> > > Ciao > Hannes > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 12 04:25:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D3B3A6774; Fri, 12 Sep 2008 04:25:11 -0700 (PDT) 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 ED9133A6774 for ; Fri, 12 Sep 2008 04:25:09 -0700 (PDT) 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 fhg70tKrAG1L for ; Fri, 12 Sep 2008 04:25:07 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id CEE943A6932 for ; Fri, 12 Sep 2008 04:25:06 -0700 (PDT) Received: from [88.114.174.201] (a88-114-174-201.elisa-laajakaista.fi [88.114.174.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 47A4021663D; Fri, 12 Sep 2008 14:25:09 +0300 (EEST) In-Reply-To: <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> <48CA49E8.1000606@gmx.net> <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Jouni Korhonen Date: Fri, 12 Sep 2008 14:24:31 +0300 To: "Jacob Martin" X-Mailer: Apple Mail (2.753.1) Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Anything could be done in software :), but I was just trying to get > the answer for "Why Wm protocol designers did not opt for new app-id > for Wm?" Because of the RFC3588 section 1.2.3 statement: "Creation of a new application should be viewed as a last resort. An ... " Now that M-bit settings are wrong is just n error in TS29.234 Cheers, Jouni > > Cheers, > Jacob >> _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Sep 13 10:58:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470433A6C96; Sat, 13 Sep 2008 10:58:02 -0700 (PDT) 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 0EB2E3A6C90 for ; Sat, 13 Sep 2008 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599] 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 pLUPFR5fJk49 for ; Sat, 13 Sep 2008 10:57:55 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id E37E23A69F0 for ; Sat, 13 Sep 2008 10:57:54 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA10.westchester.pa.mail.comcast.net with comcast id EBNK1a0041GhbT85AHy2HV; Sat, 13 Sep 2008 17:58:02 +0000 Received: from gwzPC ([24.22.128.94]) by OMTA07.westchester.pa.mail.comcast.net with comcast id EHxn1a00N22L3VU3THxxZC; Sat, 13 Sep 2008 17:58:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=wy3793SLCSDLej6LJQAA:9 a=DUxIZZFg5ls4jXPucs8I3-knlJAA:4 a=MSl-tDqOz04A:10 a=Mz_smNXqyOQA:10 From: "Glen Zorn" To: "'Jacob Martin'" References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> <48CA49E8.1000606@gmx.net> <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> In-Reply-To: <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> Date: Sat, 13 Sep 2008 10:57:42 -0700 Message-ID: <006c01c915ca$3d441960$b7cc4c20$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckUyEklY4Vca1gqQ3mbrkzLMOVbvgBATYEw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jacob Martin [mailto://jacobmartin80@gmail.com] writes: ... > > I believe the terminology would be rather "... how could it be handed > > over to the Wm application within ." > > > > This is largely an implementation specific issue. You need to enhance > > your existing application logical to handle the additional AVPs that > are > > defined on top of EAP/NASREQ. > > > > Does this help? > Anything could be done in software :), but I was just trying to get > the answer for "Why Wm protocol designers did not opt for new app-id > for Wm?" If that's the question, then pretty obviously asking the wrong people: Wm isn't a product of the IETF, let alone this WG. Take your complainin' to 3GPP ;-)... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 14 12:13:33 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623E73A6AE9; Sun, 14 Sep 2008 12:13:33 -0700 (PDT) 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 2D3993A6A41 for ; Sun, 14 Sep 2008 12:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3db1L1cGIdMZ for ; Sun, 14 Sep 2008 12:13:31 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7EB663A6AE9 for ; Sun, 14 Sep 2008 12:13:30 -0700 (PDT) Received: (qmail invoked by alias); 14 Sep 2008 19:13:37 -0000 Received: from 80-186-80-175.elisa-mobile.fi (EHLO [80.186.80.175]) [80.186.80.175] by mail.gmx.net (mp003) with SMTP; 14 Sep 2008 21:13:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/WpSI3dPLWfaUeBM14vI7k5nZrW5XemI0ga5NV70 Kvs5ZfzMR/NGfu Message-ID: <48CD625D.1000605@gmx.net> Date: Sun, 14 Sep 2008 22:13:33 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: [Dime] draft-ietf-dime-rfc3588bis review (2/3) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Here is the 2nd part of my review: 9.2. Protocol Messages A Diameter node that receives a successful authentication and/or authorization messages from the Home AAA server MUST collect accounting information for the session. s/Home AAA server/Diameter server I wonder why there is this MUST statement here. Why is there MUST regarding the collection of accounting information. The Accounting-Request message is used to transmit the accounting information to the Home AAA server, which MUST reply with the Accounting-Answer message to confirm reception. s/Home AAA server/Diameter server The Accounting-Answer message includes the Result-Code AVP, which MAY indicate that an error was present in the accounting message. A rejected Accounting-Request message MAY cause the user's session to be terminated, depending on the value of the Accounting-Realtime-Required AVP received earlier for the session in question. I would re-write the last sentence to something like: " The value of the Accounting-Realtime-Required AVP received earlier for the session in question may indicate that the user's session has to be terminated when a rejected Accounting-Request message was received. " Each Diameter Accounting protocol message MAY be compressed, in order to reduce network bandwidth usage. If TLS is used to secure the Diameter session, then TLS compression [RFC4346] MAY be used. I wonder why this compression aspect is mentioned as there is nothing in Diameter itself to provide this compression. Compression is provided by TLS for all Diameter messages. 9.3. Accounting Application Extension and Requirements Each Diameter application (e.g., NASREQ, MobileIP), MUST define their Service-Specific AVPs that MUST be present in the Accounting-Request message in a section entitled "Accounting AVPs". I wonder why this is a MUST requirement. The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so only their respective service-specific AVPs need to be defined in this section. s/this section/that section 9.6. Correlation of Accounting Records The Diameter protocol's Session-Id AVP, which is globally unique (see Section 8.8), is used during the authorization phase to identify a particular session. Services that do not require any authorization still use the Session-Id AVP to identify sessions. Why is the authorization exchange mentioned here explicitly. Session-IDs are used throught Diameter and there is nothing specifial about the authorization phase. Accounting messages MAY use a different Session-Id from that sent in authorization messages. Specific applications MAY require different a Session-ID for accounting messages. These two sentences essentially say the same thing. Maybe it would be useful to say when the session ID is different. However, there are certain applications that require multiple accounting sub-sessions. Such applications would send messages with a constant Session-Id AVP, but a different Accounting-Sub-Session-Id AVP. In these cases, correlation is performed using the Session-Id. The last sentence essentially says what the sentence said previously. It is important to note that receiving a STOP_RECORD with no Accounting-Sub-Session-Id AVP when sub-sessions were originally used in the START_RECORD messages implies that all sub-sessions are terminated. Furthermore, there are certain applications where a user receives service from different access devices (e.g., Mobile IPv4), each with their own unique Session-Id. I am not sure is meant with the Mobile IPv4 example here. Is this referring to the case that a user might, as part of their service usage, trigger multiple Diameter exchanges from different Diameter clients, such as from the NAS and also from an application server? In such cases, the Acct-Multi-Session- Id AVP is used for correlation. I would move this sentence after the subsequent paragraph. During authorization, a server that determines that a request is for an existing session SHOULD include the Acct-Multi-Session-Id AVP, which the access device MUST include in all subsequent accounting messages. 10.1. Base Protocol Command AVP Table There are a couple of AVPs in the table that do not appear in any command. I wonder whether it makes sense to actually list them in the table at all. Instead, one could argue that they are rather defined in this document since they are of general usage for applications. 11. IANA Considerations Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting. I would remove this sentence as we already know that Diameter is used today outside the originally envisioned environment. The following values are allocated. Diameter Common Messages 0 NASREQ 1 [RFC4005] Mobile-IP 2 [RFC4004] Diameter Base Accounting 3 Relay 0xffffffff I would delete the rows for NASREQ and Mobile IP. 14. References Please move [RFC4004], [RFC4005], [RFC4006], [RFC4072], [RFC4740], [RFC4306], [RFC4291] to the informative reference section. [RFC3261] -- delete this reference. You are referencing the updated NAI RFC [RFC4282], instead of [4] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. I guess that this might cause backwards compatibility problems, see draft-korhonen-dime-nai-routing-00.txt. Appendix A. Acknowledgements I believe you should make a split between the acks from RFC 3588 and the acks for the bis version. Additionally, I believe that we should thank the folks from the interops and also the guys in the design team for their feedback. I have some comments regarding the security consideration section but I am going to cover them in a separate mail. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 14 21:09:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6653A6867; Sun, 14 Sep 2008 21:09:25 -0700 (PDT) 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 C2AE13A6867 for ; Sun, 14 Sep 2008 21:09:23 -0700 (PDT) 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 rBXS1olDORr4 for ; Sun, 14 Sep 2008 21:09:23 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 7953E3A67F4 for ; Sun, 14 Sep 2008 21:09:21 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so605398yxg.49 for ; Sun, 14 Sep 2008 21:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=vFDqLMvEyKL5q3dT6FX21J7SXzNowmXxht3iVg1bP3s=; b=Ia5B0tpJuP1YC0eBf+GxhRA2KrpZSKKUscrvv63EW1iWMbpXb0MoENrYdhoSqWblyc Y+xmi4txqLWY813HXdii03R9z4A7Od0HlOCRPq+v2hEJqAhAcToOhZm0CnbS1jsW5Abg gaB3IjJ3WJiX38s4K/SfhXNxKVNsZZizfGvcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rqR+o0eytcYl+UIPzlsdDtz5cTO4wJRE3tsjRunuSofM5LooLDfGgbJfXNRhCnRuao F+9DA+NphwHJJtfwSmhnoTM/iNjQ7cDIzDG6k9HPtv6wQDXf36UY2Xr9xcvPJRET9QW6 FWh7+/h4db98I6QzQ7tVdAesGaXI8oB111C6Q= Received: by 10.103.227.10 with SMTP id e10mr5083639mur.38.1221451770290; Sun, 14 Sep 2008 21:09:30 -0700 (PDT) Received: by 10.103.217.1 with HTTP; Sun, 14 Sep 2008 21:09:29 -0700 (PDT) Message-ID: <9ad5b0030809142109x5c812c03w44d02effe8599d00@mail.gmail.com> Date: Mon, 15 Sep 2008 09:39:29 +0530 From: "Jacob Martin" To: "Jouni Korhonen" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> <48CA49E8.1000606@gmx.net> <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jouni, On 9/12/08, Jouni Korhonen wrote: >> Anything could be done in software :), but I was just trying to get >> the answer for "Why Wm protocol designers did not opt for new app-id >> for Wm?" > > Because of the RFC3588 section 1.2.3 statement: > > "Creation of a new application should be viewed as a last resort. An > ... > " Thanks for the pointer. I think Wm designers should have applied for a new application-id to tackle the kind of scenarios which I had mentioned in my initial post. Anyways, I would raise it to the 3gpp people. > > Now that M-bit settings are wrong is just n error in TS29.234 I did not get you on this. could you please explain this again? > > Cheers, > Jouni > > > >> >> Cheers, >> Jacob >>> > TFYT! Jacob _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 14 21:14:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FD03A68A0; Sun, 14 Sep 2008 21:14:05 -0700 (PDT) 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 AA6903A68A0 for ; Sun, 14 Sep 2008 21:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 2PglbqVaMOEv for ; Sun, 14 Sep 2008 21:14:03 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id B62283A6807 for ; Sun, 14 Sep 2008 21:14:03 -0700 (PDT) Received: by gxk9 with SMTP id 9so23877563gxk.13 for ; Sun, 14 Sep 2008 21:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+Lz6UYpKWyR9+5WR1qJKfPBKrsvEOKEHcsoNPwNzthE=; b=dt62sfhEwdFORS3jvWCx6bFrIr4OoVaEOpnFwrXPPNCKzz9oyJcXeNuib1OENjKEbE PgpvRPr6IQRFBkRqEn704Pr4fxbWasFPL8Uzfu7OmVeABC7SWH78w2i0fQ0au4akXmDh f/ibIudEfcnCa9sWt8YLPO+PKphLaPh/gUgmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WH4PapcIdx5Uw9JKwAfPUuZh275VDbsrzA0hJUNmgK4+vDTWA7lgRSK4yh+jdGrRl/ WXrY22lf6gdBGLYGE16jrKsZ+D4JW1Vkcn/AdtjidVwRcrMqzAyK6obY28s74wdezqyj epmMcqGegHbRIHiuipzZoHPMmL1sAqudZKhzg= Received: by 10.103.172.9 with SMTP id z9mr5047967muo.122.1221452052215; Sun, 14 Sep 2008 21:14:12 -0700 (PDT) Received: by 10.103.217.1 with HTTP; Sun, 14 Sep 2008 21:14:12 -0700 (PDT) Message-ID: <9ad5b0030809142114m281ad463o676216a1e543a17e@mail.gmail.com> Date: Mon, 15 Sep 2008 09:44:12 +0530 From: "Jacob Martin" To: "Glen Zorn" In-Reply-To: <006c01c915ca$3d441960$b7cc4c20$@net> MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> <48CA49E8.1000606@gmx.net> <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> <006c01c915ca$3d441960$b7cc4c20$@net> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Glen, On 9/13/08, Glen Zorn wrote: > Jacob Martin [mailto://jacobmartin80@gmail.com] writes: > > ... > >> > I believe the terminology would be rather "... how could it be handed >> > over to the Wm application within ." >> > >> > This is largely an implementation specific issue. You need to enhance >> > your existing application logical to handle the additional AVPs that >> are >> > defined on top of EAP/NASREQ. >> > >> > Does this help? >> Anything could be done in software :), but I was just trying to get >> the answer for "Why Wm protocol designers did not opt for new app-id >> for Wm?" > > If that's the question, then pretty obviously asking the wrong people: Wm > isn't a product of the IETF, let alone this WG. Take your complainin' to > 3GPP ;-)... My initial post had some IETF products in my scenario, so I opted for this mailing list. I would raise this issue to the 3GPP as well. > > ... > > > Cheers, Jacob _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 14 21:44:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500323A6994; Sun, 14 Sep 2008 21:44:30 -0700 (PDT) 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 BE04B3A6930 for ; Sun, 14 Sep 2008 21:44:28 -0700 (PDT) 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 CRb1b1U0OBxA for ; Sun, 14 Sep 2008 21:44:28 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id C337528C0FC for ; Sun, 14 Sep 2008 21:44:17 -0700 (PDT) Received: from [62.71.220.133] (gprs-prointernet-ffdc4700-133.dhcp.inet.fi [62.71.220.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id E0C7321690E; Mon, 15 Sep 2008 07:44:20 +0300 (EEST) Message-ID: <48CDE824.3000506@kolumbus.fi> Date: Mon, 15 Sep 2008 07:44:20 +0300 From: Jouni User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jacob Martin References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <48C657BB.4050103@nict.go.jp> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> <48CA49E8.1000606@gmx.net> <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> <9ad5b0030809142109x5c812c03w44d02effe8599d00@mail.gmail.com> In-Reply-To: <9ad5b0030809142109x5c812c03w44d02effe8599d00@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jouni.korhonen@iki.fi List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jacob Martin kirjoitti: > >> Now that M-bit settings are wrong is just n error in TS29.234 >> > I did not get you on this. could you please explain this again? Wm has some new AVPs with M-bit set, as you also pointed out. This goes against the rule for "when to create a new application" as no new application is created. These are just errors in the current TS 29.234. Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 14 21:47:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D9628C0F7; Sun, 14 Sep 2008 21:47:49 -0700 (PDT) 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 DB20128C0F2 for ; Sun, 14 Sep 2008 21:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 5Qk-BROHEX1Y for ; Sun, 14 Sep 2008 21:47:44 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.234]) by core3.amsl.com (Postfix) with ESMTP id 7209B28C0F7 for ; Sun, 14 Sep 2008 21:47:43 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id f17so2599407qba.41 for ; Sun, 14 Sep 2008 21:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=x9XP9i4cjs+l//gVDENMA736THqkcsSfnZ7wvtomNcM=; b=KKUEQvyN8EmpJA0VJvFDbf8YMuwM4meQrUblmLBLp/SLPokAT/UoawOKm4KGTHpBkY sa1ZF/yN7pyGUsVLzDzy8YwgM2pvYT66cTQUt0sjFJUA6nwZwEfxypu0lQ7/7Hmm3FrU CBdm4xb/NF8xt8nfmRfxb/IJ/6jRcUZ87CjbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sx2vO4U3nuenj5NSVM0IUZYOqyAmhMyP49gl+6dCGHqEIvuYBP5Veb0XZUcPKVveI1 3GWku2dsKpP+12+CCZMZSzW8gJtE3SLcl0Y8MdLupzP8FMuWnc04PU7RA4rcXX43uJNC FobRMkTCvpi6LSfVrBLV+EAu7RnDf+HFd1Lzw= Received: by 10.103.243.7 with SMTP id v7mr5064504mur.118.1221454072880; Sun, 14 Sep 2008 21:47:52 -0700 (PDT) Received: by 10.103.217.1 with HTTP; Sun, 14 Sep 2008 21:47:52 -0700 (PDT) Message-ID: <9ad5b0030809142147p294d28aar777ccf49be3a3d8f@mail.gmail.com> Date: Mon, 15 Sep 2008 10:17:52 +0530 From: "Jacob Martin" To: jouni.korhonen@iki.fi In-Reply-To: <48CDE824.3000506@kolumbus.fi> MIME-Version: 1.0 Content-Disposition: inline References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com> <9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se> <9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com> <48CA49E8.1000606@gmx.net> <9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com> <9ad5b0030809142109x5c812c03w44d02effe8599d00@mail.gmail.com> <48CDE824.3000506@kolumbus.fi> Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On 9/15/08, Jouni wrote: > Jacob Martin kirjoitti: >> >>> Now that M-bit settings are wrong is just n error in TS29.234 >>> >> I did not get you on this. could you please explain this again? > Wm has some new AVPs with M-bit set, as you also pointed out. This goes > against the rule for "when to create a new application" as no new > application is > created. These are just errors in the current TS 29.234. ok... Thanks for the clarification. > > Jouni > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 14 21:57:09 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D393A6A22; Sun, 14 Sep 2008 21:57:09 -0700 (PDT) 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 8D2AD3A6A61 for ; Sun, 14 Sep 2008 21:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.481, 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 fbXfjA5j8NcC for ; Sun, 14 Sep 2008 21:57:04 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 792723A6A06 for ; Sun, 14 Sep 2008 21:57:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 81C959003E for ; Mon, 15 Sep 2008 00:57:10 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02360-18 for ; Mon, 15 Sep 2008 00:57:09 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 15 Sep 2008 00:57:09 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 00:57:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Sep 2008 10:27:05 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C146AC3@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Application-id reuse Thread-Index: AckW7kIimEr0T+9mS9K0hPjYI7985AAAGc+N References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com><9ad5b0030809120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com><59D7431DE2527D4CB0F1EFEDA5683ED3031A2270@SEHAN021MB.tcad.telia.se><9ad5b0030809120329j14337e78ib3bb01b139a9d90c@mail.gmail.com><48CA49E8.1000606@gmx.net><9ad5b0030809120411pe4f40dfl73f6616ac5c6d7c4@mail.gmail.com><9ad5b0030809142109x5c812c03w44d02effe8599d00@mail.gmail.com><48CDE824.3000506@kolumbus.fi> <9ad5b0030809142147p294d28aar777ccf49be3a3d8f@mail.gmail.com> From: "Sarkar, Biplab" To: "Jacob Martin" , X-OriginalArrivalTime: 15 Sep 2008 04:57:09.0665 (UTC) FILETIME=[82593910:01C916EF] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, I was thinking of the consequences of allowing AVP's to have the liberty to either set or un-set the M-bit. The sender may decide to set it depending upon its judgement about the version of the peer. - Will this give added help for extendability? - Is it really required to mandate the presence of M-bit for AVPs? Won't it be better to allow the sender to decide? Some comments on this please. Thanks & Regards, Biplab -----Original Message----- From: dime-bounces@ietf.org on behalf of Jacob Martin Sent: Mon 9/15/2008 10:17 AM To: jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse On 9/15/08, Jouni wrote: > Jacob Martin kirjoitti: >> >>> Now that M-bit settings are wrong is just n error in TS29.234 >>> >> I did not get you on this. could you please explain this again? > Wm has some new AVPs with M-bit set, as you also pointed out. This goes > against the rule for "when to create a new application" as no new > application is > created. These are just errors in the current TS 29.234. ok... Thanks for the clarification. > > Jouni > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 14 22:20:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637EB3A68A0; Sun, 14 Sep 2008 22:20:18 -0700 (PDT) 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 0C65C3A68A0 for ; Sun, 14 Sep 2008 22:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5J2ELR5UaSJ for ; Sun, 14 Sep 2008 22:20:16 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id AD7613A6358 for ; Sun, 14 Sep 2008 22:20:15 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m8F5H28B000901 for ; Mon, 15 Sep 2008 10:47:03 +0530 Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m8F5H26s000853 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 15 Sep 2008 10:47:02 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Mon, 15 Sep 2008 10:50:17 +0530 From: Ankit Kumar Sharma To: "Sarkar, Biplab" , Jacob Martin , "jouni.korhonen@iki.fi" Date: Mon, 15 Sep 2008 10:50:15 +0530 Thread-Topic: [Dime] Application-id reuse Thread-Index: AckW7kIimEr0T+9mS9K0hPjYI7985AAAGc+NAAB9ZCA= Message-ID: References: <9ad5b0030809090114m53eead10qfcb7b9c9b7fd8936@mail.gmail.com><9ad5b0030809 120239h3f8a45e3jcc9e9ec90269a97e@mail.gmail.com><59D7431DE2527D4CB0F1EFEDA5 683ED3031A2270@SEHAN021MB.tcad.telia.se><9ad5b0030809120329j14337e78ib3bb01 b139a9d90c@mail.gmail.com><48CA49E8.1000606@gmx.net><9ad5b0030809120411pe4f 40dfl73f6616ac5c6d7c4@mail.gmail.com><9ad5b0030809142109x5c812c03w44d02effe8599d00@mail.gmail.com><48CDE8 24.3000506@kolumbus.fi><9ad5b0030809142147p294d28aar777ccf49be3a3d8f@mail.gmail.com> <69FADB84C90B1248A7DE59422771FA0C146AC3@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C146AC3@exchindia3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Application-id reuse X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Biplab, -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Sarkar, Biplab Sent: Monday, September 15, 2008 10:27 AM To: Jacob Martin; jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse Hi all, I was thinking of the consequences of allowing AVP's to have the liberty to either set or un-set the M-bit. The sender may decide to set it depending upon its judgement about the version of the peer. < I hope you are referring to section 4.1 of RFC 3588. " A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problem "> - Will this give added help for extendability? - Is it really required to mandate the presence of M-bit for AVPs? Won't it be better to allow the sender to decide? < To define any specification, there should be mandate on some of the basic AVPs which helps in core functioning. For proprietary extensions, vendors are allowed to define custom AVPs to meet their requirements> Some comments on this please. Thanks & Regards, Biplab -----Original Message----- From: dime-bounces@ietf.org on behalf of Jacob Martin Sent: Mon 9/15/2008 10:17 AM To: jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse On 9/15/08, Jouni wrote: > Jacob Martin kirjoitti: >> >>> Now that M-bit settings are wrong is just n error in TS29.234 >>> >> I did not get you on this. could you please explain this again? > Wm has some new AVPs with M-bit set, as you also pointed out. This goes > against the rule for "when to create a new application" as no new > application is > created. These are just errors in the current TS 29.234. ok... Thanks for the clarification. > > Jouni > > > > _______________________________________________ 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 Thanks, Ankit "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Sep 15 14:15:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98C83A6945; Mon, 15 Sep 2008 14:15:02 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0871F3A690F; Mon, 15 Sep 2008 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080915211502.0871F3A690F@core3.amsl.com> Date: Mon, 15 Sep 2008 14:15:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-11.txt Pages : 37 Date : 2008-09-15 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-09-15140806.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Sep 16 03:11:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7C428C198; Tue, 16 Sep 2008 03:11:01 -0700 (PDT) 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 2697A28C198; Tue, 16 Sep 2008 03:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.105 X-Spam-Level: * X-Spam-Status: No, score=1.105 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_56=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 7jqVE2FBZ8nz; Tue, 16 Sep 2008 03:11:00 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 0DA3F28C197; Tue, 16 Sep 2008 03:11:00 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7A00JH49M9W2@szxga02-in.huawei.com>; Tue, 16 Sep 2008 18:10:57 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7A00AAD9M96R@szxga02-in.huawei.com>; Tue, 16 Sep 2008 18:10:57 +0800 (CST) Received: from srinivasch ([10.18.28.82]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K7A005JH9M4OB@szxml04-in.huawei.com>; Tue, 16 Sep 2008 18:10:57 +0800 (CST) Date: Tue, 16 Sep 2008 15:40:51 +0530 From: srinivas In-reply-to: To: dime-request@ietf.org, dime@ietf.org Message-id: <005b01c917e4$806f4d10$521c120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AckW7kIimEr0T+9mS9K0hPjYI7985AAAGc+NAAB9ZCAAPOmr0A== Subject: [Dime] Silly doubt on InbandSecurity handling in CER X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: srinivasch@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Silly doubt.Suppose a Diameter node has received the CER with inband-security value as 2 then does the node has to respond with DIAMETER_NO_COMMON_SECURITY (5017) or DIAMETER_INVALID_AVP_VALUE (5004) or any one is fine. >From my understanding if the node sends DIAMETER_INVALID_AVP_VALUE (5004) then the receiver will easily come to know that AVP value is wrong. Please give your thoughts/comments on the same. Thanks & Regards, Srinivas CH, Huawei Technologis India Pvt Ltd, 1st Floor DIamond District, Airport Road, Bangalore-8, Contact: (Off) 080-41117676 ext: 3008 (Mob) +919731316362. This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ankit Kumar Sharma Sent: Monday, September 15, 2008 10:50 AM To: Sarkar, Biplab; Jacob Martin; jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse Hi Biplab, -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Sarkar, Biplab Sent: Monday, September 15, 2008 10:27 AM To: Jacob Martin; jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse Hi all, I was thinking of the consequences of allowing AVP's to have the liberty to either set or un-set the M-bit. The sender may decide to set it depending upon its judgement about the version of the peer. < I hope you are referring to section 4.1 of RFC 3588. " A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problem "> - Will this give added help for extendability? - Is it really required to mandate the presence of M-bit for AVPs? Won't it be better to allow the sender to decide? < To define any specification, there should be mandate on some of the basic AVPs which helps in core functioning. For proprietary extensions, vendors are allowed to define custom AVPs to meet their requirements> Some comments on this please. Thanks & Regards, Biplab -----Original Message----- From: dime-bounces@ietf.org on behalf of Jacob Martin Sent: Mon 9/15/2008 10:17 AM To: jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse On 9/15/08, Jouni wrote: > Jacob Martin kirjoitti: >> >>> Now that M-bit settings are wrong is just n error in TS29.234 >>> >> I did not get you on this. could you please explain this again? > Wm has some new AVPs with M-bit set, as you also pointed out. This goes > against the rule for "when to create a new application" as no new > application is > created. These are just errors in the current TS 29.234. ok... Thanks for the clarification. > > Jouni > > > > _______________________________________________ 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 Thanks, Ankit "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 16 03:31:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B2528C1C9; Tue, 16 Sep 2008 03:31:49 -0700 (PDT) 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 9C53028C1C9 for ; Tue, 16 Sep 2008 03:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.356 X-Spam-Level: X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_NJABL_PROXY=1.643] 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 dbB1bNPObV7H for ; Tue, 16 Sep 2008 03:31:48 -0700 (PDT) Received: from mail12.opentransfer.com (mail12.opentransfer.com [76.162.254.12]) by core3.amsl.com (Postfix) with SMTP id 47BF828C1C7 for ; Tue, 16 Sep 2008 03:31:48 -0700 (PDT) Received: (qmail 30629 invoked by uid 399); 16 Sep 2008 10:25:20 -0000 Received: from unknown (HELO himalaya) (61.95.206.132) by mail12.opentransfer.com with SMTP; 16 Sep 2008 10:25:20 -0000 From: "Nilanjan Sarkar" To: , , Date: Tue, 16 Sep 2008 15:55:17 +0530 Message-ID: <000001c917e6$853ca1b0$1401a8c0@himalaya> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-reply-to: <005b01c917e4$806f4d10$521c120a@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Subject: Re: [Dime] Silly doubt on InbandSecurity handling in CER X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Srinivas, According to RFC3588, Inband-Security-Id may support other security Ids apart from 0 and 1 (ref page 80), and thus value 2 may not be invalid AVP value for Inband-Security-Id AVP, so DIAMETER_INVALID_AVP_VALUE may not be appropriate. Kind Regards, Nilanjan -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of srinivas Sent: Tuesday, September 16, 2008 3:41 PM To: dime-request@ietf.org; dime@ietf.org Subject: [Dime] Silly doubt on InbandSecurity handling in CER Hi, Silly doubt.Suppose a Diameter node has received the CER with inband-security value as 2 then does the node has to respond with DIAMETER_NO_COMMON_SECURITY (5017) or DIAMETER_INVALID_AVP_VALUE (5004) or any one is fine. >From my understanding if the node sends DIAMETER_INVALID_AVP_VALUE (5004) then the receiver will easily come to know that AVP value is wrong. Please give your thoughts/comments on the same. Thanks & Regards, Srinivas CH, Huawei Technologis India Pvt Ltd, 1st Floor DIamond District, Airport Road, Bangalore-8, Contact: (Off) 080-41117676 ext: 3008 (Mob) +919731316362. This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ankit Kumar Sharma Sent: Monday, September 15, 2008 10:50 AM To: Sarkar, Biplab; Jacob Martin; jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse Hi Biplab, -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Sarkar, Biplab Sent: Monday, September 15, 2008 10:27 AM To: Jacob Martin; jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse Hi all, I was thinking of the consequences of allowing AVP's to have the liberty to either set or un-set the M-bit. The sender may decide to set it depending upon its judgement about the version of the peer. < I hope you are referring to section 4.1 of RFC 3588. " A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problem "> - Will this give added help for extendability? - Is it really required to mandate the presence of M-bit for AVPs? Won't it be better to allow the sender to decide? < To define any specification, there should be mandate on some of the basic AVPs which helps in core functioning. For proprietary extensions, vendors are allowed to define custom AVPs to meet their requirements> Some comments on this please. Thanks & Regards, Biplab -----Original Message----- From: dime-bounces@ietf.org on behalf of Jacob Martin Sent: Mon 9/15/2008 10:17 AM To: jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse On 9/15/08, Jouni wrote: > Jacob Martin kirjoitti: >> >>> Now that M-bit settings are wrong is just n error in TS29.234 >>> >> I did not get you on this. could you please explain this again? > Wm has some new AVPs with M-bit set, as you also pointed out. This goes > against the rule for "when to create a new application" as no new > application is > created. These are just errors in the current TS 29.234. ok... Thanks for the clarification. > > Jouni > > > > _______________________________________________ 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 Thanks, Ankit "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.21/1673 - Release Date: 9/15/2008 6:49 PM _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Sep 16 04:37:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D35E28C1E1; Tue, 16 Sep 2008 04:37:59 -0700 (PDT) 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 AB3BC3A6B0E; Tue, 16 Sep 2008 04:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehUkNSuuywzk; Tue, 16 Sep 2008 04:37:57 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 0217B28C1E3; Tue, 16 Sep 2008 04:37:56 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m8GBYh8C001697; Tue, 16 Sep 2008 17:04:43 +0530 Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m8GBYhA7001662 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 16 Sep 2008 17:04:43 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Tue, 16 Sep 2008 17:08:06 +0530 From: Ankit Kumar Sharma To: "srinivasch@huawei.com" Date: Tue, 16 Sep 2008 17:08:03 +0530 Thread-Topic: [Dime] Silly doubt on InbandSecurity handling in CER Thread-Index: AckW7kIimEr0T+9mS9K0hPjYI7985AAAGc+NAAB9ZCAAPOmr0AAC+dLg Message-ID: References: <005b01c917e4$806f4d10$521c120a@china.huawei.com> In-Reply-To: <005b01c917e4$806f4d10$521c120a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime-request@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Silly doubt on InbandSecurity handling in CER X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Sri, It should return DIAMETER_NO_COMMON_SECURITY. Cheers, Ankit -----Original Message----- From: srinivas [mailto:srinivasch@huawei.com] Sent: Tuesday, September 16, 2008 3:41 PM To: dime-request@ietf.org; dime@ietf.org Cc: Ankit Kumar Sharma; 'Sarkar, Biplab'; 'Jacob Martin'; jouni.korhonen@iki.fi Subject: [Dime] Silly doubt on InbandSecurity handling in CER Hi, Silly doubt.Suppose a Diameter node has received the CER with inband-security value as 2 then does the node has to respond with DIAMETER_NO_COMMON_SECURITY (5017) or DIAMETER_INVALID_AVP_VALUE (5004) or any one is fine. >From my understanding if the node sends DIAMETER_INVALID_AVP_VALUE (5004) then the receiver will easily come to know that AVP value is wrong. Please give your thoughts/comments on the same. Thanks & Regards, Srinivas CH, Huawei Technologis India Pvt Ltd, 1st Floor DIamond District, Airport Road, Bangalore-8, Contact: (Off) 080-41117676 ext: 3008 (Mob) +919731316362. This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ankit Kumar Sharma Sent: Monday, September 15, 2008 10:50 AM To: Sarkar, Biplab; Jacob Martin; jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse Hi Biplab, -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Sarkar, Biplab Sent: Monday, September 15, 2008 10:27 AM To: Jacob Martin; jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse Hi all, I was thinking of the consequences of allowing AVP's to have the liberty to either set or un-set the M-bit. The sender may decide to set it depending upon its judgement about the version of the peer. < I hope you are referring to section 4.1 of RFC 3588. " A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problem "> - Will this give added help for extendability? - Is it really required to mandate the presence of M-bit for AVPs? Won't it be better to allow the sender to decide? < To define any specification, there should be mandate on some of the basic AVPs which helps in core functioning. For proprietary extensions, vendors are allowed to define custom AVPs to meet their requirements> Some comments on this please. Thanks & Regards, Biplab -----Original Message----- From: dime-bounces@ietf.org on behalf of Jacob Martin Sent: Mon 9/15/2008 10:17 AM To: jouni.korhonen@iki.fi Cc: dime@ietf.org Subject: Re: [Dime] Application-id reuse On 9/15/08, Jouni wrote: > Jacob Martin kirjoitti: >> >>> Now that M-bit settings are wrong is just n error in TS29.234 >>> >> I did not get you on this. could you please explain this again? > Wm has some new AVPs with M-bit set, as you also pointed out. This goes > against the rule for "when to create a new application" as no new > application is > created. These are just errors in the current TS 29.234. ok... Thanks for the clarification. > > Jouni > > > > _______________________________________________ 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 Thanks, Ankit "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 18 18:57:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634693A6BDB; Thu, 18 Sep 2008 18:57:59 -0700 (PDT) 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 C9A1E3A6BA4 for ; Thu, 18 Sep 2008 18:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.683 X-Spam-Level: X-Spam-Status: No, score=0.683 tagged_above=-999 required=5 tests=[AWL=1.422, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq0wIiSbqnws for ; Thu, 18 Sep 2008 18:57:49 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id ABB7B3A6BDB for ; Thu, 18 Sep 2008 18:57:48 -0700 (PDT) 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 <0K7F00LC86SP0J@szxga01-in.huawei.com> for dime@ietf.org; Fri, 19 Sep 2008 09:58:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7F008DC6SPUQ@szxga01-in.huawei.com> for dime@ietf.org; Fri, 19 Sep 2008 09:58:01 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K7F003AK6SPV9@szxml03-in.huawei.com> for dime@ietf.org; Fri, 19 Sep 2008 09:58:01 +0800 (CST) Date: Fri, 19 Sep 2008 09:58:01 +0800 From: Tina TSOU To: tsg11q5@itu.int Message-id: <004301c919fb$2594bc40$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/mixed; boundary="Boundary_(ID_RkTOWHFs7bU47+5q9YHI/g)" X-Priority: 3 X-MSMail-priority: Normal Cc: dime@ietf.org, tsbsg11@itu.int Subject: [Dime] [Q5/11] Fw: how to update Q.3303.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_RkTOWHFs7bU47+5q9YHI/g) Content-type: multipart/alternative; boundary="Boundary_(ID_TlH3hjaWTH5t5NxYDg3+xQ)" --Boundary_(ID_TlH3hjaWTH5t5NxYDg3+xQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Dong, Thank you for letting us to know the situation. The situation of Q.3303.3 is in this link - pre-published. http://www.itu.int/rec/T-REC-Q.3303.3 If it is easy, clear, you could contact TSB to update it during the publication process. If not, you could select any of the following ways. A) Create a separate document of Amendment for Q.3303.3 B) Do it in Q.3323 Rw Diameter version 2 If I'm wrong in the procedure, anyone in the list please correct me. -HTH- B. R. Tina ITU-T Q.5/11 Rapporteur ----- Original Message ----- From: Sun, Dong (Dong) To: Tina TSOU Cc: Tom Taylor ; Huanghexian Sent: Friday, September 19, 2008 3:01 AM Subject: how to update Q.3303.3 Tina et al, as a follow-up for the q.3303.3, i am responding to Hannes's comments (attached). Since those issues are originally from other SDO's specs not by this spec. I am not sure if we can fix all them alone (e.g. the change of ANBF for some madantory AVPs) since it will cause inerop issue. Meanwhile it is possible to remedy some "M/P" bit problems although they are copied from other specs. Just wonderin what's the procedure to update the Q.3303.3? Thanks, Dong -------------------------------------------------------------------------------- From: Sun, Dong (Dong) Sent: Sunday, August 31, 2008 9:39 PM To: 'Tina TSOU'; 'Huanghexian' Cc: 'Tom Taylor' Subject: RE: [Q5/11] Re: DISCUSS: draft-sun-dime-itu-t-rw Tina, I am doing well. Thanks for the caring. this is just a suggestion to minimize the impact on Rw work. I personally can follow up the IETF mess, but does not expect they will resolve it soon since it is totally out of my control in IETF (and not my main focus at the moment). hope it will not affect the Q5/11 work too much. Dong -------------------------------------------------------------------------------- From: Tina TSOU [mailto:tena@huawei.com] Sent: Sunday, August 31, 2008 8:44 PM To: Huanghexian; Sun, Dong (Dong) Cc: Tom Taylor; tsg11q5@itu.int Subject: [Q5/11] Re: DISCUSS: draft-sun-dime-itu-t-rw Hi Dong, We all hope you get out the mess soon. I sent you a SMS, no response, so we are concerned about your current situation. You are the editor of Rw version 1. IETF Diameter ID is only assigned to those published standards, in other words Rw v1 rather than Rw v2. B. R. Tina ----- Original Message ----- From: Sun, Dong (Dong) To: Tina TSOU ; Huanghexian Cc: Tom Taylor Sent: Sunday, August 31, 2008 2:05 PM Subject: FW: DISCUSS: draft-sun-dime-itu-t-rw Tina, Hexian, FYI. It looks like the IETF has some problem to approve the informational RFC for the Rw application ID due to its own internal issue (sort of bureaucracy :-). In order to complete the Rw spec asap, I think we may find a way out ourselves. I remembered Tom ever mentioned to get new application ID for the Rs. Maybe we could do the same thing . In addition, since I am in this mess and not the editor anymore, It is more appropriate to let Hexian follow up as Tom suggests. What do you think? Tom, Could you elaborate on the steps to register a new application ID to IANA without sending the informational RFC? BTW, I will not attend the Sep meeting in persion. Wish your guys have good time there. Rgs, Dong -----Original Message----- From: Mark Townsley [mailto:townsley@cisco.com] Sent: Saturday, August 30, 2008 9:14 AM To: Hannes Tschofenig Cc: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com; draft-sun-dime-itu-t-rw@tools.ietf.org; Sun, Dong (Dong) Subject: Re: DISCUSS: draft-sun-dime-itu-t-rw Hannes Tschofenig wrote: > Hi Dan, > > let me quickly respond to this issue: > > >> As expected the document was not approved by the IESG and is now in >> AD Follow-up. >> >> Beyond the two DISCUSSes there were two ABSTAIN ballots. >> >> The principal concern that I heard was related to the fact that the >> current process followed by the draft did not ensure a sufficient >> level of review from the IETF to ensure that it really meets the IETF >> consensus. >> >> In order to overcome this I suggest that we do the following: >> >> 1. Ask for at least one more review (two is better) from the >> AAA-Doctors team or DIME WG making also sure that the reviewers also >> include reading the relevant parts in the ITU-T document in their >> review (Hannes, can you ask Bernard to be one of the reviewers?) >> > > I sent a mail to him. > > > >> 2. Explain to the IESG why the DIME Working Group did not take this >> work as a WG chartered item (hannes, please write a short >> explanation, also include the discussions around 3588bis) >> > > draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using Diameter. In the DIME working group we also have a document that deals with QoS signaling, namely http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt. It does, however, not cover NAT and Firewall signaling aspects. > > Other SDOs are, however, not required to use the work we do in the IETF on certain Diameter applications. Additionally, they may enhance or modify it. There are many reasons why this happens and I will not go into the details of those. Call it a matter of life that has todo with psychology rather than technical arguments. > > For us in DIME it does not really matter why ITU-T works on this specific subject and it does not matter to us from a review point of view either. > If that is truly the consensus of the IETF, then the IANA policies and protocol itself should allow a clean division between one SDO and another. The existence of this RFC would seem to be proof point that this is not the case. > The reason why the ITU-T (and previously OMA with http://tools.ietf.org/html/rfc5224) came to the DIME working group is actually related to a suggestion from our side (based on the Diameter extensibility discussions we had) to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP (i.e, those marked as {}). By defining new Command Codes we believe to better avoid interoperability problems. > > The OMA has followed that suggestion (and so did ITU-T, to some extend) but obviously ran into an issue with the requirements for the allocation of Command Codes (compared to the allocation of Application IDs) based on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to register applications without going through the IETF process but has different rules for the allocation of Command Codes. The DIME working group had a long discussion about this issue and decided to change the rules for allocating Command Codes with the revision of RFC 3588 (see http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt) and to align the procedure with the way how Application IDs are requested. The main reasons for this decision were the following: > > * We did not want to encourage SDOs to misuse Diameter Command Codes when they don't want to come to the IETF (and thereby causing interoperability issues). > > * We did not want to drag all the SDOs to the IETF when it comes to extending Diameter. Diameter is a very popular protocols among other SDOs and this approach would not scale very well nor are we the experts in all the applications areas people have in mind where Diameter could be used. > This may be the case with Diameter, and that is perfectly fine if in fact that is the consensus of the IETF. But understand that it is very much not the case with other IETF protocols. The IETF community tends to be *quite* concerned when other SDOs want to extend our protocols without our knowledge or consent. > * Some of us believe that the decision to have different rules for Application ID allocation and Command Code assignment was a mistake since it does not make a lot of sense from a logical point of view. > > * We should not treat the 3GPP differently to other SDOs since the 3GPP was given a bunch of Command Codes without a corresponding specification (see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be consistent in our behavior. > It's not about the SDOs themselves as much as it is about the mechanism being proposed. That is why some of us are concerned as to whether the documents that this ID point to have been reviewed. It's the mechanism itself that is important, not just the container. If you are saying that the IETF wants to draw an architectural line such that anyone can use Diameter in anyway they choose without involving the IETF, that's fine, but there needs to be consensus on that and the policies need to reflect it. Since this is most definitely not always the case for other protocols, we need to be very clear to ourselves, and to other SDOs, on this matter. > As such, we came up with the idea to have an "interim" solution for dealing with requests regarding Diameter Command Codes before RFC 3588bis gets published as an RFC. > > > >> 3. Propose text for an update to the document including reasoning for >> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will >> draft such a text >> > > I will think about text. Maybe it is lack of imagination on how > protocols could be used? Wouldn't be the first time that a protocol is > used in a way not originally envisioned. Example: RSVP - RSVP-TE > > Funny enough, the idea about using Diameter for the purpose of NAT and > firewall signaling actually came from the IETF MIDCOM working group, > see http://www.ietf.org/rfc/rfc4097.txt > Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite protocol and it turns out that this was the wrong decision. Hard to predict preferences... > > > >> Also in parallel the DIME WG should do the best to accelerate the >> approval and submission of RFC3588 to the IESG so that we will need >> to deal with as few such cases in the future as possible (ideally zero). >> > > That's certainly a good idea. We are having a final round of reviews and I have asked the authors of the draft to also re-read the document to avoid problems in later stages (as they have happened with other Diameter documents already). > I would be far, far, more comfortable seeing IETF consensus on the interaction policies with other SDOs with respect to Diameter before approving draft-sun-dime-itu-t-rw. If the revision to RFC3588 helps to clarify that, please accelerate its publication. Thanks, - Mark > Ciao > Hannes > > >> Thanks and Regards, >> >> Dan >> >> >> >>> -----Original Message----- >>> From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf >>> Of Chris Newman >>> Sent: Thursday, August 28, 2008 7:29 PM >>> To: iesg@ietf.org >>> Cc: Hannes.Tschofenig@gmx.net; >>> draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com >>> Subject: DISCUSS: draft-sun-dime-itu-t-rw >>> >>> Discuss: >>> As this issue was raised during IETF review and appears to concern a >>> number of area directors, I'm holding an actionable discuss >>> position: >>> >>> Based on GEN-ART review responses, it appears this statement in the >>> DIAMETER base spec: >>> >>> "Diameter is not intended as a general purpose protocol, and >>> allocations SHOULD NOT be made for purposes unrelated to >>> authentication, authorization or accounting." >>> >>> is spurious and not being followed. If we're not going to follow >>> this rule (which is fine if there's rough consensus not to follow >>> it), I believe it's important that it be documented why we're not >>> following the rule (a "SHOULD NOT" >>> requires justification). Various approaches I find acceptable are: >>> 1. The document approval text includes reasoning for ignoring >>> SHOULD NOT 2. An update to the document text includes reasoning for >>> ignoring >>> SHOULD NOT >>> 3. Hold this until a small RFC is published that updates 3588 to >>> change or remove the SHOULD NOT restriction. >>> >>> >>> >>> > > --Boundary_(ID_TlH3hjaWTH5t5NxYDg3+xQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi Dong,
Thank you for letting us to know the situation.
 
The situation of Q.3303.3 is in this link - pre-published.
http://www.itu.int/rec/T-REC-Q.3303.3
 
If it is easy, clear, you could contact TSB to update it during the publication process.
If not, you could select any of the following ways.
A) Create a separate document of Amendment for Q.3303.3
B) Do it in Q.3323 Rw Diameter version 2
 
If I'm wrong in the procedure, anyone in the list please correct me.
 
-HTH-
 
B. R.
Tina
ITU-T Q.5/11 Rapporteur
 
----- Original Message -----
Sent: Friday, September 19, 2008 3:01 AM
Subject: how to update Q.3303.3

Tina et al,
 
as a follow-up for the q.3303.3, i am responding to Hannes's comments (attached). Since those issues are originally from other SDO's specs not by this spec. I am not sure if we can fix all them alone (e.g. the change of ANBF for some madantory AVPs) since it will cause inerop issue. Meanwhile it is possible to remedy some "M/P" bit problems although they are copied from other specs.
 
Just wonderin what's the procedure to update the Q.3303.3?
 
Thanks,
Dong

From: Sun, Dong (Dong)
Sent: Sunday, August 31, 2008 9:39 PM
To: 'Tina TSOU'; 'Huanghexian'
Cc: 'Tom Taylor'
Subject: RE: [Q5/11] Re: DISCUSS: draft-sun-dime-itu-t-rw

Tina,
I am doing well. Thanks for the caring.
this is just a suggestion to minimize the impact on Rw work.  I personally can follow up the IETF mess, but does not expect they will resolve it soon since it is totally out of my control in IETF (and not my main focus at the moment). hope it will not affect the Q5/11 work too much.
 
Dong

From: Tina TSOU [mailto:tena@huawei.com]
Sent: Sunday, August 31, 2008 8:44 PM
To: Huanghexian; Sun, Dong (Dong)
Cc: Tom Taylor; tsg11q5@itu.int
Subject: [Q5/11] Re: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dong,
We all hope you get out the mess soon. I sent you a SMS, no response, so we are concerned about your current situation.
You are the editor of Rw version 1. IETF Diameter ID is only assigned to those published standards, in other words Rw v1 rather than Rw v2.
 
B. R.
Tina
----- Original Message -----
Sent: Sunday, August 31, 2008 2:05 PM
Subject: FW: DISCUSS: draft-sun-dime-itu-t-rw

Tina, Hexian,

FYI. It looks like the IETF has some problem to approve the
informational RFC for the Rw application ID due to its own internal
issue (sort of bureaucracy :-).
In order to complete the Rw spec asap, I think we may find a way out
ourselves. I remembered Tom ever mentioned to get new application ID for
the Rs. Maybe we could do the same thing .

In addition, since I am in this mess and not the editor anymore, It is
more appropriate to let Hexian follow up as Tom suggests.

What do you think?

Tom,

Could you elaborate on the steps to register a new application ID to
IANA without sending the informational RFC?

BTW, I will not attend the Sep meeting in persion.
Wish your guys have good time there.

Rgs,
Dong

-----Original Message-----
From: Mark Townsley [mailto:townsley@cisco.com]
Sent: Saturday, August 30, 2008 9:14 AM
To: Hannes Tschofenig
Cc: Romascanu, Dan (Dan); iesg@ietf.org; chris.newman@sun.com;
draft-sun-dime-itu-t-rw@tools.ietf.org; Sun, Dong (Dong)
Subject: Re: DISCUSS: draft-sun-dime-itu-t-rw

Hannes Tschofenig wrote:
> Hi Dan,
>
> let me quickly respond to this issue:
>
>  
>> As expected the document was not approved by the IESG and is now in
>> AD Follow-up.
>>
>> Beyond the two DISCUSSes there were two ABSTAIN ballots.
>>
>> The principal concern that I heard was related to the fact that the
>> current process followed by the draft did not ensure a sufficient
>> level of review from the IETF to ensure that it really meets the IETF

>> consensus.
>>
>> In order to overcome this I suggest that we do the following:
>>
>> 1. Ask for at least one more review (two is better) from the
>> AAA-Doctors team or DIME WG making also sure that the reviewers also
>> include reading the relevant parts in the ITU-T document in their
>> review (Hannes, can you ask Bernard to be one of the reviewers?)
>>    
>
> I sent a mail to him.
>
>
>  
>> 2. Explain to the IESG why the DIME Working Group did not take this
>> work as a WG chartered item (hannes, please write a short
>> explanation, also include the discussions around 3588bis)
>>    
>
> draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using
Diameter. In the DIME working group we also have a document that deals
with QoS signaling, namely
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt.
It does, however, not cover NAT and Firewall signaling aspects.
>
> Other SDOs are, however, not required to use the work we do in the
IETF on certain Diameter applications. Additionally, they may enhance or
modify it. There are many reasons why this happens and I will not go
into the details of those. Call it a matter of life that has todo with
psychology rather than technical arguments.
>
> For us in DIME it does not really matter why ITU-T works on this
specific subject and it does not matter to us from a review point of
view either.
>  
If that is truly the consensus of the IETF, then the IANA policies and
protocol itself should allow a clean division between one SDO and
another. The existence of this RFC would seem to be proof point that
this is not the case.
> The reason why the ITU-T (and previously OMA with
http://tools.ietf.org/html/rfc5224) came to the DIME working group is
actually related to a suggestion from our side (based on the Diameter
extensibility discussions we had) to define new Command Codes whenever
the ABNF of a command is modified by adding, removing or semantically
changing required AVP (i.e, those marked as {}). By defining new Command
Codes we believe to better avoid interoperability problems.
>
> The OMA has followed that suggestion (and so did ITU-T, to some
extend) but obviously ran into an issue with the requirements for the
allocation of Command Codes (compared to the allocation of Application
IDs) based on what RFC 3588 says. RFC 3588 allows vendors (in this case
SDOs) to register applications without going through the IETF process
but has different rules for the allocation of Command Codes. The DIME
working group had a long discussion about this issue and decided to
change the rules for allocating Command Codes with the revision of RFC
3588 (see
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt)
and to align the procedure with the way how Application IDs are
requested. The main reasons for this decision were the following:
>
> * We did not want to encourage SDOs to misuse Diameter Command Codes
when they don't want to come to the IETF (and thereby causing
interoperability issues).
>
> * We did not want to drag all the SDOs to the IETF when it comes to
extending Diameter. Diameter is a very popular protocols among other
SDOs and this approach would not scale very well nor are we the experts
in all the applications areas people have in mind where Diameter could
be used.
>  
This may be the case with Diameter, and that is perfectly fine if in
fact that is the consensus of the IETF. But understand that it is very
much not the case with other IETF protocols. The IETF community tends to
be *quite* concerned when other SDOs want to extend our protocols
without our knowledge or consent.
> * Some of us believe that the decision to have different rules for
Application ID allocation and Command Code assignment was a mistake
since it does not make a lot of sense from a logical point of view.
>
> * We should not treat the 3GPP differently to other SDOs since the
3GPP was given a bunch of Command Codes without a corresponding
specification (see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We
try to be consistent in our behavior.
>  
It's not about the SDOs themselves as much as it is about the mechanism
being proposed. That is why some of us are concerned as to whether the
documents that this ID point to have been reviewed. It's the mechanism
itself that is important, not just the container.

If you are saying that the IETF wants to draw an architectural line such
that anyone can use Diameter in anyway they choose without involving the
IETF, that's fine, but there needs to be consensus on that and the
policies need to reflect it. Since this is most definitely not always
the case for other protocols, we need to be very clear to ourselves, and
to other SDOs, on this matter.
> As such, we came up with the idea to have an "interim" solution for
dealing with requests regarding Diameter Command Codes before RFC
3588bis gets published as an RFC.
>
>
>  
>> 3. Propose text for an update to the document including reasoning for

>> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will
>> draft such a text
>>    
>
> I will think about text. Maybe it is lack of imagination on how
> protocols could be used? Wouldn't be the first time that a protocol is

> used in a way not originally envisioned. Example: RSVP - RSVP-TE
>
> Funny enough, the idea about using Diameter for the purpose of NAT and

> firewall signaling actually came from the IETF MIDCOM working group,
> see http://www.ietf.org/rfc/rfc4097.txt
> Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their
favorite protocol and it turns out that this was the wrong decision.
Hard to predict preferences...
>
>
>  
>> Also in parallel the DIME WG should do the best to accelerate the
>> approval and submission of RFC3588 to the IESG so that we will need
>> to deal with as few such cases in the future as possible (ideally
zero).
>>    
>
> That's certainly a good idea. We are having a final round of reviews
and I have asked the authors of the draft to also re-read the document
to avoid problems in later stages (as they have happened with other
Diameter documents already).
>  
I would be far, far, more comfortable seeing IETF consensus on the
interaction policies with other SDOs with respect to Diameter before
approving draft-sun-dime-itu-t-rw. If the revision to RFC3588 helps to
clarify that, please accelerate its publication.

Thanks,

- Mark
> Ciao
> Hannes
>
>  
>> Thanks and Regards,
>>
>> Dan
>>
>>
>>    
>>> -----Original Message-----
>>> From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On Behalf

>>> Of Chris Newman
>>> Sent: Thursday, August 28, 2008 7:29 PM
>>> To: iesg@ietf.org
>>> Cc: Hannes.Tschofenig@gmx.net;
>>> draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com
>>> Subject: DISCUSS: draft-sun-dime-itu-t-rw
>>>
>>> Discuss:
>>> As this issue was raised during IETF review and appears to concern a

>>> number of area directors, I'm holding an actionable discuss
>>> position:
>>>
>>> Based on GEN-ART review responses, it appears this statement in the
>>> DIAMETER base spec:
>>>
>>>   "Diameter is not intended as a general purpose protocol, and
>>>    allocations SHOULD NOT be made for purposes unrelated to
>>>    authentication, authorization or accounting."
>>>
>>> is spurious and not being followed.  If we're not going to follow
>>> this rule (which is fine if there's rough consensus not to follow
>>> it), I believe it's important that it be documented why we're not
>>> following the rule (a "SHOULD NOT"
>>> requires justification).  Various approaches I find acceptable are:
>>>  1. The document approval text includes reasoning for ignoring
>>> SHOULD NOT  2. An update to the document text includes reasoning for

>>> ignoring
>>>     SHOULD NOT
>>>  3. Hold this until a small RFC is published that updates 3588 to
>>>     change or remove the SHOULD NOT restriction.
>>>
>>>
>>>
>>>      
>
>  
--Boundary_(ID_TlH3hjaWTH5t5NxYDg3+xQ)-- --Boundary_(ID_RkTOWHFs7bU47+5q9YHI/g) Content-type: message/rfc822; name="[Dime] Review of draft-sun-dime-itu-t-rw-01.eml" Content-disposition: attachment; filename="[Dime] Review of draft-sun-dime-itu-t-rw-01.eml" Received: from ilexp03.ndc.lucent.com ([135.3.39.50]) by ILEXC2U01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 08:59:59 -0500 Received: from ihemail3.lucent.com ([135.245.2.37]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 08:59:49 -0500 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by ihemail3.lucent.com (8.13.8/IER-i) with ESMTP id m7SDxmDK024030; Thu, 28 Aug 2008 08:59:48 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0492A28C2E2; Thu, 28 Aug 2008 06:59:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DAC228C273 for ; Thu, 28 Aug 2008 06:59:44 -0700 (PDT) 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 xaZkJAVSk-nc for ; Thu, 28 Aug 2008 06:59:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 736F53A6945 for ; Thu, 28 Aug 2008 06:59:43 -0700 (PDT) Received: (qmail 442 invoked by uid 0); Thu, 28 Aug 2008 13:52:39 +0000 Received: from 192.100.124.218 by www170.gmx.net with HTTP; Thu, 28 Aug 2008 15:52:39 +0200 (CEST) Date: Thu, 28 Aug 2008 08:52:39 -0500 From: Hannes Tschofenig Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01 Sender: dime-bounces@ietf.org To: aaa-doctors@ietf.org Cc: dime@ietf.org Message-id: <20080828135239.62230@gmx.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="Boundary_(ID_MSb/T90ImAc1pJy3K4TJjw)" Content-class: urn:content-classes:message Thread-topic: [Dime] Review of draft-sun-dime-itu-t-rw-01 Thread-index: AckJFl3SUio9iUyTRtC58dZoelRc3g== X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Subscribe: , List-Unsubscribe: , List-Help: This is a multi-part message in MIME format. --Boundary_(ID_MSb/T90ImAc1pJy3K4TJjw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT I reviewed draft-sun-dime-itu-t-rw-01 the normative reference: [Q.3303.3] ITU-T Recommendation Q.3303.3, "Resource control protocol no. 3 (rcp3): Protocol at the Rw interface between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE): Diameter", 2008. I think it is the right decision to define two new command codes (PIR / PIA) as it is done in [Q.3303.3]. HOWEVER, more command codes must be specified as the ABNF of existing Diameter Base Protocol and Diameter Credit Control Commands has been modified. I therefore request that [Q.3303.3] be changed in the following way since they would cause interoperability problems with existing Diameter Base Protocol and Diameter Credit Control implementations. * CCR Command The ABNF of the original CCR command is modified by removing the required Service-Context-ID AVP. * CCA Command The ABNF of the original CCA command is modified by turning the required Result-Code AVP into an optional one. * RAA Command The ABNF of the original RAA command is modified by turning the required Result-Code AVP into an optional one. * ASR Command The ABNF of the original ASR command is modified by adding the required Abort-Cause AVP. * ASA Command The ABNF of the original ASA command is modified by turning the required Result-Code AVP into an optional one. The simplest way to solve these issues is to register new command codes. Alternatively you could think about why you actually need to modify the ABNF of these commands. Another remark: A couple of tables are listed with AVP flag settings. I got the impression that these flag settings got copied from other documents. This could be a problem since the M-bit (and other flags) meaning is specific for the specific application and command. A new Diameter application/Command may require a different flag setting. I hope that the ITU-T checked this aspect since otherwise they will experience a lot of interop issues. Table 2 is missing indications about the M bit usage. Table 3 is missing indications about the P bit usage. Table 4 is missing indications about the P bit usage. A minor issue: The description about soft-state vs. hard-state was confusing since there is no Reservation-Lifetime AVP specified. Furthermore the text refers to NASREQ and the specification does not use NASREQ. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_MSb/T90ImAc1pJy3K4TJjw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT [Dime] Review of draft-sun-dime-itu-t-rw-01

I reviewed draft-sun-dime-itu-t-rw-01 the normative reference:

   [Q.3303.3]
              ITU-T Recommendation Q.3303.3, "Resource control protocol
              no. 3 (rcp3): Protocol at the Rw interface between the
              Policy Decision Physical Entity (PD-PE) and the Policy
              Enforcement Physical Entity (PE-PE): Diameter", 2008.


I think it is the right decision to define two new command codes (PIR / PIA) as it is done in [Q.3303.3].

HOWEVER, more command codes must be specified as the ABNF of existing Diameter Base Protocol and Diameter Credit Control Commands has been modified. I therefore request that [Q.3303.3] be changed in the following way since they would cause interoperability problems with existing Diameter Base Protocol and Diameter Credit Control implementations.

* CCR Command

The ABNF of the original CCR command is modified by removing the required Service-Context-ID AVP.

* CCA Command

The ABNF of the original CCA command is modified by turning the required Result-Code AVP into an optional one.

* RAA Command

The ABNF of the original RAA command is modified by turning the required Result-Code AVP into an optional one.

* ASR Command

The ABNF of the original ASR command is modified by adding the required Abort-Cause AVP.

* ASA Command

The ABNF of the original ASA command is modified by turning the required Result-Code AVP into an optional one.


The simplest way to solve these issues is to register new command codes. Alternatively you could think about why you actually need to modify the ABNF of these commands.

Another remark: A couple of tables are listed with AVP flag settings. I got the impression that these flag settings got copied from other documents. This could be a problem since the M-bit (and other flags) meaning is specific for the specific application and command. A new Diameter application/Command may require a different flag setting. I hope that the ITU-T checked this aspect since otherwise they will experience a lot of interop issues.

Table 2 is missing indications about the M bit usage.
Table 3 is missing indications about the P bit usage.
Table 4 is missing indications about the P bit usage.

A minor issue:

The description about soft-state vs. hard-state was confusing since there is no Reservation-Lifetime AVP specified.
Furthermore the text refers to NASREQ and the specification does not use NASREQ.


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

--Boundary_(ID_MSb/T90ImAc1pJy3K4TJjw)-- --Boundary_(ID_RkTOWHFs7bU47+5q9YHI/g) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_RkTOWHFs7bU47+5q9YHI/g)-- From dime-bounces@ietf.org Thu Sep 18 20:16:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541563A6A20; Thu, 18 Sep 2008 20:16:17 -0700 (PDT) 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 D509C3A6A20; Thu, 18 Sep 2008 20:16:16 -0700 (PDT) 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 WLoJHP+Gh-Yg; Thu, 18 Sep 2008 20:16:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id DF31B3A6897; Thu, 18 Sep 2008 20:16:15 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m8J3GOJK011717; Thu, 18 Sep 2008 22:16:25 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Sep 2008 22:16:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 22:16:23 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01E6526F@ILEXC2U01.ndc.lucent.com> In-Reply-To: <20080828135239.62230@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-sun-dime-itu-t-rw-01 Thread-Index: AckJFl3SUio9iUyTRtC58dZoelRc3gQoeExA References: <20080828135239.62230@gmx.net> From: "Sun, Dong \(Dong\)" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 19 Sep 2008 03:16:24.0740 (UTC) FILETIME=[18F1DE40:01C91A06] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-sun-dime-itu-t-rw-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, I understood your concern on the modification of the ABNF of existing Diameter Credit control commands e.g. CCR/CCA. However, those changes are made originally by 3GPP 29.212 Gx interface. The ITU-T Q.3303.3 just reuses what are defined by Gx interface in order to avoid the interoperability problem with other SDOs (e.g. including WiMAX and 3GPP2 since both them are based on 3GPP Gx). Regarding the indications of "M"/"P" bits, all them are copied from other specs. I will try to fix it for this spec if possible. Same to the NASREQ issue. Thanks for the review and comments, although they are more related to the ITU-T spec instead of this IETF I-D. Rgs, Dong -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, August 28, 2008 9:53 AM To: aaa-doctors@ietf.org Cc: dime@ietf.org Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01 I reviewed draft-sun-dime-itu-t-rw-01 the normative reference: [Q.3303.3] ITU-T Recommendation Q.3303.3, "Resource control protocol no. 3 (rcp3): Protocol at the Rw interface between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE): Diameter", 2008. I think it is the right decision to define two new command codes (PIR / PIA) as it is done in [Q.3303.3]. HOWEVER, more command codes must be specified as the ABNF of existing Diameter Base Protocol and Diameter Credit Control Commands has been modified. I therefore request that [Q.3303.3] be changed in the following way since they would cause interoperability problems with existing Diameter Base Protocol and Diameter Credit Control implementations. * CCR Command The ABNF of the original CCR command is modified by removing the required Service-Context-ID AVP. * CCA Command The ABNF of the original CCA command is modified by turning the required Result-Code AVP into an optional one. * RAA Command The ABNF of the original RAA command is modified by turning the required Result-Code AVP into an optional one. * ASR Command The ABNF of the original ASR command is modified by adding the required Abort-Cause AVP. * ASA Command The ABNF of the original ASA command is modified by turning the required Result-Code AVP into an optional one. The simplest way to solve these issues is to register new command codes. Alternatively you could think about why you actually need to modify the ABNF of these commands. Another remark: A couple of tables are listed with AVP flag settings. I got the impression that these flag settings got copied from other documents. This could be a problem since the M-bit (and other flags) meaning is specific for the specific application and command. A new Diameter application/Command may require a different flag setting. I hope that the ITU-T checked this aspect since otherwise they will experience a lot of interop issues. Table 2 is missing indications about the M bit usage. Table 3 is missing indications about the P bit usage. Table 4 is missing indications about the P bit usage. A minor issue: The description about soft-state vs. hard-state was confusing since there is no Reservation-Lifetime AVP specified. Furthermore the text refers to NASREQ and the specification does not use NASREQ. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Sep 18 22:03:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF903A67F4; Thu, 18 Sep 2008 22:03:14 -0700 (PDT) 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 99E1C3A67B6 for ; Thu, 18 Sep 2008 22:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.042 X-Spam-Level: ** X-Spam-Status: No, score=2.042 tagged_above=-999 required=5 tests=[AWL=-2.398, BAYES_40=-0.185, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, SARE_HELO_EQ_DSL_3=1.022] 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 2ElBrJvcBuXy for ; Thu, 18 Sep 2008 22:03:11 -0700 (PDT) Received: from smh01.opentransfer.com (smh01.opentransfer.com [71.18.216.112]) by core3.amsl.com (Postfix) with ESMTP id A99F23A67F4 for ; Thu, 18 Sep 2008 22:03:11 -0700 (PDT) Received: by smh01.opentransfer.com (Postfix, from userid 8) id A19FD22A52A1; Fri, 19 Sep 2008 01:00:42 -0400 (EDT) Received: from webmail5.opentransfer.com (unknown [69.49.230.6]) by smh01.opentransfer.com (Postfix) with ESMTP id 7BFF322A529B; Fri, 19 Sep 2008 01:00:42 -0400 (EDT) Received: from webmail5.opentransfer.com (webmail5.opentransfer.com [127.0.0.1]) by webmail5.opentransfer.com (8.13.8/8.13.8) with ESMTP id m8J533Kj000410; Fri, 19 Sep 2008 00:03:03 -0500 Received: (from nobody@localhost) by webmail5.opentransfer.com (8.13.8/8.13.8/Submit) id m8J52xsJ000408; Fri, 19 Sep 2008 00:02:59 -0500 X-Authentication-Warning: webmail5.opentransfer.com: nobody set sender to nilanjans@condornetworks.com using -f Received: from dsl-KK-static-132.206.95.61.airtelbroadband.in (dsl-KK-static-132.206.95.61.airtelbroadband.in [61.95.206.132]) by webmail.opentransfer.com (Horde MIME library) with HTTP; for ; Fri, 19 Sep 2008 00:02:59 -0500 Message-ID: <20080919000259.tjoh5gbpc4o04ogg@webmail.opentransfer.com> Date: Fri, 19 Sep 2008 00:02:59 -0500 From: nilanjans@condornetworks.com To: dime@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Originating-IP: 61.95.206.132 Subject: [Dime] Query regarding handling diameter corrupted packet X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Dear All: We need some clarification of handling diameter corrupted packets. As stated in RFC 3588, If Diameter receives data up from TCP that cannot be parsed or identified as a Diameter error made by the peer, the stream is compromised and cannot be recovered. The transport connection MUST be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT message (graceful closure is compromised). o) In case of TCP, in this case, is it fine to just close the Connection with the peer (by socket close), and re-open another new connection (Diameter + transport) with same peer? o) As we have experience, in case of TCP, we can encounter a corrupted buffer if there is a mismatch between our tcp stream slicing pointer, with diameter message size encoded, which can happen in many ways, one of this is wrongly encoded from peer, or missing some padding in time of encoding. But main issue is that, once we miss even four byte from beginning for one wrong encoded packet, we can not recover for all rest of the packets from the tcp stream (assuming fully loaded traffic), even-if we ignore couple of byte, since there is no message boundary defined in Diameter message. So, can we have message boundary defined in Diameter messages in future extension, to recover from this situation mainly in case of TCP. o) In case of TCP, since we depend on message size encoded inside buffer to slice a diameter packet, so we can not detect DIAMETER_INVALID_MESSAGE_LENGTH for a wrong corrupted message (until it is some very big value), so we have to depend on message flags checking, Command code, AVP Code etc. but unfortunately all may be within correct range. But disaster may happen, when we encounter one AVP (mainly string) with very big length, which may corrupt the full system. In any case, do we need to inform with some error message to the peer before closing the TCP connection, and re-open again? o) Do we need to follow same reset procedure for SCTP case? Since in SCTP even-if one message is corrupted, we can always recover if the rest of the messages are ok. Kind Regards, Nilanjan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Sep 21 09:31:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9F03A6BCD; Sun, 21 Sep 2008 09:31:19 -0700 (PDT) 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 D261E3A69E1 for ; Sun, 21 Sep 2008 09:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.695 X-Spam-Level: X-Spam-Status: No, score=0.695 tagged_above=-999 required=5 tests=[AWL=-4.340, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 e7jDR3pdl0zh for ; Sun, 21 Sep 2008 09:31:16 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 69D1628C140 for ; Sun, 21 Sep 2008 09:31:16 -0700 (PDT) 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 m8LGVAPo006607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 18:31:10 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8LGV8ZP027645; Sun, 21 Sep 2008 18:31:08 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Sep 2008 18:31:08 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Sep 2008 18:31:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 21 Sep 2008 19:31:06 +0300 Message-ID: In-Reply-To: <000c01c91afc$eecbbc60$9001a8c0@xxxx87e842e29b> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?ILTwuLQ6IFtEaW1lXSBEZXNpZ24gVGVhbSBvbiBEaWFtZXRlciBSb3V0aW5n?= Thread-Index: AckOWTrbDliLjk97Ss6g9vo24qVgmAMk2CjQAD8PaIA= References: <000c01c91afc$eecbbc60$9001a8c0@xxxx87e842e29b> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Fortune HUANG" , X-OriginalArrivalTime: 21 Sep 2008 16:31:07.0627 (UTC) FILETIME=[72FC83B0:01C91C07] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080921183110-0D8F5BB0-DAF16A41/0-0/0-15 X-purgate-size: 4988/0 Cc: diameter-routing@googlegroups.com Subject: Re: [Dime] =?gb2312?b?tPC4tDogIERlc2lnbiBUZWFtIG9uIERpYW1ldGVyIFJv?= =?gb2312?b?dXRpbmc=?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SGkgRm9ydHVuZSwgCgo+SGkgYWxsLAo+Cj5JIHZpc2l0ZWQgdGhlIGRpYW1ldGVyLXJvdXRpbmcg Z3JvdXAgYW5kIG5vdGljZWQgdGhhdCB0aGVyZSAKPndhcyBhIGNvbmZlcmVuY2UgY2FsbCBvbiBT ZXAgMTkuCgpZZXMsIEkgc2NoZWR1bGQgYSBjYWxsLiAgVW5mb3J0dW5hdGVseSwgSSB3YXMgdGhl IG9ubHkgcGVyc29uIG9uIHRoZSBjYWxsLiBJIGhhdmUgbm8gY2x1ZSB3aHkgb3RoZXIgZm9sa3Mg ZGlkIG5vdCBqb2luIHRoZSBjYWxsLiAKCkFzIHlvdSBjYW4gaW1hZ2luZSBJIHdhcyBub3QgaGFw cHkuIAoKSSBoYXZlIHNjaGVkdWxlZCBhbm90aGVyIGNvbmYuIGNhbGwgZm9yIG5leHQgd2Vlay4g CgoKIEFsdGhvdWdoIEkgYW0gdmVyeSBpbnRlcmVzdGVkIAo+aW4gdGhpcyB0b3BpYywgdW5mb3J0 dW5hdGVseSBJIGFtIG5vdCBvbmUgb2YgdGhlIGRlc2lnbiB0ZWFtIAo+bWVtYmVycyBhbmQgaGF2 ZW4ndCBiZWVuIGludml0ZWQgdG8gdGhlIGdyb3VwLgo+VGhlcmVmb3JlLCBjb3VsZCBIYW5uZXMg b3Igc29tZW9uZSBlbHNlIGJlIHNvIGtpbmQgdG8gc2VuZCBvdXQgCj5zb21ldGhpbmcgbGlrZSB0 aGUgbWludXRlcyBmb3IgdXMgdG8ga25vdyB0aGUgcHJvZ3Jlc3MsIHBsZWFzZT8KCkluIHByZXZp b3VzIGRlc2lnbiB0ZWFtcyBJIGhhdmUgZGlzdHJpYnV0ZWQgbWVldGluZyBtaW51dGVzLiBJbiB0 aGlzIHNwZWNpZmljIGNhc2UgSSBvYnZpb3VzbHkgY2Fubm90IGRpc3RyaWJ1dGUgYW55IG1pbnV0 ZXMgc2luY2UgdGhlIG1lZXRpbmcgZXNzZW50aWFsbHkgZGlkIG5vdCB0b29rIHBsYWNlLiAKCgo+ Cj5CVFcsIGhlcmUgaXMgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgZGlhbWV0ZXIgcm91dGluZyBw cm9ibGVtcyAKPm9yIHNjZW5hcmlvcy4KPlBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3Jvbmcu Cj4xKSBFeHBsaWNpdCByb3V0aW5nLiBJZiB0aGVyZSBhcmUgYWx0ZXJuYXRpdmUgRGlhbWV0ZXIg cHJveGllcyAKPndoaWNoIHBlcmZvcm0gZm9yIGV4YW1wbGUgY2hhcmdpbmcgYmFzZWQgb24gbWVz c2FnZXMgKGUuZy4gCj5BQVIvQUFBIGZvciBjaGFyZ2luZyBzdGFydCwgYW5kIFNUUiBmb3IgY2hh cmdpbmcgdGVybWluYXRpb24pLCAKPm9uY2UgYSBwcm94eSBpcyBjaG9zZW4gZm9yIHRoZSBmaXJz dCByZXF1ZXN0IG9yIHJlc3BvbnNlIAo+bWVzc2FnZSAoZS5nLiBBQVIgb3IgQUFBKSwgdGhlIGZv bGxvd2luZyBtZXNzYWdlcyAoZS5nLiBTVFIpIAo+c2hvdWxkIGFsd2F5cyBnbyB0aHJvdWdoIHRo ZSBwcm94eTsgb3RoZXJ3aXNlLCB0aGUgY2hhcmdpbmcgbmV2ZXIgZW5kcy4KPkV4cGxpY2l0IHJv dXRpbmcgYSBtZWNoYW5pc20gdG8gbWFrZSBzdXJlIHRoZSBmb2xsb3dpbmcgCj5tZXNzYWdlcyBn byB0aHJvdWdoIHRoZSBwcm94eSB3aGljaCBoYXMgYmVlbiBjaG9zZW4gZm9yIHRoZSBzZXNzaW9u LgoKVGhlcmUgYXJlIHR3byBpc3N1ZXMgcmVsYXRlZCB0byB0aGlzOiAKCkEpIEFyZSB0aGVzZSB2 YWxpZCBzY2VuYXJpbyB0aGF0IHByb3hpZXMgbmVlZCB0byBiZSBpbiB0aGUgcGF0aCBmb3IgZXZl cnkgbWVzc2FnZXMgb2YgY2VydGFpbiBzZXNzaW9ucz8gCgpCKSBBdCB3aGF0IGxldmVsIGRvZXMg cm91dGluZyB3b3JrPyBJcyBpdCBvbiB0aGUgbGV2ZWwgb2YgYSBkb21haW4gb3IgYmFzZWQgb24g aW5kaXZpZHVhbCBob3N0cz8gCgpJbiBwYXN0IGRpc2N1c3Npb25zIGZvbGtzIGhhZCBkaWZmZXJl bnQgdmlld3MgcmVnYXJkaW5nIGJvdGggKEEpIGFuZCAoQikgd2l0aCBzZXZlcmFsIHN0cm9uZyBv cGluaW9ucyByYWlzZWQgYWdhaW5zdCBleHBsaWNpdCByb3V0aW5nIGJhc2VkIG9uIGluZGl2aWR1 YWwgaG9zdHMgcmF0aGVyIHRoYW4gZG9tYWlucy4gCiAKCj4yKSBSZWRpcmVjdCByZWFsbSBpbmRp Y2F0aW9uLiBTdXBwb3NlIG9wZXJhdGVyX0Egd2l0aCBSZWFsbV9BIAo+Y3VycmVudGx5IHByb3Zp ZGVzIGEgY2VydGFpbiBzZXJ2aWNlIHRvIGl0cyBEaWFtZXRlciBjbGllbnRzLiAKPkhvd2V2ZXIs IGZvciBhIGNlcnRhaW4gcmVhc29uLCBvcGVyYXRlcl9BIGRlY2lkZXMgbm90IHRvIAo+cHJvdmlk ZSB0aGUgc2VydmljZSBhbnkgbG9uZ2VyIGFuZCBhc2tzIG9wZXJhdG9yX0Igd2l0aCAKPlJlYWxt X0IgdG8gcHJvdmlkZSB0aGUgc2FtZSBzZXJ2aWNlIHRvIGl0cyBjbGllbnRzLiBCZWZvcmUgYWxs IAo+aXRzIGNsaWVudHMgY2hhbmdlIHRoZWlyIGNvbmZpZ3VyYXRpb24gdG8gc2VuZCB0aGUgc2Vy dmljZSAKPnJlcXVlc3RzIGRpcmVjdGx5IHRvIFJlYWxtX0IsIHRoZSBEaWFtZXRlciByZWRpcmVj dCBhZ2VudCBpbiAKPlJlYWxtX0EgbWF5IGFsc28gbmVlZCB0byByZWRpcmVjdCB0aGUgaW5jb21p bmcgcmVxdWVzdHMgdG8gCj5SZWFsbV9CIGF0IGxlYXN0IGZvciBhIHBlcmlvZCBvZiB0aW1lLgo+ UmVkaXJlY3QgcmVhbG0gaW5kaWNhdGlvbiBpcyBhIG1lY2hhbmlzbSB0byBtYWtlIHRoZSByZWxh eSAKPmZ1bmN0aW9uIG1vcmUgZmxleGlibGUgYW5kIG1ha2UgdGhlIHJlZGlyZWN0IHRvIGFub3Ro ZXIgcmVhbG0gaGFwcGVuLgoKVGhpcyBpcyBhIG5pY2Ugc2NlbmFyaW8uIElzIGl0IGEgY2hhbGxl bmdlIG9wZXJhdG9ycyBmYWNlIHdoZW4gZGVwbG95aW5nIERpYW1ldGVyIG9yIGlzIGl0IHJhdGhl ciBhIHRoZW9yZXRpY2FsbHkgbmljZSB0aGluZyB0byBoYXZlPyAKTXkgaW1wcmVzc2lvbiBzbyBm YXIgd2FzIHRoYXQgdGhlIHJlZGlyZWN0IG1lY2hhbmlzbSBpc24ndCByZWFsbHkgd2lkZWx5IHVz ZWQgYXQgYWxsLiBJbiB5b3VyIGV4YW1wbGUgYWJvdmUsIEkgY291bGQgaW1hZ2luZSB0aGF0IG9w ZXJhdG9yIEEgbWF5IHdhbnQgdG8gc3RpbGwgc2VlIGFsbCBtZXNzYWdlcyB0byBtYWtlIHN1cmUg dGhhdCBpdCBrbm93cyB3aGF0IG9wZXJhdG9yIEIgaXMgYWN0dWFsbHkgb2ZmZXJpbmcgdG8gY2xp ZW50cy4gCgpUaGFua3MgZm9yIHNoYXJpbmcgeW91ciB0aG91Z2h0cyB3aXRoIHVzLiAKCkNpYW8K SGFubmVzCgo+QmVzdCBSZWdhcmRzLAo+Rm9ydHVuZQo+Cj4KPi0tLS0t08q8/tStvP4tLS0tLQo+ t6K8/sjLOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v cmddILT6se0KPlRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pCj63osvNyrG85Dog MjAwOMTqOdTCNMjVIDE0OjQxCj7K1bz+yMs6IGRpbWVAaWV0Zi5vcmcKPrOty806IGRpYW1ldGVy LXJvdXRpbmdAZ29vZ2xlZ3JvdXBzLmNvbQo+1vfM4jogW0RpbWVdIERlc2lnbiBUZWFtIG9uIERp YW1ldGVyIFJvdXRpbmcKPgo+VGhlIERJTUUgY2hhaXJzIGluIGRpc2N1c3Npb24gd2l0aCBEYW4g ZGVjaWRlZCB0byBjcmVhdGUgYSAKPmRlc2lnbiB0ZWFtIHdpdGggdGhlIGludGVudGlvbiB0byBp bnZlc3RpZ2F0ZSBleHRlbnNpb25zIHRvIAo+dGhlIFJGQyAzNTg4YmlzIERpYW1ldGVyIHJvdXRp bmcuIE1vcmUgc3BlY2lmaWNhbGx5LCB3ZSBoYWQgCj5kaXNjdXNzaW9ucyBhYm91dCB0aGlzIHN1 YmplY3QgdHJpZ2dlcmVkIGJ5IHRoZSBwdWJsaWNhdGlvbiBvZiAKPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC10c291LWRpbWUtYmFzZS1yb3V0aW5nLWV4dC0wNC50eAo+dCB0aGF0IG5l dmVyIGdvdCByZXNvbHZlZCBhbmQgdGhlIGltcHJlc3Npb24gb2YgZm9sa3MgYXQgdGhlIAo+SUVU RiM3MiBtZWV0aW5nIHdhcyB0aGF0IHdlIGhhdmUgdG8gaW52ZXN0aWdhdGUgdGhlIHVzYWdlIAo+ c2NlbmFyaW9zIGFuZCB0byBkZXZlbG9wIGEgcHJvYmxlbSBzdGF0ZW1lbnQgYmVmb3JlIHdlIGZv Y3VzIAo+b24gdGhlIHNvbHV0aW9uIGNvbXBvbmVudHMuIAo+Cj5UaGUgZmlyc3QgcHJvZHVjdCBv ZiB0aGUgZ3JvdXAgd2lsbCBiZSBhIHByb2JsZW0gc3RhdGVtZW50IGFuZCAKPnVzYWdlIHNjZW5h cmlvcyBkZXNjcmlwdGlvbiB0aGF0IHdpbGwgYmUgcHJlc2VudGVkIHRvIHRoZSBESU1FIGdyb3Vw LiAKPk90aGVyIG5lY2Vzc2FyeSBhY3Rpdml0eSB3aWxsIGJlIGRlY2lkZWQgYmFzZWQgb24gdGhl IG91dGNvbWUgCj5vZiB0aGUgYWJvdmUtbWVudGlvbmVkIGRlbGl2ZXJhYmxlLiAKPgo+VGhlIGRl c2lnbiB0ZWFtIG1lbWJlcnMgYXJlOgo+LSBUZW5hIFRzb3UKPi0gVmljdG9yIEZhamFyZG8KPi0g Sm91bmkgS29yaG9uZW4KPi0gVG9sZ2EgQXN2ZXJlbgo+LSBNYXJrIEpvbmVzCj4tIEF2aSBMaW9y Cj4tIEdsZW4gWm9ybgo+LSBTdGV2ZSBOb3JyZXlzCj4tIExpb25lbCBNb3JhbmQKPgo+VGhlIGRl c2lnbiB0ZWFtIGlzIGxlYWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzOiBEYXZlIAo+RnJh c2NvbmUgYW5kIEhhbm5lcyBUc2Nob2ZlbmlnCj4KPk1haWxpbmcgTGlzdCBhcmNoaXZlOiAKPmh0 dHA6Ly9ncm91cHMuZ29vZ2xlLmNvbS9ncm91cC9kaWFtZXRlci1yb3V0aW5nCj4KPkNpYW8KPkhh bm5lcyAmIERhdmUKPgo+UFM6IFRoZSBydWxlcyBmb3IgZGVzaWduIHRlYW1zIGFyZSBkZXNjcmli ZWQgaW4gCj5odHRwOi8vd3d3LmlldGYub3JnL0lFU0cvU1RBVEVNRU5UUy9EZXNpZ24tVGVhbXMu dHh0Cj4KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5E aU1FIG1haWxpbmcgbGlzdAo+RGlNRUBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaW1lCj4KPgo+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCkRpTUUgbWFpbGluZyBsaXN0CkRpTUVAaWV0Zi5vcmcKaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCg== From dime-bounces@ietf.org Tue Sep 23 09:30:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01103A6CE4; Tue, 23 Sep 2008 09:30:03 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7FFFD3A6A8F; Tue, 23 Sep 2008 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080923163001.7FFFD3A6A8F@core3.amsl.com> Date: Tue, 23 Sep 2008 09:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-12.txt Pages : 37 Date : 2008-09-23 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-09-23091850.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Sep 24 07:24:22 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44E23A6A72; Wed, 24 Sep 2008 07:24:22 -0700 (PDT) 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 E216C3A6A72 for ; Wed, 24 Sep 2008 07:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, URI_HEX=0.368] 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 wWj0G39sALBq for ; Wed, 24 Sep 2008 07:24:18 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 162693A699E for ; Wed, 24 Sep 2008 07:24:17 -0700 (PDT) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m8OEOGNo048688; Wed, 24 Sep 2008 10:24:16 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48DA4D83.2050604@tari.toshiba.com> Date: Wed, 24 Sep 2008 10:24:03 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Hannes Tschofenig References: <48C92258.6050008@gmx.net> In-Reply-To: <48C92258.6050008@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, I apologize for the really late response. I'm running out of cycles lately but I'll try to work on this review as soon as I can. regards, victor > --- I noticed that my mail did not make it to the list because it is too > large. > > Hi Victor, > > as I am the PROTO shepherd for this document I had todo a review of the > document before it leaves the working group. I did it based on the -11 > version but I noticed that you just published -12. Still, I wanted to > submit my first round of comments. Many aspects are very easy to address > since they are just editorial. > > I split my comments into three parts; this is the first part. > > Section 1.1: > > All data delivered by the protocol is in the form of an AVP. Some of > these AVP values are used by the Diameter protocol itself, while > > Diameter base protocol > > others deliver data associated with particular applications that > employ Diameter. AVPs may be added arbitrarily to Diameter messages, > so long as the requirements of a message's ABNF are met and the ABNF > allows for it. AVPs are used by the base Diameter protocol to > > Diameter base protocol > > support the following required features: > > > o Exchanging resource usage information, which MAY be used for > accounting purposes, capacity planning, etc. > > s/MAY/may > > > > A Diameter node MAY act as an agent for > certain requests while acting as a server for others. > > > s/MAY/may > > > Section 1.1.1. > > I would shorten this section and just say the following: > > > > 1.1.1. Description of the Document Set > > > The Diameter specification consists of an updated version > of the base protocol specification (this document), Transport Profile > [RFC3539] and various document defining new Diameter applications or > > extending existing applications. Note that > this document obsoletes [RFC3588]. A summary of the base protocol > updates included in this document can be found in Section 1.1.3. > > The Transport Profile document [RFC3539] discusses transport layer > issues that arise with AAA protocols and recommendations on how to > overcome these issues. This document also defines the Diameter > failover algorithm and state machine. > > Since standardization efforts on Diameters are being entertained in > > various standardization organizations the list of Diameter applications is > > increasing steadily and providing a list of all Diameter applications is > not > > provided in this document. Example applications can be found with Mobile > IPv4 > > [RFC4004], NASREQ [RFC4005], Credit Control [RFC4006], EAP [RFC4072] and > SIP > > [RFC4740]. > > > > 1.1.3. Changes from RFC3588 > > > This document deprecates [RFC3588] but is fully backward compatible > with that document. The changes introduced in this document focuses > on fixing issues that has surfaced during implementation of > > s/has/have > > [RFC3588]. An overview of some the major changes are shown below. > > > o Simplified Security Requirements. The use of a secured transport > for exchanging diameter messages remains mandatory. However, TLS > has become the primary method of securing diameter and IPSec is a > secondary alternative. See Section 13 for details. Along with > this, support for the End-to-End security framework (E2ESequence > AVP and 'P'-bit in the AVP header) has also been deprecated. > > s/IPSec/IPsec > s/support for/the support for > > o Diameter Extensibility Changes. This includes fixes to the > diameter extensibility specification (Section 1.2 and others) to > better aid diameter application designers. It also includes > allocation of vendor specific command code space. The new > specification relaxes the allocation of command codes for vendor > specific uses. See Section 11.2.1 for details. > > s/diameter extensibility specification/Diameter extensibility description > > s/diameter application designers/Diameter application designers > > > o Application Id Usage. Clarify the proper use of Application Id > information which can be found in multiple places within a > diameter message. This includes co-relating Application Ids found > in the message headers and AVPs. These changes also clearly > specifies the proper Application Id value to use for specific base > protocol messages (ASR/ASA, STR/STA) as well as clarifying the > content and use of Vendor-Specific-Application-Id. > > > s/Clarify the proper use of Application Id > information which can be found in multiple places within a > diameter message. > /Clarify the proper use of Application Id > information, which can be found in multiple places within a > Diameter message. > > > > o Simplification of Diameter Peer Discovery. The diameter discovery > process now supports only well known discovery schemes. The rest > has been deprecated. (See Section 5.2 for details). > > s/diameter/Diameter > > > > > > 1.3. Terminology > > > Broker > > A broker is a business term commonly used in AAA infrastructures. > A broker is either a relay, proxy or redirect agent, and MAY be > operated by roaming consortiums. Depending on the business model, > a broker may either choose to deploy relay agents or proxy agents. > > > s/MAY/may > > > Diameter Server > > A Diameter Server is one that handles authentication, > authorization and accounting requests for a particular realm. By > its very nature, a Diameter Server MUST support Diameter server > applications in addition to the base protocol. > > s/MUST/must > > > > Diameter Client > > A Diameter Client is a device at the edge of the network that > performs access control. An example of a Diameter client is a > Network Access Server (NAS) or a Foreign Agent (FA). By its very > nature, a Diameter Client MUST support Diameter client > applications in addition to the base protocol. > > s/MUST/must > > > > > > Local Realm > > A local realm is the administrative domain providing services to a > user. An administrative domain MAY act as a local realm for > certain users, while being a home realm for others. > > s/MAY/may > > > Real-time Accounting > > Real-time accounting involves the processing of information on > resource usage within a defined time window. Time constraints are > typically imposed in order to limit financial risk. > > > I would include a pointer to the DCCA spec here as it provides the > real-time > > accounting functionality. > > > Session > > A session is a related progression of events devoted to a > particular activity. Each application SHOULD provide guidelines > as to when a session begins and ends. All Diameter packets with > the same Session-Identifier are considered to be part of the same > session. > > > s/Each application SHOULD provide guidelines > as to when a session begins and ends. > /Diameter application documents provide guidelines as to when ... > > > > User > > The entity requesting or using some resource, in support of which > a Diameter client has generated a request. > > > > It might be worth noting that it does not necessary have to be a human. > > Instead, the NAI refers to some entity and this document refers to it as > > user. > > > > 2. Protocol Overview > > This section starts a bit strange. Here is my proposal on how to > re-write it: > > > > The Diameter base protocol concerns itself with capabilities > negotiation, how messages are sent and how peers may eventually be > abandoned. The base protocol also defines certain rules that apply > to all exchanges of messages between Diameter nodes. > > Communication between Diameter peers begins with one peer sending a > message to another Diameter peer. The set of AVPs included in the > message is determined by a particular Diameter application. One AVP > that is included to reference a user's session is the Session-Id. > > The initial request for authentication and/or authorization of a user > would include the Session-Id. The Session-Id is then used in all > subsequent messages to identify the user's session (see Section 8 for > more information). The communicating party may accept the request, > or reject it by returning an answer message with the Result-Code AVP > set to indicate an error occurred. The specific behavior of the > Diameter server or client receiving a request depends on the Diameter > application employed. > > Session state (associated with a Session-Id) MUST be freed upon > receipt of the Session-Termination-Request, Session-Termination- > Answer, expiration of authorized service time in the Session-Timeout > AVP, and according to rules established in a particular Diameter > application. > > > The base Diameter protocol, which includes > accounting functionality, may be used by itself to offer accounting > functionality to applications, but for use in authentication > and > > authorization always requires a particular application. > > Diameter Clients MUST support the base protocol. In addition, they MUST > > fully support each Diameter > application that is needed to implement the client's service, e.g., > NASREQ. A Diameter Client that does not support > both Application X and Application Y, MUST be referred to as "Diameter X > Client" where X is the application which it supports, and not a > "Diameter Client". > > Diameter Servers MUST support the base protocol. In addition, they MUST > > fully support each Diameter > application that is needed to implement the intended service, e.g., > NASREQ. A Diameter Server that does not support > both Application X and Application Y, MUST be referred to as "Diameter X > Server" where X is the application which it supports, and not a > "Diameter Server". > > Diameter Relays and redirect agents are, by definition, protocol > transparent, and MUST support the Diameter base protocol. > > Diameter proxies MUST support the base protocol. In addition, they MUST > > fully support each Diameter > application that is needed to implement proxied services, e.g., > NASREQ. A Diameter proxy which does not support > also both Application X and Application Y, MUST be referred to as > > "Diameter X > Proxy" where X is the application which it supports, and not a > "Diameter Proxy". > > > 2.1. Transport > > s/ Transport profile is defined in [RFC3539]./The Diameter Transport > > profile is defined in [RFC3539]./ > > > s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] and > > SCTP [RFC2960] transport protocols./The base Diameter protocol is run on > port > > 3868 of both TCP [RFC793] and SCTP [RFC2960]. > > Delete "Future versions of this specification MAY > mandate that clients support SCTP." > > I also do not understand why we require that agents and servers must > support > > SCTP. That does not sound realistic if I consider our interop testing > > experience. > > > 2.2. Securing Diameter Messages > > s/IPSec/IPsec > > > > 2.3. Diameter Application Compliance > > > > For a given application, advertising support of > an application implies that the sender supports all command codes, > and the AVPs specified in the associated ABNFs, described in the > specification. > > I don't think that this is true. Whether a specific AVP has to be > implemented > > by either the sender is essentially up to the definition of the application > > specification. > > As such, I would rather say: > > For a given application, advertising support of > an application implies that the sender supports the functionality > > specified in the respective Diameter application specification. > > > > > 2.4. Application Identifiers > > > > > The following Application Id values are defined: > > Diameter Common Messages 0 > NASREQ 1 [RFC4005] > Mobile-IP 2 [RFC4004] > Diameter Base Accounting 3 > Relay 0xffffffff > > > I don't understand why the Diameter base protocol spec needs to list the > > application Ids of NASREQ and Mobile-IP. I suggest to delete them in the > > above table to something like this: > > The following Application Id values are defined in this document: > > Diameter Common Messages 0 > Diameter Base Accounting 3 > Relay 0xffffffff > > > > 2.5. Connections vs. Sessions > > > s/ A connection is a transport level connection between two peers, used > to send and receive Diameter messages. > / > A connection refers to a transport level connection between two peers > that > > is used to send and receive Diameter messages. > > s/ > A session is a logical > concept at the application layer, and is shared between an access > device and a server, and is identified via the Session-Id AVP. > / > A session is a logical > concept at the application layer, it spawns from the Diameter client to > > the Diameter server and is identified via the Session-Id AVP. > > > s/ > In the example provided in Figure 1, peer connection A is established > between the Client and its local Relay. > / In the example provided in Figure 1, peer connection A is established > between the Client and the Relay. > > > > 2.7. Routing Table > > s/ > 1. LOCAL - Diameter messages that resolve to a route entry with > the Local Action set to Local can be satisfied locally, and do > not need to be routed to another server. > / > 1. LOCAL - Diameter messages that can be satisfied locally, and do > not need to be routed to another Diameter entity. > > > > s/ > 2. RELAY - All Diameter messages that fall within this category > MUST be routed to a next hop server, without modifying any > non-routing AVPs. See Section 6.1.9 for relaying guidelines > / > > > 2. RELAY - All Diameter messages that fall within this category > MUST be routed to a next hop Diameter entity that is indicated by > > the identifier described below, without modifying any > non-routing AVPs. See Section 6.1.9 for relaying guidelines > > > s/ > > 3. PROXY - All Diameter messages that fall within this category > MUST be routed to a next hop server. The local server MAY > apply its local policies to the message by including new AVPs > to the message prior to routing. See Section 6.1.9 for > proxying guidelines. > > / > > 3. PROXY - All Diameter messages that fall within this category > MUST be routed to a next Diameter entity that is indicated by the > > identifier described below. The local server MAY > apply its local policies to the message by including new AVPs > to the message prior to routing. See Section 6.1.9 for > proxying guidelines. > > > Server Identifier > > One or more servers the message is to be routed to. These servers > MUST also be present in the Peer table. When the Local Action is > set to RELAY or PROXY, this field contains the identity of the > server(s) the message must be routed to. When the Local Action > field is set to REDIRECT, this field contains the identity of one > or more servers the message should be redirected to. > > Shouldn't it say ".. the message MUST be routed to." > > and why is there a should and not a MUST in the last sentence? > > > s/ > Relay agents MUST NOT reorder > AVPs, and proxies MUST NOT reorder AVPs. > / > Relay agents and proxies MUST NOT reorder > AVPs. > > > 2.8. Role of Diameter Agents > > s/ > Maintaining session state MAY be useful in certain applications, such > as: > / > Maintaining session state may be useful in certain applications, such > as: > > 2.8.1. Relay Agents > > s/ > Relays MAY be used to aggregate requests from multiple Network Access > Servers (NASes) within a common geographical area (POP). > / > Relays may, for example, be used to aggregate requests from multiple > > Network Access Servers (NASes) within a common geographical area (POP). > > > I think we can delete this sentence since it essentially reflects the > > definition of a relay: > > Relays SHOULD NOT maintain session state but MUST maintain > transaction state. > > > > 2.8.2. Proxy Agents > > s/ > Proxies MAY be used in call control centers or access ISPs that > provide outsourced connections, they can monitor the number and types > of ports in use, and make allocation and admission decisions > according to their configuration. > / > Proxies may, for example, be used in call control centers or access ISPs > > that > provide outsourced connections, they can monitor the number and types > of ports in use, and make allocation and admission decisions > according to their configuration. > > > > > Proxies that wish to limit resources MUST maintain session state. > All proxies MUST maintain transaction state. > > I don't really understand what the first sentence should tell us and the > 2nd > > one is essentially already described with the definition of the proxy. > > > 2.8.3. Redirect Agents > > > s/ > Since redirect > agents do not receive answer messages, they cannot maintain session > state. Further, since redirect agents never relay requests, they are > not required to maintain transaction state. > / > > Since redirect > agents do not receive answer messages, they cannot maintain session > and transaction state. > > > > > 3.2. Command Code ABNF specification > > s/ > Every Command Code defined MUST include a corresponding ABNF > specification, which is used to define the AVPs that MUST or MAY be > present. > / > Every Command Code defined MUST include a corresponding ABNF > specification, which is used to define the AVPs that MUST or MAY be > present when sending the message. > > > > > 3.3. Diameter Command Naming Conventions > > > > o An additional request MUST be sent to provide information the peer > requires prior to returning a successful or failed answer. > > s/MUST/has to be > > > > Additional information, encoded within AVPs, MAY also be included in > answer messages. > > s/MAY/may > > > Some AVPs MAY be listed more than once. The effect of such an AVP is > specific, and is specified in each case by the AVP description. > > > There is something wrong with this sentence. > > > 4.1. AVP Header > > > AVP Flags > > The 'P' bit indicates the need for > encryption for end-to-end security. Note that the 'P' bit has > been deprecated and MUST be to zero(0) when sending an AVP and > ingnored on receipt of an AVP. > > > Instead of the above, I think it should say: > > The 'P' bit has been reserved for future usage of end-to-end security. > At the time of writing there are no end-to-end security mechanisms > specified. > > > The 'M' Bit, known as the Mandatory bit, indicates whether support > of the AVP is required. If an AVP with the 'M' bit set is > received by a Diameter client, server or translation agent and > either the AVP or its value is unrecognized, the message MUST be > rejected. > > We changed this already. New text proposal: > > The 'M' Bit, known as the Mandatory bit, indicates whether > the receiver of the AVP MUST understand the received AVP and the > content of the AVP. When the receiving entity MUST return an > > appropriate error message if it receives an AVP that has the M-bit > set but does not understand it. > > > AVP Length > > If a message is > received with an invalid attribute length, the message SHOULD be > rejected. > > Why is this only a SHOULD level recommendation? What should the receiver do > > otherwise? > > > 4.1.1. Optional Header Elements > > > Vendor-ID > > > Any vendor > wishing to implement a vendor-specific Diameter AVP MUST use their > own Vendor-ID along with their privately managed AVP address > space, guaranteeing that they will not collide with any other > vendor's vendor-specific AVP(s), nor with future IETF > applications. > > s/Any vendor .../Any vendor or standardization organization that are also > > treated like vendors in the IANA managed"SMI Network Management Private > > Enterprise Codes" space ... > > s/nor with future IETF applications./nor with future IETF AVPs. > > 4.3. Derived AVP Data Formats > > In addition to using the Basic AVP Data Formats, applications may > define data formats derived from the Basic AVP Data Formats. An > application that defines new AVP Derived Data Formats MUST include > them in a section entitled "AVP Derived Data Formats", using the same > format as the definitions below. Each new definition MUST be either > defined or listed with a reference to the RFC that defines the > format. > > > This is sort of interesting, particularly when you look at the > IPFilterRule, > > as the boundary between Derived AVP Data Formats and AVP definitions is > sort > > of fuzzy. > > Does any other Diameter document ever tried to define new derived Data > > Formats? > > > > Time > > The Time format is derived from the OctetString AVP Base Format. > The string MUST contain four octets, in the same format as the > first four bytes are in the NTP timestamp format. The NTP > Timestamp format is defined in chapter 3 of [RFC4330]. > > s/chapter/Chapter > > This represents the number of seconds since 0h on 1 January 1900 > with respect to the Coordinated Universal Time (UTC). > > On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. > SNTP [RFC4330] describes a procedure to extend the time to 2104. > This procedure MUST be supported by all DIAMETER nodes. > > s/DIAMETER/Diameter > > > 4.4. Grouped AVP Values > > However, the encapsulated AVPs with 'M' (mandatory) bit set MUST > belong to the Diameter application the Grouped APV is used in. > > I don't quite understand that sentence. Could you explain it a bit? > > > > 5.1. Peer Connections > > Delete the following paragraph since it does not say anything > > In > order to promote interoperable implementations of Diameter peer > discovery, the following mechanisms are described. These are based > on existing IETF standards. > > > > The first option (manual configuration) > MUST be supported by all DIAMETER nodes, while the latter option > (DNS) MAY be supported. > > s/DIAMETER/Diameter > > > > 5.2. Diameter Peer Discovery > > s/ > We also establish an IANA > registry for NAPTR service name to transport protocol > mappings. > / > An IANA > registry for NAPTR service name to transport protocol > mappings is defined in Section 11.6. > > > 3. If no NAPTR records are found, the requester queries for those > address records for the destination address, > '_diameter._sctp'.realm or '_diameter._tcp'.realm. > > Why is it necessary to specify two mechanisms to query the DNS? > > I will distribute a separate mail about the domain certificate stuff. > > > > > 5.3.5. Host-IP-Address AVP > > > The Host-IP-Address AVP (AVP Code 257) is of type Address and is used > to inform a Diameter peer of the sender's IP address. All source > addresses that a Diameter node expects to use with SCTP [RFC2960] > MUST be advertised in the CER and CEA messages by including a > Host-IP- Address AVP for each address. This AVP MUST ONLY be used in > the CER and CEA messages. > > s/Host-IP- Address/Host-IP-Address > > I wonder why there is the last sentence in there? It is fine to use the AVP > > in the CER and CEA message but why is there a need to say that it must only > > be used there? That does not make a lot of sense. > > > 5.3.6. Supported-Vendor-Id AVP > > Multiple instances of this AVP containing the same value SHOULD NOT > be sent. > > Why not MUST NOT be sent? > > > > I was also wondering why only a selection of AVPs is listed in Section 5.3 > > instead of all of them? Any special reason? > > > > > 5.5.4. Failover and Failback Procedures > > Shouldn't it actually read "Fallback" instead of failback? > > > > > 6.1. Diameter Request Routing Overview > > > I would change text a bit by modifying this paragraph: > > o a request that needs to be sent to a home server serving a > specific realm, but not to a specific server (such as the first > request of a series of round-trips), MUST contain a Destination- > Realm AVP, but MUST NOT contain a Destination-Host AVP. For > Diameter clients, the value of the Destination-Realm AVP MAY be > extracted from the User-Name AVP, or other methods. > > and by deleting this paragraph: > > The Destination-Realm AVP MUST be present if the message is > proxiable. A message that MUST NOT be forwarded by Diameter agents > (proxies, redirects or relays) MUST NOT include the Destination-Realm > in its ABNF. For Diameter clients, the value of the Destination- > Realm AVP MAY be extracted from the User-Name AVP, or other > application-specific methods. > > 6.1.2. Sending a Request > > When sending a request, originated either locally, or as the result > of a forwarding or routing operation, the following procedures MUST > be followed: > > o the Hop-by-Hop Identifier should be set to a locally unique value. > > s/should/SHOULD > > o The message should be saved in the list of pending requests. > > s/should/SHOULD > > > Given that the introductory sentence says "MUST be followed" I was > wondering > > whether SHOULD is actually too weak here. > > 6.1.6. Request Routing > > Diameter request message routing is done via realms and applications. > A Diameter message that may be forwarded by Diameter agents (proxies, > redirects or relays) MUST include the target realm in the > Destination-Realm AVP. > > s/applications/application identifiers > s/redirects/redirect agents > > > Realm names and Application Ids are the minimum supported routing > criteria, additional routing information maybe needed to support > redirect semantics. > > s/routing information/information > s/maybe/may be > > > 6.1.8. Redirecting requests > > s/Redirecting requests/ Redirecting Requests > > In such a case, a routing precedence > rule MUST be used againt the redirect usage value to resolve the > contention. > > s/againt/against > > 6.1.9. Relaying and Proxying Requests > > > Proxy-Info AVP has certain > security implications and SHOULD contain an embedded HMAC with a > node-local key. > > I suspect that you mean protecting the content in similar fashion as it is > > done with a cookie. > > Maybe something like > > " > The Proxy-Info AVP has security implications as state information is > > distribute to other entities. As such, it is RECOMMMENDED to protect the > > content of the Proxy-Info AVP with cryptographic mechanisms, for example by > > using a keyed message digest. Such a mechanism, however, requires the > > management of keys, although only locally at the Diameter server. Still, a > > full description of the management of the keys used to protect the > Proxy-Info AVP is beyond the scope of this document. Below is a list of > > commonly recommended: > o The keys should be generated securely following the randomness > recommendations in [RFC4086]. > o The keys and cryptographic protection algorithms should be at > least 128 bits in strength. > o The keys should not be used for any other purpose than generating > and verifying tickets. > o The keys should be changed regularly. > o The keys should be changed if the ticket format or cryptographic > protection algorithms change. > " > > would be more appropriate. > > > > 6.1.9. Relaying and Proxying Requests > > Relay and proxy agents are not required to perform full validation of > incoming messages. > > s/validation/inspection > > > > 6.2.2. Relaying and Proxying Answers > > > If the agent receives an answer > message with a Result-Code AVP indicating success, and it wishes to > modify the AVP to indicate an error, it MUST modify the Result-Code > AVP to contain the appropriate error in the message destined towards > the access device as well as include the Error-Reporting-Host AVP and > it MUST issue an STR on behalf of the access device. > > extend the sentence by saying ".. towards the Diameter server." > > > 6.7.2. Proxy-Info AVP > > > The description for the AVP does not describe the semantic. > > > 6.7.4. Proxy-State AVP > > s/ > > The Proxy-State AVP (AVP Code 33) is of type OctetString, and > contains state local information, and MUST be treated as opaque data. > > / > > The Proxy-State AVP (AVP Code 33) is of type OctetString, and > is created by the Diameter server and passed on to the Diameter > client. It contains state information that would otherwise be stored at > the Diameter. > As such, this AVP MUST be treated as opaque data by entities other > than the Diameter server that created it. > > > 6.8. Auth-Application-Id AVP > > The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and > is used in order to advertise support of the Authentication and > Authorization portion of an application (see Section 2.4). If > present in a message other than CER and CEA, the value of the Auth- > Application-Id AVP MUST match the Application Id present in the > Diameter message header. > > If it always matches then does it make a lot of sense? > > 6.10. Inband-Security-Id AVP > > The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and > is used in order to advertise support of the Security portion of the > application. > > s/Security/security > > > 6.11. Vendor-Specific-Application-Id AVP > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Exactly one instance of either Auth- > Application-Id or Acct-Application-Id AVP MUST be present. > > > We should say where it must be present. > > The > Application Id carried by either Auth-Application-Id or Acct- > Application-Id AVP MUST comply with vendor specific Application Id > assignment described in Sec 11.3. It MUST also match the Application > Id present in the diameter header except when used in a CER or CEA > messages. > > s/diameter/Diameter > > > This AVP MUST also be present as the first AVP in all experimental > commands defined in the vendor-specific application. > > This AVP SHOULD be placed as close to the Diameter header as > possible. > > > "This" in the above two sentences refers to the > Vendor-Specific-Application-Id AVP. Right? > > If a Vendor-Specific-Application-Id is received that contains both > Auth-Application-Id and Acct-Application-Id, then the recipient > SHOULD issue an answer with Result-Code set to > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer SHOULD also include a > Failed-AVP which MUST contain the received Auth-Application-Id AVP > and Acct-Application-Id AVP. > > Why are these only SHOULD level requirements? What happens in the other > cases? > > > 6.13. Redirect-Host-Usage AVP > > > > When present, this AVP dictates how the routing entry resulting from > the Redirect-Host is to be used. The following values are supported: > > s/dictates/provides a hint about > > Dictate is really not the right term given that everything below is fluffy. > Another term that would come to my mind is "provides a suggestion about" > > > > DONT_CACHE 0 > > The host specified in the Redirect-Host AVP should not be cached. > This is the default value. > > s/should not/SHOULD NOT?? > > > ALL_SESSION 1 > > All messages within the same session, as defined by the same value > of the Session-ID AVP MAY be sent to the host specified in the > Redirect-Host AVP. > > s/MAY/SHOULD > > > ALL_REALM 2 > > All messages destined for the realm requested MAY be sent to the > host specified in the Redirect-Host AVP. > > > s/MAY/SHOULD > > > REALM_AND_APPLICATION 3 > > All messages for the application requested to the realm specified > MAY be sent to the host specified in the Redirect-Host AVP. > > s/MAY/SHOULD > > > ALL_APPLICATION 4 > > All messages for the application requested MAY be sent to the host > specified in the Redirect-Host AVP. > > s/MAY/SHOULD > > > ALL_HOST 5 > > All messages that would be sent to the host that generated the > Redirect-Host MAY be sent to the host specified in the Redirect- > Host AVP. > > s/MAY/SHOULD > > > ALL_USER 6 > > All messages for the user requested MAY be sent to the host > specified in the Redirect-Host AVP. > > s/MAY/SHOULD > > > > 6.14. Redirect-Max-Cache-Time AVP > > > > > This AVP contains the maximum number of seconds the peer and route > table entries, created as a result of the Redirect-Host, will be > cached. Note that once a host created due to a redirect indication > is no longer reachable, any associated peer and routing table entries > MUST be deleted. > > > "will be cached" does not provide a good indication how the value provided > by this AVP should actually be treated. Is this > * MUST be cached > * SHOULD cached > * MAY be cached > > I think that the semantic is a bit weak. What can the sender really expect > when it provides a value with AVP to the receiver? > > > > > 7. Error Handling > > > Application errors, on the other hand, generally > occur due to a problem with a function specified in a Diameter > application (e.g., user authentication, Missing AVP). > > s/Missing AVP/missing AVP > > o A command is received with an AVP that is omitted, yet is > mandatory according to the command's ABNF. > > s/mandatory/required > > > > > 7.1. Result-Code AVP > > > The Result-Code AVP (AVP Code 268) is of type Unsigned32 and > indicates whether a particular request was completed successfully or > whether an error occurred. All Diameter answer messages defined in > IETF applications MUST include one Result-Code AVP. > > s/IETF applications/IETF defined Diameter application specifications > > > > 7.1.2. Success > > > > DIAMETER_SUCCESS 2001 > > The Request was successfully completed. > > s/Request/request > > > > 7.1.3. Protocol Errors > > s/ > To provide backward > compatibility with existing implementations that follow [RFC3588], > some of the error values that have previously been used in this > category by [RFC3588] will not be re-used. Therefore the error > values enumerated here may be non-sequential. > / > This document omits some error codes defined in RFC 3588 [RFC3588]. > To provide backward compatibility with RFC 3588 implementations > these error code values are not re-used and hence the error codes > values enumerated below are non-sequential. > > > > DIAMETER_REDIRECT_INDICATION 3006 > > A redirect agent has determined that the request could not be > satisfied locally and the initiator of the request should direct > the request directly to the server, whose contact information has > been added to the response. When set, the Redirect-Host AVP MUST > be present. > > s/should/SHOULD > > > > > DIAMETER_NO_COMMON_APPLICATION 5010 > > This error is returned by a Diameter node that is not acting as a > relay when it receives a CER which advertises a set of > applications that it does not support. > > > Why not saying something like: > > " > This error is returned by a Diameter node that receives a CER > whereby no applications are common between the CER sending peer > and the CER receiving peer. > > > > > DIAMETER_INVALID_AVP_LENGTH 5014 > > The request contained an AVP with an invalid length. A Diameter > message indicating this error MUST include the offending AVPs > within a Failed-AVP AVP. In cases where the erroneous avp length > value exceeds the message length or is less than the minimum AVP > header length, it is sufficient to include the offending AVP > header and a zero filled payload of the minimum required length > for the payloads data type. If the AVP is a grouped AVP, the > grouped AVP header with an empty payload would be sufficient to > indicate the offending AVP. In the case where the offending AVP > header cannot be fully decoded when avp length is less than the > minimum AVP header length, it is sufficient to include an > offending AVP header that is formulated by padding the incomplete > AVP header with zero up to the minimum AVP header length. > > s/avp/AVP > > s/when avp length/when the AVP length > > > DIAMETER_COMMAND_UNSUPPORTED 5019 > > The Request contained a Command-Code that the receiver did not > recognize or support. This MUST be used when a Diameter node > receives an experimental command that it does not understand. > > What about: > " > This error code is used when a Diameter entity receives a message > with a Command Code that it does not support. > " > > > > 7.3. Error-Message AVP > > s/ > The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY > accompany a Result-Code AVP as a human readable error message. The > Error-Message AVP is not intended to be useful in real-time, and > SHOULD NOT be expected to be parsed by network entities. > / > .. to be useful in an environment where error messages are processed > automatically. > It SHOULD NOT be expected that the content of this AVP is parsed by > network entities. > > > 7.6. Experimental-Result AVP > > The Experimental-Result AVP (AVP Code 297) is of type Grouped, and > indicates whether a particular vendor-specific request was completed > successfully or whether an error occurred. Its Data field has the > following ABNF grammar: > > s/ > Its Data field has the > following ABNF grammar: > / > This AVP has the following structure: > > > > > 8. Diameter User Sessions > > > However, the base > protocol does define a set of messages that is used to terminate user > sessions. These are used to allow servers that maintain state > information to free resources. > > s/is used/are used > > > Diameter may also be used for services that cannot be easily > categorized as authentication, authorization or accounting (e.g., > certain 3GPP IMS interfaces). In such cases, the finite state > machine defined in subsequent sections may not be applicable. > Therefore, the applications itself MAY need to define its own finite > state machine. However, such application specific state machines > MUST comply with general Diameter user session requirements such co- > relating all message exchanges via Session-Id AVP. > > What specifically is meant by saying that such applications must comply > with the > general Diameter user session requirements? > > > > > > 8.2. Accounting Session State Machine > > > s/ > Implementations of Diameter MAY perform checking, ordering, > correlation, fraud detection, and other tasks based on these records. > Both base Diameter AVPs as well as application specific AVPs MAY be > inspected as a part of these tasks. > / > Implementations of Diameter may perform checking, ordering, > correlation, fraud detection, and other tasks based on these records. > AVPs may need to be inspected as a part of these tasks. > > > > 8.4.1. Session-Termination-Request > > The Session-Termination-Request (STR), indicated by the Command-Code > set to 275 and the Command Flags' 'R' bit set, is sent by the access > device to inform the Diameter Server that an authenticated and/or > authorized session is being terminated. > > > s/access device/the Diameter client or by a Diameter proxy > > > 8.5. Aborting a Session > > s/ > For example, the Diameter server that originally authorized the > session may be required to cause that session to be stopped for > credit or other reasons that were not anticipated when the session > was first authorized. On the other hand, an operator may maintain a > management server for the purpose of issuing ASRs to administratively > remove users from the network. > / > For example, the Diameter server that originally authorized the > session may be required to cause that session to be stopped for > lack of credit or other reasons that were not anticipated when the > session > was first authorized. > > > I would delete the following paragraph: > > " > Note that if the access device does stop the session upon receipt of > an ASR, it issues an STR to the authorizing server (which may or may > not be the agent issuing the ASR) just as it would if the session > were terminated for any other reason. > > " > > 8.5.1. Abort-Session-Request > > The Abort-Session-Request (ASR), indicated by the Command-Code set to > 274 and the message flags' 'R' bit set, may be sent by any server to > the access device that is providing session service, to request that > the session identified by the Session-Id be stopped. > > > The text talks about "any server". I guess it is more saying "Diameter > server or > Diameter proxy" > > > 8.6. Inferring Session Termination from Origin-State-Id > > this section is a bit confusing as it talks about CER/CEA and the > hop-by-hop processing > but then refers to end-to-end processing as well. > > > > 8.7. Auth-Request-Type AVP > > The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is > included in application-specific auth requests to inform the peers > whether a user is to be authenticated only, authorized only or both. > Note any value other than both MAY cause RADIUS interoperability > issues. > > What are the RADIUS interoperability issues? > > > 8.8. Session-Id AVP > > > > accesspoint7.acme.com;1876543210;523 > > Example, in which there is an optional value: > > accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88 > > > I believe examples now have to use something like "example.com" rather > than the above. > > > > The Session-Id is created by the Diameter application initiating the > session, which in most cases is done by the client. Note that a > Session-Id MAY be used for both the authorization and accounting > commands of a given application. > > > Shouldn't it say ... be used for the authentication, authorization and > accounting > commands of a given app. > > > > 8.9. Authorization-Lifetime AVP > > > This is typically used in cases where multiple > authentication methods are used, and a successful auth response with > this AVP set to zero is used to signal that the next authentication > method is to be immediately initiated. > > Where is this used? > > > > This AVP MAY be provided by the client as a hint of the maximum > lifetime that it is willing to accept. However, the server MAY > return a value that is equal to, or smaller, than the one provided by > the client. > > > There are many MAYs in there. Does it mean that a value that is larger > can also be provided by the server? > If not, then shouldn't the second sentence say MUST? > > > > > 8.17. Session-Binding AVP > > s/ > The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY > be present in application-specific authorization answer messages. If > present, this AVP MAY inform the Diameter client that all future > application-specific re-auth messages for this session MUST be sent > to the same authorization server. This AVP MAY also specify that a > Session-Termination-Request message for this session MUST be sent to > the same authorizing server. > / > The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY > be present in application-specific authorization answer messages. If > present, this AVP MAY inform the Diameter client that all future > application-specific re-auth and > Session-Termination-Request messages > for this session MUST be sent > to the same authorization server. > > --- stop here ---- > more later. > > Ciao > Hannes > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 24 16:06:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D383A6B15; Wed, 24 Sep 2008 16:06:46 -0700 (PDT) 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 16C633A6B15 for ; Wed, 24 Sep 2008 16:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 OxWJyc7Qjuza for ; Wed, 24 Sep 2008 16:06:44 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 2C44C3A6A6D for ; Wed, 24 Sep 2008 16:06:44 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Q0087C2VEQ0@usaga04-in.huawei.com> for dime@ietf.org; Wed, 24 Sep 2008 18:06:50 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K7Q00HRI2V8E8@usaga04-in.huawei.com> for dime@ietf.org; Wed, 24 Sep 2008 18:06:50 -0500 (CDT) Date: Wed, 24 Sep 2008 18:06:43 -0500 From: Frank Xia To: jouni.korhonen@teliasonera.com Message-id: <004501c91e9a$397251c0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <20080923163001.7FFFD3A6A8F@core3.amsl.com> Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-mip6-split-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni Please check section "6.7. MIP-Careof-Address AVP". The care of address is limited to IPv6. However, it is possible to be IPv4 in DSMIPv6. BR Frank ----- Original Message ----- From: To: Cc: Sent: Tuesday, September 23, 2008 11:30 AM Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-12.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Diameter Maintenance and Extensions > Working Group of the IETF. > > > Title : Diameter Mobile IPv6: Support for Home Agent to Diameter > Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-ietf-dime-mip6-split-12.txt > Pages : 37 > Date : 2008-09-23 > > Mobile IPv6 deployments may want to bootstrap their operations > dynamically based on an interaction between the Home Agent and the > Diameter server of the Mobile Service Provider (MSP). This document > specifies the interaction between a Mobile IP Home Agent and that > Diameter server. > > Several different mechanisms for authenticating a Mobile Node are > supported. The usage of the Internet Key Exchange v2 (IKEv2) > protocol allows different mechanisms, such as the Extensible > Authentication Protocol (EAP), certificates and pre-shared secrets to > be used. Furthermore, another method makes use of the Mobile IPv6 > Authentication Protocol. In addition to authentication and > authorization, the configuration of Mobile IPv6 specific parameters > and accounting is specified in this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Sep 24 22:46:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7473A6844; Wed, 24 Sep 2008 22:46:18 -0700 (PDT) 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 BAC733A6856 for ; Wed, 24 Sep 2008 22:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS-PNDKy1t66 for ; Wed, 24 Sep 2008 22:46:15 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id E1C463A6844 for ; Wed, 24 Sep 2008 22:46:11 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Sep 2008 07:43:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Sep 2008 07:43:19 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A24C5@SEHAN021MB.tcad.telia.se> In-Reply-To: <004501c91e9a$397251c0$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] I-D Action:draft-ietf-dime-mip6-split-12.txt Thread-Index: Ackemj4wnhzNSYXLScOItTsDzBK22AANzdbw References: <20080923163001.7FFFD3A6A8F@core3.amsl.com> <004501c91e9a$397251c0$5c0c7c0a@china.huawei.com> From: To: X-OriginalArrivalTime: 25 Sep 2008 05:43:20.0050 (UTC) FILETIME=[9DC1ED20:01C91ED1] Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-mip6-split-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Frank, > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: 25. syyskuuta 2008 2:07 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-mip6-split-12.txt > > > Hi Jouni > > Please check section "6.7. MIP-Careof-Address AVP". > The care of address is limited to IPv6. > > However, it is possible to be IPv4 in DSMIPv6. Good catch. Thanks. Cheers, Jouni > > BR > Frank > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, September 23, 2008 11:30 AM > Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-12.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Diameter Maintenance and > Extensions > > Working Group of the IETF. > > > > > > Title : Diameter Mobile IPv6: Support for Home > Agent to Diameter > > Server Interaction > > Author(s) : J. Korhonen, et al. > > Filename : draft-ietf-dime-mip6-split-12.txt > > Pages : 37 > > Date : 2008-09-23 > > > > Mobile IPv6 deployments may want to bootstrap their operations > > dynamically based on an interaction between the Home Agent and the > > Diameter server of the Mobile Service Provider (MSP). This document > > specifies the interaction between a Mobile IP Home Agent and that > > Diameter server. > > > > Several different mechanisms for authenticating a Mobile Node are > > supported. The usage of the Internet Key Exchange v2 (IKEv2) > > protocol allows different mechanisms, such as the Extensible > > Authentication Protocol (EAP), certificates and pre-shared > secrets to > > be used. Furthermore, another method makes use of the Mobile IPv6 > > Authentication Protocol. In addition to authentication and > > authorization, the configuration of Mobile IPv6 specific parameters > > and accounting is specified in this document. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-12.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > -------------------------------------------------------------- > ------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Sep 26 08:09:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464F228C14A; Fri, 26 Sep 2008 08:09:07 -0700 (PDT) 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 80AD53A6AA1 for ; Fri, 26 Sep 2008 01:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3] 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 I3NLiMoWAc-x for ; Fri, 26 Sep 2008 01:46:55 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id C4CB83A697F for ; Fri, 26 Sep 2008 01:46:55 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id n4so427809wag.5 for ; Fri, 26 Sep 2008 01:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=B4GH4YPurrmuE5WMsnBC2B1bxMh8CgEv8TvEp4pGzRk=; b=UZtKKmnAtNDn+zjroQLrxTPKmo3QFTDLmotSKukaufPQaEN1s1GAfTfRnfPIJVOf39 95zuznQuzJ6oPNl9qMLT1RoBClL7MJ/zMXAPK6TAxM2KiGLwlWRbNH/plQcOJZt2wyPo g25rW+qgyK2XWHbeXrNZd9df8OGZQI7PXXK1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=cIq0GJLe4AmcA0wRLGxuSWI4s5siq3iXpttHsNXBr7pzZL2HkWRsFOoAn+oJxp7Wd+ nMiapE/Yck8wRKNASgcRndKHzl7cpHq/alLCu0AbvQk05HiYb3+Lnf4EeV3P/WdwMNO+ eneQu7g1O0+kVPXZLavyBOGyhwj7sSUbrKgjQ= Received: by 10.114.56.4 with SMTP id e4mr1050024waa.0.1222418813858; Fri, 26 Sep 2008 01:46:53 -0700 (PDT) Received: by 10.114.60.14 with HTTP; Fri, 26 Sep 2008 01:46:53 -0700 (PDT) Message-ID: <13c12d6b0809260146m3fc89bacsa8b9cd0f772cd7f6@mail.gmail.com> Date: Fri, 26 Sep 2008 10:46:53 +0200 From: "Bartosz Baranowski" To: dime@ietf.org, "=?UTF-8?Q?Alexandre_Mendon=C3=A7a?=" MIME-Version: 1.0 Subject: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2050449821==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============2050449821== Content-Type: multipart/alternative; boundary="----=_Part_5150_8617341.1222418813848" ------=_Part_5150_8617341.1222418813848 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Im trying to figure few things out for some time now and up until now I have been hearing contradicting voices wherever I turn myself. I would like to know what are values of ApplicationID set in messages - Base messages used in context of Sh interface to Authanticate/Authorize user? Lets consider flow like follows (not sure if its valid or not): CLIENT SERVER(HSS ?) | ------------- UDR -----------------> | SesssionId_1, AppId_1 ==Sh X | <----------- RAR ------------------- | SessionId_2, AppId_2= Base | ------------- RAA -----------------> | SessionId_2, AppId_2= Base | ------------- UDR -----------------> | SesssionId_1, AppId_1 ==Sh | <----------- UDA -------------------- | SesssionId_1, AppId_1 ==Sh Does X indicates UDA denying access? Is SessionId_1 equal to SessionId_2? Is AppId_2== Base or is it equal to AppId_2 ? Thanks ------=_Part_5150_8617341.1222418813848 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi
Im trying to figure few things out for some time now and up until now I have been hearing contradicting voices wherever I turn myself.
I would like to know what are values of ApplicationID set in messages - Base messages used in context of Sh interface to Authanticate/Authorize user?

Lets consider flow like follows (not sure if its valid or not):




CLIENT                               SERVER(HSS ?)
     | -------------    UDR -----------------> |                             SesssionId_1, AppId_1 ==Sh
                           X
     | <-----------    RAR ------------------- |                             SessionId_2, AppId_2= Base
     | -------------    RAA -----------------> |                             SessionId_2, AppId_2= Base
     | -------------    UDR -----------------> |                             SesssionId_1, AppId_1 ==Sh
     | <-----------   UDA -------------------- |                             SesssionId_1, AppId_1 ==Sh


Does X indicates UDA denying access?
Is SessionId_1 equal to SessionId_2?
Is AppId_2== Base or is it equal to AppId_2 ?


Thanks
------=_Part_5150_8617341.1222418813848-- --===============2050449821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2050449821==-- From dime-bounces@ietf.org Fri Sep 26 08:15:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA41128C140; Fri, 26 Sep 2008 08:15:17 -0700 (PDT) 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 9CDFE28C140 for ; Fri, 26 Sep 2008 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 aIO1YCsetrs8 for ; Fri, 26 Sep 2008 08:15:15 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id E0F5328C12C for ; Fri, 26 Sep 2008 08:15:15 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id n4so497657wag.5 for ; Fri, 26 Sep 2008 08:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=wvIs4TAzBsdG6BK4qftplFl1fPFy1vs6x/MrYnNcdgM=; b=q47XrUtNnNLwe/9tZSh7w0fgp81ByNvn6ReAL8Vtb13M8x4ICFcjhPR1XJ+anVKLc/ oAUzBRtoXOfvucDv6ylWeoZOMS0JChvLPGZRW6EIKoUFBGjijMUka3vVI/zzlX2jHZs7 4RSiny9JHPXcO47dR2QFfRIkNntZ2MzSaaU6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=tQM501aWB6Cwz/sTBTMwepmO5Lg3pBXfbD4nOS1FjRyVJ0WN0/TBrkxyE0bLvpCgFs Do15wlMlbPVhFj4RRMqJ77Zs7MKbHjIR/gA9DqmnpXI5cDTnRIl67F71CDzBLnSgaXvq C+OAXMUp+mqbGXhH/XkZnsp/Lmc5+9yA7hsuA= Received: by 10.114.144.1 with SMTP id r1mr1522973wad.97.1222442125536; Fri, 26 Sep 2008 08:15:25 -0700 (PDT) Received: by 10.114.60.14 with HTTP; Fri, 26 Sep 2008 08:15:25 -0700 (PDT) Message-ID: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> Date: Fri, 26 Sep 2008 17:15:25 +0200 From: "Bartosz Baranowski" To: dime@ietf.org MIME-Version: 1.0 Subject: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0957547885==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0957547885== Content-Type: multipart/alternative; boundary="----=_Part_8771_31847842.1222442125537" ------=_Part_8771_31847842.1222442125537 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Im trying to figure few things out for some time now and up until now I have been hearing contradicting voices wherever I turn myself. I would like to know what are values of ApplicationID set in messages - Base messages used in context of Sh interface to Authanticate/Authorize user? Lets consider flow like follows (not sure if its valid or not): CLIENT SERVER(HSS ?) | ------------- UDR -----------------> | SesssionId_1, AppId_1 ==Sh X | <----------- RAR ------------------- | SessionId_2, AppId_2= Base | ------------- RAA -----------------> | SessionId_2, AppId_2= Base | ------------- UDR -----------------> | SesssionId_1, AppId_1 ==Sh | <----------- UDA -------------------- | SesssionId_1, AppId_1 ==Sh Does X indicates UDA denying access? Is SessionId_1 equal to SessionId_2? Is AppId_2== Base or is it equal to AppId_2 ? Thanks ------=_Part_8771_31847842.1222442125537 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi
Im trying to figure few things out for some time now and up until now I have been hearing contradicting voices wherever I turn myself.
I would like to know what are values of ApplicationID set in messages - Base messages used in context of Sh interface to Authanticate/Authorize user?

Lets consider flow like follows (not sure if its valid or not):




CLIENT                        
       SERVER(HSS ?)
     | -------------    UDR -----------------> |                             SesssionId_1, AppId_1 ==Sh
                           X
     | <-----------    RAR ------------------- |                             SessionId_2, AppId_2= Base
     | -------------    RAA -----------------> |                             SessionId_2, AppId_2= Base
     | -------------    UDR -----------------> |                             SesssionId_1, AppId_1 ==Sh
     | <-----------   UDA -------------------- |                             SesssionId_1, AppId_1 ==Sh


Does X indicates UDA denying access?
Is SessionId_1 equal to SessionId_2?
Is AppId_2== Base or is it equal to AppId_2 ?


Thanks
------=_Part_8771_31847842.1222442125537-- --===============0957547885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0957547885==-- From dime-bounces@ietf.org Fri Sep 26 08:23:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55AE28C15F; Fri, 26 Sep 2008 08:23:16 -0700 (PDT) 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 D662828C15F for ; Fri, 26 Sep 2008 08:23:15 -0700 (PDT) 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_63=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 oWmjj5ZVHTBs for ; Fri, 26 Sep 2008 08:23:10 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 2332628C157 for ; Fri, 26 Sep 2008 08:23:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 6E91DC8403 for ; Fri, 26 Sep 2008 11:23:14 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29564-06 for ; Fri, 26 Sep 2008 11:23:13 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 26 Sep 2008 11:23:13 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Sep 2008 11:23:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 26 Sep 2008 20:53:08 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C07772C84@exchindia3.starentnetworks.com> In-Reply-To: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Application ID, Session Id and message flows Thread-Index: Ackf6sFt8WyWo8GvQ0O1ZZLfrkPZnQAAHdVA References: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> From: "Gowda, Avinash" To: "Bartosz Baranowski" , X-OriginalArrivalTime: 26 Sep 2008 15:23:14.0047 (UTC) FILETIME=[CB0248F0:01C91FEB] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0787969931==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0787969931== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C91FEB.C900EC76" This is a multi-part message in MIME format. ------_=_NextPart_001_01C91FEB.C900EC76 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bartosz, =20 Does X indicates UDA denying access? >> Yes. Is SessionId_1 equal to SessionId_2? >> Yes. Always Re-Auth Request is sent on the existing session. If the session-id is not available then Result-Code in RAA will be sent as DIAMETER_UNKNOWN_SESSION_ID (5002). Is AppId_2=3D=3D Base or is it equal to AppId_2 ? >> In credit-control application we use Application-Id 4. The same Application-Id will be used in RAR/RAA also. I am not sure about Sh interface. =20 Please anybody comment on this answer. =20 Thanks, Avinash Gowda ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Bartosz Baranowski Sent: Friday, September 26, 2008 8:45 PM To: dime@ietf.org Subject: [Dime] Application ID, Session Id and message flows =20 Hi Im trying to figure few things out for some time now and up until now I have been hearing contradicting voices wherever I turn myself. I would like to know what are values of ApplicationID set in messages - Base messages used in context of Sh interface to Authanticate/Authorize user? Lets consider flow like follows (not sure if its valid or not): CLIENT =20 SERVER(HSS ?) | ------------- UDR -----------------> | SesssionId_1, AppId_1 =3D=3DSh X | <----------- RAR ------------------- | SessionId_2, AppId_2=3D Base | ------------- RAA -----------------> | SessionId_2, AppId_2=3D Base | ------------- UDR -----------------> | SesssionId_1, AppId_1 =3D=3DSh | <----------- UDA -------------------- | SesssionId_1, AppId_1 =3D=3DSh Does X indicates UDA denying access? Is SessionId_1 equal to SessionId_2? Is AppId_2=3D=3D Base or is it equal to AppId_2 ? Thanks=20 ------_=_NextPart_001_01C91FEB.C900EC76 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Bartosz,

 

Does X indicates UDA denying = access?

>> Yes.

Is SessionId_1 equal to = SessionId_2?

>> Yes. Always Re-Auth Request is sent on the existing = session. If the session-id is not available then Result-Code in RAA will be sent = as DIAMETER_UNKNOWN_SESSION_I= D (5002).


Is AppId_2=3D=3D Base or is it equal to AppId_2 = ?

>> In credit-control application we use Application-Id 4. = The same Application-Id will be used in RAR/RAA also. I am not sure about Sh interface.

 

Please anybody comment on this answer.

 

Thanks,

Avinash = Gowda

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Bartosz Baranowski
Sent: Friday, September = 26, 2008 8:45 PM
To: dime@ietf.org
Subject: [Dime] = Application ID, Session Id and message flows

 

Hi
Im trying to figure few things out for some time now and up until now I = have been hearing contradicting voices wherever I turn myself.
I would like to know what are values of ApplicationID set in messages - = Base messages used in context of Sh interface to Authanticate/Authorize = user?

Lets consider flow like follows (not sure if its valid or not):




CLIENT           &= nbsp;           &n= bsp;

       SERVER(HSS ?)
     | -------------    UDR = -----------------> |            =             &= nbsp;    SesssionId_1, AppId_1 =3D=3DSh
            &= nbsp;           &n= bsp;  X
     | <-----------    RAR ------------------- |            =             &= nbsp;    SessionId_2, AppId_2=3D Base
     | -------------    RAA -----------------> |            =             &= nbsp;    SessionId_2, AppId_2=3D Base
     | -------------    UDR -----------------> |            =             &= nbsp;    SesssionId_1, AppId_1 =3D=3DSh
     | <-----------   UDA = -------------------- |            =             &= nbsp;    SesssionId_1, AppId_1 =3D=3DSh


Does X indicates UDA denying access?
Is SessionId_1 equal to SessionId_2?
Is AppId_2=3D=3D Base or is it equal to AppId_2 ?


Thanks

------_=_NextPart_001_01C91FEB.C900EC76-- --===============0787969931== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0787969931==-- From dime-bounces@ietf.org Fri Sep 26 08:30:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFE728C187; Fri, 26 Sep 2008 08:30:41 -0700 (PDT) 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 7621F28C157 for ; Fri, 26 Sep 2008 08:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_63=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 pspEesifG+8A for ; Fri, 26 Sep 2008 08:30:39 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 55E2028C11C for ; Fri, 26 Sep 2008 08:30:38 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m8QFQ4bh002257 for ; Fri, 26 Sep 2008 20:56:04 +0530 Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m8QFPxoI002202 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Fri, 26 Sep 2008 20:55:59 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Fri, 26 Sep 2008 20:59:38 +0530 From: Vipul2 Aggarwal To: "dime@ietf.org" Date: Fri, 26 Sep 2008 20:59:36 +0530 Thread-Topic: [Dime] Application ID, Session Id and message flows Thread-Index: Ackf6r2CTjhNsmWtRpCMN2LFXF81zAAASOdg Message-ID: <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> References: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> In-Reply-To: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1974807246==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1974807246== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_2644750229D3DC4896C04587BF628046021CE4411AGUREXMB01ASIA_" --_000_2644750229D3DC4896C04587BF628046021CE4411AGUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As far as I know, there is no RAR message in Sh Interface. The messages supported in Sh Interface are UDR/UDA PUR/PUA SNR/SNA PNR/PNA All these messages use the application ID of Sh. Can you please elaborate more on the context of RAR in the Sh interface? Regds, Vipul Aggarwal Senior Software Engineer A R I C E N T The Presidency Tower-A 351/2, Sector 14, M.G Road Gurgaon, 122001, Haryana, India ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Bar= tosz Baranowski Sent: Friday, September 26, 2008 8:45 PM To: dime@ietf.org Subject: [Dime] Application ID, Session Id and message flows Hi Im trying to figure few things out for some time now and up until now I hav= e been hearing contradicting voices wherever I turn myself. I would like to know what are values of ApplicationID set in messages - Bas= e messages used in context of Sh interface to Authanticate/Authorize user? Lets consider flow like follows (not sure if its valid or not): CLIENT SERVER(HSS ?) | ------------- UDR -----------------> | = SesssionId_1, AppId_1 =3D=3DSh X | <----------- RAR ------------------- | = SessionId_2, AppId_2=3D Base | ------------- RAA -----------------> | = SessionId_2, AppId_2=3D Base | ------------- UDR -----------------> | = SesssionId_1, AppId_1 =3D=3DSh | <----------- UDA -------------------- | = SesssionId_1, AppId_1 =3D=3DSh Does X indicates UDA denying access? Is SessionId_1 equal to SessionId_2? Is AppId_2=3D=3D Base or is it equal to AppId_2 ? Thanks ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_2644750229D3DC4896C04587BF628046021CE4411AGUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" = name=3D"Street" />

Hi,

 

As far as I know, there is no RAR mess= age in Sh Interface.

The messages supported in Sh Interface= are

UDR= /UDA

PUR= /PUA

SNR= /SNA

PNR= /PNA

 

All these messages use the application= ID of Sh.

 

Can you please elaborate more on the c= ontext of RAR in the Sh interface?

 

Regds,

Vipul Aggarwal

Senior Softwa= re Engineer

 

= A R I C E N T

 

The Presidency Tower-A

351/2, Sector= 14, M.G Road

Gurgaon, 1220= 01,  Haryana, India

 

From: dime= -bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Bartosz Baranowski
Sent: Friday, September 26, = 2008 8:45 PM
To: dime@ietf.org
Subject: [Dime] Application = ID, Session Id and message flows

 

Hi
Im trying to figure few things out for some time now and up until now I hav= e been hearing contradicting voices wherever I turn myself.
I would like to know what are values of ApplicationID set in messages - Bas= e messages used in context of Sh interface to Authanticate/Authorize user?<= br>
Lets consider flow like follows (not sure if its valid or not):




CLIENT           &nb= sp;            =

       SERVER(HSS ?)
     | -------------    UDR -----------------= > |           &nb= sp;            =      SesssionId_1, AppId_1 =3D=3DSh
            &nb= sp;            =   X
     | <-----------    RAR ----------= --------- |          &nbs= p;            &= nbsp;     SessionId_2, AppId_2=3D Base
     | -------------    RAA ------------= -----> |          &nbs= p;            &= nbsp;     SessionId_2, AppId_2=3D Base
     | -------------    UDR ------------= -----> |          &nbs= p;            &= nbsp;     SesssionId_1, AppId_1 =3D=3DSh
     | <-----------   UDA ----------------= ---- |           &nb= sp;            =      SesssionId_1, AppId_1 =3D=3DSh


Does X indicates UDA denying access?
Is SessionId_1 equal to SessionId_2?
Is AppId_2=3D=3D Base or is it equal to AppId_2 ?


Thanks


"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
 --_000_2644750229D3DC4896C04587BF628046021CE4411AGUREXMB01ASIA_-- --===============1974807246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1974807246==-- From dime-bounces@ietf.org Fri Sep 26 08:44:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFE028C11C; Fri, 26 Sep 2008 08:44:51 -0700 (PDT) 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 394BB3A6A5D for ; Fri, 26 Sep 2008 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_63=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 FM92E8zQucnE for ; Fri, 26 Sep 2008 08:44:47 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id EB5BD3A6AC8 for ; Fri, 26 Sep 2008 08:44:46 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1154897wfd.31 for ; Fri, 26 Sep 2008 08:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=uwBoz2ory8juSm7rwR3QCxIQSjbIJygVVCfSq5Z68hw=; b=tre3d+Niz/Uiux3I2UPi4SLzEb4K7v3loAd/POGTSGQ9x/NnOg4gFuO/aHFePJDcAd sKYt9jvRb7uIx2zvoqTqruP0XJepeC+XTJt2AdkF08H4ScZKk65yjJZfWhOlBt45SY+f 4c1hQLG4tKY2s16Lnkl5PsfOQWY8CHF9hUHvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=PqKvpozrL1ShHELUOfE6XB3x232b+OrY8OqRwWEdC88Gf3hPhLIJpy/c8EHVe2TBLz SBcqWUCaCykZ43zoyFoq5yZe1EqSDwhYfBxKdc9J9V2xsQmHKfreSEfCdLFb5FukRw8A qkQYtEKJdFKioCMAaTjWS75Z8SPG/jzsxglcE= Received: by 10.114.74.18 with SMTP id w18mr1565633waa.125.1222443866057; Fri, 26 Sep 2008 08:44:26 -0700 (PDT) Received: by 10.114.60.14 with HTTP; Fri, 26 Sep 2008 08:44:25 -0700 (PDT) Message-ID: <13c12d6b0809260844s281521e4tfe007acb0b2c30d5@mail.gmail.com> Date: Fri, 26 Sep 2008 17:44:25 +0200 From: "Bartosz Baranowski" To: "Vipul2 Aggarwal" In-Reply-To: <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> MIME-Version: 1.0 References: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> Cc: "dime@ietf.org" Subject: Re: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1624901285==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1624901285== Content-Type: multipart/alternative; boundary="----=_Part_9067_30633990.1222443866035" ------=_Part_9067_30633990.1222443866035 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Thanks for such quick answer. See inline On Fri, Sep 26, 2008 at 5:29 PM, Vipul2 Aggarwal < vipul2.aggarwal@aricent.com> wrote: > Hi, > > > > As far as I know, there is no RAR message in Sh Interface. > Yes I know, there is no such message in Sh defined > The messages supported in Sh Interface are > > UDR/UDA > > PUR/PUA > > SNR/SNA > > PNR/PNA > > > > All these messages use the application ID of Sh. > Someone just threw example of Sh scenario where server reqeust authentication - I didnt find anything about that in TS, rfc or google, neither I was able to find any example scenarios (of any kind, not regardign this particular case), so I have decided to post here. Up until now I was sure that there is not authentication in Sh scenarios, or is there? Is there any case of application that uses base messages? I mean there is no app id in Base, this would indicate that all aplication have to support those? > Can you please elaborate more on the context of RAR in the Sh interface? > > > > Regds, > > *Vipul Aggarwal* > > Senior Software Engineer > > > > *A R I C E N T* > > > > The Presidency Tower-A > > 351/2, Sector 14, M.G Road > > Gurgaon, 122001, Haryana, India > > > ------------------------------ > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf Of > *Bartosz Baranowski > *Sent:* Friday, September 26, 2008 8:45 PM > *To:* dime@ietf.org > *Subject:* [Dime] Application ID, Session Id and message flows > > > > Hi > > Im trying to figure few things out for some time now and up until now I > have been hearing contradicting voices wherever I turn myself. > I would like to know what are values of ApplicationID set in messages - > Base messages used in context of Sh interface to Authanticate/Authorize > user? > > Lets consider flow like follows (not sure if its valid or not): > > > > > CLIENT > > SERVER(HSS ?) > | ------------- UDR -----------------> > | SesssionId_1, AppId_1 ==Sh > X > | <----------- RAR ------------------- > | SessionId_2, AppId_2= Base > | ------------- RAA -----------------> > | SessionId_2, AppId_2= Base > | ------------- UDR -----------------> > | SesssionId_1, AppId_1 ==Sh > | <----------- UDA -------------------- > | SesssionId_1, AppId_1 ==Sh > > > Does X indicates UDA denying access? > Is SessionId_1 equal to SessionId_2? > Is AppId_2== Base or is it equal to AppId_2 ? > > > Thanks > > ------------------------------ > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error,please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage from > virus." > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > -- Bartosz Baranowski JBoss R & D ================================== Word of criticism meant to improve is always step forward. ------=_Part_9067_30633990.1222443866035 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi
Thanks for such quick answer.
See inline

On Fri, Sep 26, 2008 at 5:29 PM, Vipul2 Aggarwal <vipul2.aggarwal@aricent.com> wrote:

Hi,

 

As far as I know, there is no RAR message in Sh Interface.

Yes I know, there is no such message in Sh defined

The messages supported in Sh Interface are

UDR/UDA

PUR/PUA

SNR/SNA

PNR/PNA

 

All these messages use the application ID of Sh.

Someone just threw example of Sh scenario where server reqeust authentication - I didnt find anything about that in TS, rfc or google, neither I was able to find any example scenarios (of any kind, not regardign this particular case), so I have decided to post here.
Up until now I was sure that there is not authentication in Sh scenarios, or is there?
Is there any case of application that uses base messages? I mean there is no app id in Base, this would indicate that all aplication have to support those?

Can you please elaborate more on the context of RAR in the Sh interface?

 

Regds,

Vipul Aggarwal

Senior Software Engineer

 

A R I C E N T

 

The Presidency Tower-A

351/2, Sector 14, M.G Road

Gurgaon, 122001,  Haryana, India

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Bartosz Baranowski
Sent: Friday, September 26, 2008 8:45 PM
To: dime@ietf.org
Subject: [Dime] Application ID, Session Id and message flows

 

Hi


Im trying to figure few things out for some time now and up until now I have been hearing contradicting voices wherever I turn myself.
I would like to know what are values of ApplicationID set in messages - Base messages used in context of Sh interface to Authanticate/Authorize user?

Lets consider flow like follows (not sure if its valid or not):




CLIENT                        

       SERVER(HSS ?)
     | -------------    UDR -----------------> |                             SesssionId_1, AppId_1 ==Sh
                           X
     | <-----------    RAR ------------------- |                             SessionId_2, AppId_2= Base
     | -------------    RAA -----------------> |                             SessionId_2, AppId_2= Base
     | -------------    UDR -----------------> |                             SesssionId_1, AppId_1 ==Sh
     | <-----------   UDA -------------------- |                             SesssionId_1, AppId_1 ==Sh


Does X indicates UDA denying access?
Is SessionId_1 equal to SessionId_2?
Is AppId_2== Base or is it equal to AppId_2 ?


Thanks


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

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




--
Bartosz Baranowski
JBoss R & D
==================================
Word of criticism meant to improve is always step forward.
------=_Part_9067_30633990.1222443866035-- --===============1624901285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1624901285==-- From dime-bounces@ietf.org Fri Sep 26 09:04:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2334A28C13B; Fri, 26 Sep 2008 09:04:14 -0700 (PDT) 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 6958F3A67F6 for ; Fri, 26 Sep 2008 09:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_63=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 sPK21sY5Ls1h for ; Fri, 26 Sep 2008 09:04:05 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 382B328C11C for ; Fri, 26 Sep 2008 09:04:03 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m8QFxt3d014257 for ; Fri, 26 Sep 2008 21:29:55 +0530 Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m8QFxtWo014237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 26 Sep 2008 21:29:55 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Fri, 26 Sep 2008 21:33:34 +0530 From: Vipul2 Aggarwal To: Bartosz Baranowski Date: Fri, 26 Sep 2008 21:33:32 +0530 Thread-Topic: [Dime] Application ID, Session Id and message flows Thread-Index: Ackf7sQbI1+U/G4KSfa0BMJWcSaFBAAAX2TQ Message-ID: <2644750229D3DC4896C04587BF628046021CE44125@GUREXMB01.ASIAN.AD.ARICENT.COM> References: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> <13c12d6b0809260844s281521e4tfe007acb0b2c30d5@mail.gmail.com> In-Reply-To: <13c12d6b0809260844s281521e4tfe007acb0b2c30d5@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0328434575==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0328434575== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_2644750229D3DC4896C04587BF628046021CE44125GUREXMB01ASIA_" --_000_2644750229D3DC4896C04587BF628046021CE44125GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, You are right. There is no re-authentication scenario in Sh. Yes, there are interfaces (like NASReq, EAP, Wm, Rx, that I am aware of) th= at use base messages. But, these interfaces use their own application ID in= these messages i.e. they don't use the application ID of Base (i.e. 0) in = the messages. For e.g. NASReq interface uses the messages STR/STA, RAR/RAA, ASR/ASA. But,= the application ID that goes in these messages is that of NASReq (i.e. 1). Hope this helps. Regds, Vipul Aggarwal Senior Software Engineer A R I C E N T The Presidency Tower-A 351/2, Sector 14, M.G Road Gurgaon, 122001, Haryana, India ________________________________ From: Bartosz Baranowski [mailto:baranowb@gmail.com] Sent: Friday, September 26, 2008 9:14 PM To: Vipul2 Aggarwal Cc: dime@ietf.org Subject: Re: [Dime] Application ID, Session Id and message flows Hi Thanks for such quick answer. See inline On Fri, Sep 26, 2008 at 5:29 PM, Vipul2 Aggarwal > wrote: Hi, As far as I know, there is no RAR message in Sh Interface. Yes I know, there is no such message in Sh defined The messages supported in Sh Interface are UDR/UDA PUR/PUA SNR/SNA PNR/PNA All these messages use the application ID of Sh. Someone just threw example of Sh scenario where server reqeust authenticati= on - I didnt find anything about that in TS, rfc or google, neither I was a= ble to find any example scenarios (of any kind, not regardign this particul= ar case), so I have decided to post here. Up until now I was sure that there is not authentication in Sh scenarios, o= r is there? Is there any case of application that uses base messages? I mean there is n= o app id in Base, this would indicate that all aplication have to support t= hose? Can you please elaborate more on the context of RAR in the Sh interface? Regds, Vipul Aggarwal Senior Software Engineer A R I C E N T The Presidency Tower-A 351/2, Sector 14, M.G Road Gurgaon, 122001, Haryana, India ________________________________ From: dime-bounces@ietf.org [mailto:dime-boun= ces@ietf.org] On Behalf Of Bartosz Baranowski Sent: Friday, September 26, 2008 8:45 PM To: dime@ietf.org Subject: [Dime] Application ID, Session Id and message flows Hi Im trying to figure few things out for some time now and up until now I hav= e been hearing contradicting voices wherever I turn myself. I would like to know what are values of ApplicationID set in messages - Bas= e messages used in context of Sh interface to Authanticate/Authorize user? Lets consider flow like follows (not sure if its valid or not): CLIENT SERVER(HSS ?) | ------------- UDR -----------------> | = SesssionId_1, AppId_1 =3D=3DSh X | <----------- RAR ------------------- | = SessionId_2, AppId_2=3D Base | ------------- RAA -----------------> | = SessionId_2, AppId_2=3D Base | ------------- UDR -----------------> | = SesssionId_1, AppId_1 =3D=3DSh | <----------- UDA -------------------- | = SesssionId_1, AppId_1 =3D=3DSh Does X indicates UDA denying access? Is SessionId_1 equal to SessionId_2? Is AppId_2=3D=3D Base or is it equal to AppId_2 ? Thanks ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime -- Bartosz Baranowski JBoss R & D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Word of criticism meant to improve is always step forward. ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_2644750229D3DC4896C04587BF628046021CE44125GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" = name=3D"Street" />

Hi,

 

You are right. There is no re-authenti= cation scenario in Sh.

 

Yes, there are interfaces (like NASReq= , EAP, Wm, Rx, that I am aware of) that use base messages. But, these inter= faces use their own application ID in these messages i.e. they don’t use the application= ID of Base (i.e. 0) in the messages.

 

For e.g. NASReq interface uses the mes= sages STR/STA, RAR/RAA, ASR/ASA. But, the application ID that goes in these= messages is that of NASReq (i.e. 1).

 

Hope this helps.

Regds,

Vipul Aggarwal

Senior Software Engineer

 

A R I C E N T=

 

The Presidency Tower-A

351/2, Sector 14, M.G Road

Gurgaon, 122001,  Haryana, India

 

From: Bart= osz Baranowski [mailto:baranowb@gmail.com]
Sent: Friday, September 26, = 2008 9:14 PM
To: Vipul2 Aggarwal
Cc: dime@ietf.org
Subject: Re: [Dime] Applicat= ion ID, Session Id and message flows

 

Hi
Thanks for such quick answer.
See inline

On Fri, Sep 26, 2008 at 5:29 PM, Vipul2 Aggarwal <vipul2.aggarwal@aricent.com> wrote:=

Hi,

 

As far as I know, there is no RAR message in Sh Interface= .

Yes I know, there is no such message in Sh defined

The messages supported in Sh Interface are<= o:p>

UDR/UDA

PUR/PUA

SNR/SNA

PNR/PNA

 

All these messages use the application ID of Sh.

Someone just threw example of Sh scenario where server reqeust auth= entication - I didnt find anything about that in TS, rfc or google, neither= I was able to find any example scenarios (of any kind, not regardign this particular case), so I = have decided to post here.
Up until now I was sure that there is not authentication in Sh scenarios, o= r is there?
Is there any case of application that uses base messages? I mean there is n= o app id in Base, this would indicate that all aplication have to support t= hose?

Can you please elaborate more on the context of RAR in th= e Sh interface?

 

Regds,

Vipul Aggarwal

Senior Software Engineer

 

A R I C E N T=

 

The Presidency Tower-A

351/2, Sector 14, M.G Road

Gurgaon, 122001,  Haryana, India

 

From:<= span style=3D"font-size:10.0pt;font-family:Tahoma"> dime-bounces@iet= f.org [mailto:dime-bounces@ietf.org] On Behalf Of Bartosz Baranow= ski
Sent: Friday, September 26, = 2008 8:45 PM
To: dime@ietf.org
Subject: [Dime] Application = ID, Session Id and message flows

 

Hi


Im trying to figure few things out for some time now and up until now I hav= e been hearing contradicting voices wherever I turn myself.
I would like to know what are values of ApplicationID set in messages - Bas= e messages used in context of Sh interface to Authanticate/Authorize user?<= br>
Lets consider flow like follows (not sure if its valid or not):




CLIENT           &nb= sp;            =

       SERVER(HSS ?)
     | -------------    UDR -----------------= > |           &nb= sp;            =      SesssionId_1, AppId_1 =3D=3DSh
            &nb= sp;            =   X
     | <-----------    RAR ----------= --------- |          &nbs= p;            &= nbsp;     SessionId_2, AppId_2=3D Base
     | -------------    RAA ------------= -----> |          &nbs= p;            &= nbsp;     SessionId_2, AppId_2=3D Base
     | -------------    UDR ------------= -----> |          &nbs= p;            &= nbsp;     SesssionId_1, AppId_1 =3D=3DSh
     | <-----------   UDA ----------------= ---- |           &nb= sp;            =      SesssionId_1, AppId_1 =3D=3DSh


Does X indicates UDA denying access?
Is SessionId_1 equal to SessionId_2?
Is AppId_2=3D=3D Base or is it equal to AppId_2 ?


Thanks

 

"DISCLAIMER: This message is prop= rietary to Aricent and is intended solely for the use of the individual to = whom it is addressed. It may contain privileged or confidential information and should not be circu= lated or used for any purpose other than for what it is intended. If you ha= ve received this message in error,please notify the originator immediately.= If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, alt= ering, or disclosing the contents of this message. Aricent accepts no respo= nsibility for loss or damage arising from the use of the information transm= itted by this email including damage from virus."


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




--
Bartosz Baranowski
JBoss R & D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Word of criticism meant to improve is always step forward.


"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
 --_000_2644750229D3DC4896C04587BF628046021CE44125GUREXMB01ASIA_-- --===============0328434575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0328434575==-- From dime-bounces@ietf.org Fri Sep 26 10:48:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15163A69A1; Fri, 26 Sep 2008 10:48:44 -0700 (PDT) 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 22BCD3A69A1 for ; Fri, 26 Sep 2008 10:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_63=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 W1uK0848Mi8L for ; Fri, 26 Sep 2008 10:48:41 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id B619F3A68BB for ; Fri, 26 Sep 2008 10:48:41 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1206109wfd.31 for ; Fri, 26 Sep 2008 10:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=6UKu4aJL3v7JzzQWT254UEahUJbwjajRYJYfrTxynvU=; b=a7EsLTwH9LZCD90zA8fCRcsxuZ7IJ6swb3sOBVjomORGKG26Iv9M8F0826NQPAL2I+ 324WUGQpr1W3R2BRULyxAhn5wJDPThc8Mpv+Chjq9h4Jxfmb5QBae4XLBHsfkCwrFAfb X8M27nSnq7kD+WKq8OCWz9qBlNmnzBe0z/V6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=p1kR4UgrEaCVrS7ZgOH3Gcb8ko0ZuubX5XybiAR31+I/vq5W1rzzwYOuXfJ5yzZRMc Hn4Pi/2jrxJrPKFXOJfFG88cxclQChCK60OeHQkTbZa35BN1hIKINLxLCg+osoxXvYiS DHEj3NMzL73lGIJX+RO0+i4jMa62zXrWPm6ko= Received: by 10.114.201.1 with SMTP id y1mr1752445waf.216.1222451311278; Fri, 26 Sep 2008 10:48:31 -0700 (PDT) Received: by 10.114.60.14 with HTTP; Fri, 26 Sep 2008 10:48:31 -0700 (PDT) Message-ID: <13c12d6b0809261048u24d144cgb036d8a43f5f4487@mail.gmail.com> Date: Fri, 26 Sep 2008 19:48:31 +0200 From: "Bartosz Baranowski" To: "Vipul2 Aggarwal" In-Reply-To: <2644750229D3DC4896C04587BF628046021CE44125@GUREXMB01.ASIAN.AD.ARICENT.COM> MIME-Version: 1.0 References: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> <13c12d6b0809260844s281521e4tfe007acb0b2c30d5@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE44125@GUREXMB01.ASIAN.AD.ARICENT.COM> Cc: "dime@ietf.org" Subject: Re: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0633456221==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0633456221== Content-Type: multipart/alternative; boundary="----=_Part_9939_6085410.1222451311262" ------=_Part_9939_6085410.1222451311262 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Thanks, this clears my mind - should be mentioned in TS or rfc. On Fri, Sep 26, 2008 at 6:03 PM, Vipul2 Aggarwal < vipul2.aggarwal@aricent.com> wrote: > Hi, > > > > You are right. There is no re-authentication scenario in Sh. > > > > Yes, there are interfaces (like NASReq, EAP, Wm, Rx, that I am aware of) > that use base messages. But, these interfaces use their own application ID > in these messages i.e. they don't use the application ID of Base (i.e. 0) in > the messages. > > > > For e.g. NASReq interface uses the messages STR/STA, RAR/RAA, ASR/ASA. But, > the application ID that goes in these messages is that of NASReq (i.e. 1). > > > > Hope this helps. > > Regds, > > *Vipul Aggarwal* > > Senior Software Engineer > > > > *A R I C E N T* > > > > The Presidency Tower-A > > 351/2, Sector 14, M.G Road > > Gurgaon, 122001, Haryana, India > > > ------------------------------ > > *From:* Bartosz Baranowski [mailto:baranowb@gmail.com] > *Sent:* Friday, September 26, 2008 9:14 PM > *To:* Vipul2 Aggarwal > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] Application ID, Session Id and message flows > > > > Hi > Thanks for such quick answer. > See inline > > On Fri, Sep 26, 2008 at 5:29 PM, Vipul2 Aggarwal < > vipul2.aggarwal@aricent.com> wrote: > > Hi, > > > > As far as I know, there is no RAR message in Sh Interface. > > Yes I know, there is no such message in Sh defined > > The messages supported in Sh Interface are > > UDR/UDA > > PUR/PUA > > SNR/SNA > > PNR/PNA > > > > All these messages use the application ID of Sh. > > Someone just threw example of Sh scenario where server reqeust > authentication - I didnt find anything about that in TS, rfc or google, > neither I was able to find any example scenarios (of any kind, not regardign > this particular case), so I have decided to post here. > Up until now I was sure that there is not authentication in Sh scenarios, > or is there? > Is there any case of application that uses base messages? I mean there is > no app id in Base, this would indicate that all aplication have to support > those? > > Can you please elaborate more on the context of RAR in the Sh interface? > > > > Regds, > > *Vipul Aggarwal* > > Senior Software Engineer > > > > *A R I C E N T* > > > > The Presidency Tower-A > > 351/2, Sector 14, M.G Road > > Gurgaon, 122001, Haryana, India > > > ------------------------------ > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf Of > *Bartosz Baranowski > *Sent:* Friday, September 26, 2008 8:45 PM > *To:* dime@ietf.org > *Subject:* [Dime] Application ID, Session Id and message flows > > > > Hi > > > Im trying to figure few things out for some time now and up until now I > have been hearing contradicting voices wherever I turn myself. > I would like to know what are values of ApplicationID set in messages - > Base messages used in context of Sh interface to Authanticate/Authorize > user? > > Lets consider flow like follows (not sure if its valid or not): > > > > > CLIENT > > SERVER(HSS ?) > | ------------- UDR -----------------> > | SesssionId_1, AppId_1 ==Sh > X > | <----------- RAR ------------------- > | SessionId_2, AppId_2= Base > | ------------- RAA -----------------> > | SessionId_2, AppId_2= Base > | ------------- UDR -----------------> > | SesssionId_1, AppId_1 ==Sh > | <----------- UDA -------------------- > | SesssionId_1, AppId_1 ==Sh > > > Does X indicates UDA denying access? > Is SessionId_1 equal to SessionId_2? > Is AppId_2== Base or is it equal to AppId_2 ? > > > Thanks > > > ------------------------------ > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error,please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage from > virus." > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > -- > Bartosz Baranowski > JBoss R & D > ================================== > Word of criticism meant to improve is always step forward. > > ------------------------------ > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error,please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage from > virus." > -- Bartosz Baranowski JBoss R & D ================================== Word of criticism meant to improve is always step forward. ------=_Part_9939_6085410.1222451311262 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi
Thanks, this clears my mind - should be mentioned in TS or rfc.

On Fri, Sep 26, 2008 at 6:03 PM, Vipul2 Aggarwal <vipul2.aggarwal@aricent.com> wrote:

Hi,

 

You are right. There is no re-authentication scenario in Sh.

 

Yes, there are interfaces (like NASReq, EAP, Wm, Rx, that I am aware of) that use base messages. But, these interfaces use their own application ID in these messages i.e. they don't use the application ID of Base (i.e. 0) in the messages.

 

For e.g. NASReq interface uses the messages STR/STA, RAR/RAA, ASR/ASA. But, the application ID that goes in these messages is that of NASReq (i.e. 1).

 

Hope this helps.

Regds,

Vipul Aggarwal

Senior Software Engineer

 

A R I C E N T

 

The Presidency Tower-A

351/2, Sector 14, M.G Road

Gurgaon, 122001,  Haryana, India

 

From: Bartosz Baranowski [mailto:baranowb@gmail.com]
Sent: Friday, September 26, 2008 9:14 PM
To: Vipul2 Aggarwal
Cc: dime@ietf.org
Subject: Re: [Dime] Application ID, Session Id and message flows

 

Hi
Thanks for such quick answer.
See inline

On Fri, Sep 26, 2008 at 5:29 PM, Vipul2 Aggarwal <vipul2.aggarwal@aricent.com> wrote:

Hi,

 

As far as I know, there is no RAR message in Sh Interface.

Yes I know, there is no such message in Sh defined

The messages supported in Sh Interface are

UDR/UDA

PUR/PUA

SNR/SNA

PNR/PNA

 

All these messages use the application ID of Sh.

Someone just threw example of Sh scenario where server reqeust authentication - I didnt find anything about that in TS, rfc or google, neither I was able to find any example scenarios (of any kind, not regardign this particular case), so I have decided to post here.
Up until now I was sure that there is not authentication in Sh scenarios, or is there?
Is there any case of application that uses base messages? I mean there is no app id in Base, this would indicate that all aplication have to support those?

Can you please elaborate more on the context of RAR in the Sh interface?

 

Regds,

Vipul Aggarwal

Senior Software Engineer

 

A R I C E N T

 

The Presidency Tower-A

351/2, Sector 14, M.G Road

Gurgaon, 122001,  Haryana, India

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Bartosz Baranowski
Sent: Friday, September 26, 2008 8:45 PM
To: dime@ietf.org
Subject: [Dime] Application ID, Session Id and message flows

 

Hi


Im trying to figure few things out for some time now and up until now I have been hearing contradicting voices wherever I turn myself.
I would like to know what are values of ApplicationID set in messages - Base messages used in context of Sh interface to Authanticate/Authorize user?

Lets consider flow like follows (not sure if its valid or not):




CLIENT                        

       SERVER(HSS ?)
     | -------------    UDR -----------------> |                             SesssionId_1, AppId_1 ==Sh
                           X
     | <-----------    RAR ------------------- |                             SessionId_2, AppId_2= Base
     | -------------    RAA -----------------> |                             SessionId_2, AppId_2= Base
     | -------------    UDR -----------------> |                             SesssionId_1, AppId_1 ==Sh
     | <-----------   UDA -------------------- |                             SesssionId_1, AppId_1 ==Sh


Does X indicates UDA denying access?
Is SessionId_1 equal to SessionId_2?
Is AppId_2== Base or is it equal to AppId_2 ?


Thanks

 

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


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




--
Bartosz Baranowski
JBoss R & D
==================================
Word of criticism meant to improve is always step forward.


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



--
Bartosz Baranowski
JBoss R & D
==================================
Word of criticism meant to improve is always step forward.
------=_Part_9939_6085410.1222451311262-- --===============0633456221== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0633456221==-- From dime-bounces@ietf.org Fri Sep 26 11:25:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534973A68B0; Fri, 26 Sep 2008 11:25:27 -0700 (PDT) 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 0B8143A68B0 for ; Fri, 26 Sep 2008 11:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_63=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 pF1-m6-Ch1NO for ; Fri, 26 Sep 2008 11:25:23 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8C45A3A6A5C for ; Fri, 26 Sep 2008 11:25:19 -0700 (PDT) Received: (qmail invoked by alias); 26 Sep 2008 18:25:29 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.101.110] by mail.gmx.net (mp005) with SMTP; 26 Sep 2008 20:25:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/FcmQwjJLFJv/CcijVHnA/PJjDl6YrhZ0DgEzFda 32nsR0LUoE5x+l Message-ID: <48DD291D.10800@gmx.net> Date: Fri, 26 Sep 2008 21:25:33 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bartosz Baranowski References: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> <13c12d6b0809260844s281521e4tfe007acb0b2c30d5@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE44125@GUREXMB01.ASIAN.AD.ARICENT.COM> <13c12d6b0809261048u24d144cgb036d8a43f5f4487@mail.gmail.com> In-Reply-To: <13c12d6b0809261048u24d144cgb036d8a43f5f4487@mail.gmail.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: "dime@ietf.org" Subject: Re: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org A well written IETF document must describe the Application ID setting for the messages an application uses. Bartosz Baranowski wrote: > Hi > Thanks, this clears my mind - should be mentioned in TS or rfc. > > On Fri, Sep 26, 2008 at 6:03 PM, Vipul2 Aggarwal > > wrote: > > Hi, > > > > You are right. There is no re-authentication scenario in Sh. > > > > Yes, there are interfaces (like NASReq, EAP, Wm, Rx, that I am > aware of) that use base messages. But, these interfaces use their > own application ID in these messages i.e. they don't use the > application ID of Base (i.e. 0) in the messages. > > > > For e.g. NASReq interface uses the messages STR/STA, RAR/RAA, > ASR/ASA. But, the application ID that goes in these messages is > that of NASReq (i.e. 1). > > > > Hope this helps. > > Regds, > > *Vipul Aggarwal* > > Senior Software Engineer > > > > *A R I C E N T* > > > > The Presidency Tower-A > > 351/2, Sector 14, M.G Road > > Gurgaon, 122001, Haryana, India > > > > ------------------------------------------------------------------------ > > *From:* Bartosz Baranowski [mailto:baranowb@gmail.com > ] > *Sent:* Friday, September 26, 2008 9:14 PM > *To:* Vipul2 Aggarwal > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] Application ID, Session Id and message flows > > > > Hi > Thanks for such quick answer. > See inline > > On Fri, Sep 26, 2008 at 5:29 PM, Vipul2 Aggarwal > > > wrote: > > Hi, > > > > As far as I know, there is no RAR message in Sh Interface. > > Yes I know, there is no such message in Sh defined > > The messages supported in Sh Interface are > > UDR/UDA > > PUR/PUA > > SNR/SNA > > PNR/PNA > > > > All these messages use the application ID of Sh. > > Someone just threw example of Sh scenario where server reqeust > authentication - I didnt find anything about that in TS, rfc or > google, neither I was able to find any example scenarios (of any > kind, not regardign this particular case), so I have decided to > post here. > Up until now I was sure that there is not authentication in Sh > scenarios, or is there? > Is there any case of application that uses base messages? I mean > there is no app id in Base, this would indicate that all > aplication have to support those? > > Can you please elaborate more on the context of RAR in the Sh > interface? > > > > Regds, > > *Vipul Aggarwal* > > Senior Software Engineer > > > > *A R I C E N T* > > > > The Presidency Tower-A > > 351/2, Sector 14, M.G Road > > Gurgaon, 122001, Haryana, India > > > > ------------------------------------------------------------------------ > > *From:* dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org ] > *On Behalf Of *Bartosz Baranowski > *Sent:* Friday, September 26, 2008 8:45 PM > *To:* dime@ietf.org > *Subject:* [Dime] Application ID, Session Id and message flows > > > > Hi > > > Im trying to figure few things out for some time now and up > until now I have been hearing contradicting voices wherever I > turn myself. > I would like to know what are values of ApplicationID set in > messages - Base messages used in context of Sh interface to > Authanticate/Authorize user? > > Lets consider flow like follows (not sure if its valid or not): > > > > > CLIENT > > SERVER(HSS ?) > | ------------- UDR -----------------> > | SesssionId_1, AppId_1 ==Sh > X > | <----------- RAR ------------------- > | SessionId_2, AppId_2= Base > | ------------- RAA -----------------> > | SessionId_2, AppId_2= Base > | ------------- UDR -----------------> > | SesssionId_1, AppId_1 ==Sh > | <----------- UDA -------------------- > | SesssionId_1, AppId_1 ==Sh > > > Does X indicates UDA denying access? > Is SessionId_1 equal to SessionId_2? > Is AppId_2== Base or is it equal to AppId_2 ? > > > Thanks > > > > ------------------------------------------------------------------------ > > "DISCLAIMER: This message is proprietary to Aricent and is > intended solely for the use of the individual to whom it is > addressed. It may contain privileged or confidential > information and should not be circulated or used for any > purpose other than for what it is intended. If you have > received this message in error,please notify the originator > immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, > altering, or disclosing the contents of this message. Aricent > accepts no responsibility for loss or damage arising from the > use of the information transmitted by this email including > damage from virus." > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > -- > Bartosz Baranowski > JBoss R & D > ================================== > Word of criticism meant to improve is always step forward. > > > ------------------------------------------------------------------------ > "DISCLAIMER: This message is proprietary to Aricent and is > intended solely for the use of the individual to whom it is > addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than > for what it is intended. If you have received this message in > error,please notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the > contents of this message. Aricent accepts no responsibility for > loss or damage arising from the use of the information transmitted > by this email including damage from virus." > > > > > -- > Bartosz Baranowski > JBoss R & D > ================================== > Word of criticism meant to improve is always step forward. > ------------------------------------------------------------------------ > > _______________________________________________ > 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