From dime-bounces@ietf.org Tue May 01 11:02:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HitsK-0004DD-M3; Tue, 01 May 2007 11:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HitsJ-0004D8-Sh for dime@ietf.org; Tue, 01 May 2007 11:02:43 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HitsJ-0003QY-Az for dime@ietf.org; Tue, 01 May 2007 11:02:43 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 17:02:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 Date: Tue, 1 May 2007 17:02:41 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301D80CFF@SEHAN021MB.tcad.telia.se> In-Reply-To: <000d01c78b61$03ce9fb0$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] MIP6 NAS-HAAA issue #1 Thread-Index: AcdsfuOHC3+c5oNVQU68Yh1z7rQnJAcfP2bwAANYWzAAlaJykAAnKf4g References: <59D7431DE2527D4CB0F1EFEDA5683ED301D80C6A@SEHAN021MB.tcad.telia.se> <000d01c78b61$03ce9fb0$2f01a8c0@china.huawei.com> From: To: , X-OriginalArrivalTime: 01 May 2007 15:02:41.0977 (UTC) FILETIME=[C44FD290:01C78C01] X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Madjid, See some comments inline. > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Sent: Monday, April 30, 2007 10:52 PM > To: Korhonen, Jouni /TeliaSonera Finland Oyj; dime@ietf.org > Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 >=20 > Hi Jouni, >=20 > It is ok to extend the grouped AVP with *[AVP], I guess, but=20 > my point was since we will have a Diameter Mobile IPv6=20 > application (at least for split case), it is easier to call=20 > the attribute what it is: MIP6_Addresses without expanding=20 Well, it is just a name of an AVP. The group is supposed to contain MIP6 related information that might in the future=20 be more than just FQDNs, IPs and refixes. That's why I came up with the MIP6-Info. > its scope rather than including everything that is related to=20 > that application into one AVP. I may need to send Mobile IP6=20 > attributes in an uplink message TO the server, then what?=20 We already send AVPs to uplink. In NAS-HAAA we don't have a new application. Honestly, I really don't see what is the issue here. We have a group because when we send information e.g. about multiple HAs we need to have a clean & nice way of correlating the HAA, its FQDN and possibly other information. A grouped AVP does that. You are free to take an AVP out of the group or add any AVP outside the group.. With *[ AVP ] one can even extend the group in any way, which I think would be good for other SDOs. > As you said your ID scope is confined and you don't want to=20 > and should not deal with all future Mobile IP6 related=20 > attributes that may be defined later. I didn't say I would not want to expand the scope. I am not just sure whether we are allowed to do that. For example I see a lot work already done in NAS-HAAA for the forthcoming PMIP6.=20 > As far as multiple HA and multiple grouped AVPs, I guess that=20 > is fine. Is there a need to indicate how many HA s are=20 > included in the message and whether there is a preference on=20 > which one to pick? I see no reason to add information about the number of HAs. I guess the message parser does good job in that. Preference, hmmm, I would suggest that the order they appear in the message defines the preference. Cheers, Jouni >=20 > R, >=20 > Madjid >=20 > -----Original Message----- > From: jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com] >=20 > Sent: Friday, April 27, 2007 1:42 PM > To: mnakhjiri@huawei.com; dime@ietf.org > Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 >=20 > Hi Madjid,=20 >=20 > > -----Original Message----- > > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > > Sent: 27. huhtikuuta 2007 21:51 > > To: Korhonen, Jouni /TeliaSonera Finland Oyj; dime@ietf.org > > Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 > >=20 > > Hi Jouni, > >=20 > > I have no problem with the general idea of grouped AVP, only a few=20 > > notes regarding the construct: >=20 > Good. >=20 > > 1) calling the AVP MIP6-Info may be a bit problematic,=20 > basically you=20 > > are putting the entire MIP6 application info into one grouped AVP?=20 > > Will we then be able to define this group AVP in a way that any=20 > > possible AVP people come up with to support MIP6 can easily be=20 > > integrated in this AVP? If yes, then no problem. >=20 > Right.. if extending the MIP6-Info is desired we could define it as: >=20 > MIP6-Info ::=3D < AVP Header: xyz > > [ MIP6-Home-Agent-Address ] > [ MIP6-Home-Agent-FQDN ] > [ MIP6-Home-Link-Prefix ] > [ MIP6-Home-Address ] > *[ AVP ] >=20 > > Right now, I can have an idea about a couple of things that can be=20 > > MIP6-info related AVPs and are not shown below. Just call it=20 > > MIP6_HA_info (leave HOA out of it, IMO) or call it=20 > MIP6_ADDR_info and=20 > > leave HOA in. >=20 > There is definitely a lot of stuff that could be put in.. e.g. > in a case when the NAS is co-located with MAG. I am open to=20 > extend the coverage but I am not sure if it is in scope of the ID. >=20 > > 2) Not debating whether or not we should send multiple HA info=20 > > together, The suggested construct does not show how many=20 > HAs there are=20 > > in the AVP. I would guess you would need something to indicate that. >=20 > It is always at most one HA per grouped AVP. If more HAs are=20 > needed, the message just needs to include multiple grouped=20 > MIP6-Info AVPs. >=20 > >=20 > > Hope this helps, >=20 > Cheers, > Jouni >=20 >=20 > >=20 > > Madjid > >=20 > > -----Original Message----- > > From: jouni.korhonen@teliasonera.com > > [mailto:jouni.korhonen@teliasonera.com] > >=20 > > Sent: Thursday, March 22, 2007 5:38 AM > > To: dime@ietf.org > > Subject: [Dime] MIP6 NAS-HAAA issue #1 > >=20 > >=20 > > About the issue #1 presented during the Dime WG meeting. If the=20 > > ASP/NAS needs to send or the MSA needs to return more than one HA=20 > > information the current AVP formulation does not work. > > This is because we have defined AVP counts as "at most one". > > Furthermore, if we are about to allow "zero or more" AVPs=20 > we need to=20 > > have a way to group HA address, FQDN, home link prefix etc=20 > together.=20 > > For that purpose a grouped AVP would be OK. > >=20 > > So the question is (also related to the issue #2) whether "zero or=20 > > more" HAs must be supported. At least the recent discussion in MIP6=20 > > list points to this direction. > >=20 > > Anyway, my personal opinion is that defining a grouped AVP=20 > > does-no-harm anyway. Below is one proposal for a grouped AVP: > >=20 > > MIP6-Info ::=3D < AVP Header: 297 > > > [ MIP6-Home-Agent-Address ] > > [ MIP6-Home-Agent-FQDN ] > > [ MIP6-Home-Link-Prefix ] > > [ MIP6-Home-Address ] > > ... > >=20 > > Any opinions? > >=20 > > Cheers, > > Jouni > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue May 01 15:23:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HixwQ-0005cR-6f; Tue, 01 May 2007 15:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HixwP-0005ak-7T for dime@ietf.org; Tue, 01 May 2007 15:23:13 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HixwM-0003gJ-Nz for dime@ietf.org; Tue, 01 May 2007 15:23:13 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHD00MPKN6L69@usaga01-in.huawei.com> for dime@ietf.org; Tue, 01 May 2007 12:23:10 -0700 (PDT) Received: from N737011 (pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHD006KWN6HM3@usaga01-in.huawei.com> for dime@ietf.org; Tue, 01 May 2007 12:23:09 -0700 (PDT) Date: Tue, 01 May 2007 12:23:10 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 In-reply-to: <59D7431DE2527D4CB0F1EFEDA5683ED301D80CFF@SEHAN021MB.tcad.telia.se> To: jouni.korhonen@teliasonera.com, dime@ietf.org Message-id: <001e01c78c26$2866a550$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdsfuOHC3+c5oNVQU68Yh1z7rQnJAcfP2bwAANYWzAAlaJykAAnKf4gAApKs4A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, I had the Mobile IPv6 split scenario case in mind, when I made the comments about the naming of the attribute. As far as other comments, they are merely suggestions, that is all. R, Madjid -----Original Message----- From: jouni.korhonen@teliasonera.com [mailto:jouni.korhonen@teliasonera.com] Sent: Tuesday, May 01, 2007 8:03 AM To: mnakhjiri@huawei.com; dime@ietf.org Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 Hi Madjid, See some comments inline. > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > Sent: Monday, April 30, 2007 10:52 PM > To: Korhonen, Jouni /TeliaSonera Finland Oyj; dime@ietf.org > Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 > > Hi Jouni, > > It is ok to extend the grouped AVP with *[AVP], I guess, but > my point was since we will have a Diameter Mobile IPv6 > application (at least for split case), it is easier to call > the attribute what it is: MIP6_Addresses without expanding Well, it is just a name of an AVP. The group is supposed to contain MIP6 related information that might in the future be more than just FQDNs, IPs and refixes. That's why I came up with the MIP6-Info. > its scope rather than including everything that is related to > that application into one AVP. I may need to send Mobile IP6 > attributes in an uplink message TO the server, then what? We already send AVPs to uplink. In NAS-HAAA we don't have a new application. Honestly, I really don't see what is the issue here. We have a group because when we send information e.g. about multiple HAs we need to have a clean & nice way of correlating the HAA, its FQDN and possibly other information. A grouped AVP does that. You are free to take an AVP out of the group or add any AVP outside the group.. With *[ AVP ] one can even extend the group in any way, which I think would be good for other SDOs. > As you said your ID scope is confined and you don't want to > and should not deal with all future Mobile IP6 related > attributes that may be defined later. I didn't say I would not want to expand the scope. I am not just sure whether we are allowed to do that. For example I see a lot work already done in NAS-HAAA for the forthcoming PMIP6. > As far as multiple HA and multiple grouped AVPs, I guess that > is fine. Is there a need to indicate how many HA s are > included in the message and whether there is a preference on > which one to pick? I see no reason to add information about the number of HAs. I guess the message parser does good job in that. Preference, hmmm, I would suggest that the order they appear in the message defines the preference. Cheers, Jouni > > R, > > Madjid > > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > > Sent: Friday, April 27, 2007 1:42 PM > To: mnakhjiri@huawei.com; dime@ietf.org > Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 > > Hi Madjid, > > > -----Original Message----- > > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > > Sent: 27. huhtikuuta 2007 21:51 > > To: Korhonen, Jouni /TeliaSonera Finland Oyj; dime@ietf.org > > Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 > > > > Hi Jouni, > > > > I have no problem with the general idea of grouped AVP, only a few > > notes regarding the construct: > > Good. > > > 1) calling the AVP MIP6-Info may be a bit problematic, > basically you > > are putting the entire MIP6 application info into one grouped AVP? > > Will we then be able to define this group AVP in a way that any > > possible AVP people come up with to support MIP6 can easily be > > integrated in this AVP? If yes, then no problem. > > Right.. if extending the MIP6-Info is desired we could define it as: > > MIP6-Info ::= < AVP Header: xyz > > [ MIP6-Home-Agent-Address ] > [ MIP6-Home-Agent-FQDN ] > [ MIP6-Home-Link-Prefix ] > [ MIP6-Home-Address ] > *[ AVP ] > > > Right now, I can have an idea about a couple of things that can be > > MIP6-info related AVPs and are not shown below. Just call it > > MIP6_HA_info (leave HOA out of it, IMO) or call it > MIP6_ADDR_info and > > leave HOA in. > > There is definitely a lot of stuff that could be put in.. e.g. > in a case when the NAS is co-located with MAG. I am open to > extend the coverage but I am not sure if it is in scope of the ID. > > > 2) Not debating whether or not we should send multiple HA info > > together, The suggested construct does not show how many > HAs there are > > in the AVP. I would guess you would need something to indicate that. > > It is always at most one HA per grouped AVP. If more HAs are > needed, the message just needs to include multiple grouped > MIP6-Info AVPs. > > > > > Hope this helps, > > Cheers, > Jouni > > > > > > Madjid > > > > -----Original Message----- > > From: jouni.korhonen@teliasonera.com > > [mailto:jouni.korhonen@teliasonera.com] > > > > Sent: Thursday, March 22, 2007 5:38 AM > > To: dime@ietf.org > > Subject: [Dime] MIP6 NAS-HAAA issue #1 > > > > > > About the issue #1 presented during the Dime WG meeting. If the > > ASP/NAS needs to send or the MSA needs to return more than one HA > > information the current AVP formulation does not work. > > This is because we have defined AVP counts as "at most one". > > Furthermore, if we are about to allow "zero or more" AVPs > we need to > > have a way to group HA address, FQDN, home link prefix etc > together. > > For that purpose a grouped AVP would be OK. > > > > So the question is (also related to the issue #2) whether "zero or > > more" HAs must be supported. At least the recent discussion in MIP6 > > list points to this direction. > > > > Anyway, my personal opinion is that defining a grouped AVP > > does-no-harm anyway. Below is one proposal for a grouped AVP: > > > > MIP6-Info ::= < AVP Header: 297 > > > [ MIP6-Home-Agent-Address ] > > [ MIP6-Home-Agent-FQDN ] > > [ MIP6-Home-Link-Prefix ] > > [ MIP6-Home-Address ] > > ... > > > > Any opinions? > > > > Cheers, > > Jouni > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 02 17:30:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjMPZ-0000zB-Fq; Wed, 02 May 2007 17:30:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjMPY-0000ve-0p for dime@ietf.org; Wed, 02 May 2007 17:30:56 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjMPW-0004mU-Ph for dime@ietf.org; Wed, 02 May 2007 17:30:56 -0400 Received: from sonusmail01.sonusnet.com (sonusmail01.sonusnet.com [10.128.32.75]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l42LUpvf031483 for ; Wed, 2 May 2007 17:30:51 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 May 2007 17:30:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 May 2007 17:30:50 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702E011@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments for draft-fajardo-dime-app-design-guide-02.txt Thread-Index: AceNASfGTP5NsTInR0+eSfdibLJcNw== From: "Asveren, Tolga" To: X-OriginalArrivalTime: 02 May 2007 21:30:51.0240 (UTC) FILETIME=[28351680:01C78D01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Dime] Comments for draft-fajardo-dime-app-design-guide-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I read through the last version of Application Design Guidelines draft. Here are my comments: 1)It could be a good idea to give a description of "mandatory AVP". I propose to use the following terminology: mandatory AVP: An AVP with M-bit set. A mandatory AVP has to be understood and processed by its receiver. 2) 4.1 "This means that the M-bit is set and the AVP(s) is required to exist in command ABNF." I think even if the AVP is not required to exist in the command ABNF, i.e. it is optional, it still changes the semantics of an existing application. If it is received (it can be received because it is optional on command ABNF), it has to be understood and processed. IMHO, "and the AVP(s) is required to exist in command ABNF" should be removed. This interpretation already caused some confusion/damage in 3GPP Rf/Ro interfaces. There are a bunch of AVPs with M-bit defined for these interfaces. They are defined as optional in command ABNFs and Rf/Ro are reusing Accounting/DCCA Application Ids. I don't think a vanilla DCCA server can handle CCRs for Ro interface. IMHO, Ro and Rf should have used new application Ids. 3) I propose that we add the following items to the 5.9 system Architecture and Deployment: o Applications are encouraged to define their own application layer timers to guard against requests not being delivered to the final destination due to the transport errors. Relying on base protocol timer Tw for that purpose may be problematic because Tw is a hop-by-hop timer and its provisioning through the whole path may not be under the control of the administrative entity operating originator of the request. Furthermore, applications may have different characteristics regarding timeout values to determine a non-delivery of a request. o Applications should specify any AVP, which could be used for duplicate detection and how these could be used for that purpose. This could help to ease duplicate detection process for certain cases.=20 Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 02 18:10:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjN2H-0001oc-Bs; Wed, 02 May 2007 18:10:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjN2G-0001oX-EM for dime@ietf.org; Wed, 02 May 2007 18:10:56 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjN2F-0005vh-1m for dime@ietf.org; Wed, 02 May 2007 18:10:56 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l42MATKE066588; Wed, 2 May 2007 18:10:30 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46390C55.9000208@tari.toshiba.com> Date: Wed, 02 May 2007 18:10:29 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Comments for draft-fajardo-dime-app-design-guide-02.txt References: <033458F56EC2A64E8D2D7B759FA3E7E702E011@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E702E011@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, > 1)It could be a good idea to give a description of "mandatory AVP". I > propose to use the following terminology: > mandatory AVP: An AVP with M-bit set. A mandatory AVP has to be > understood and processed by its receiver. > Ok. How about in Sec 4.1 we re-phrase the first few sentence of the paragraph: " The rules are strict in the case where the AVP(s) to be added is mandatory to be understood and interpreted. This means that the M-bit is set and the AVP(s) is required to exist in command ABNF. Note that this mandatory AVP rule applies to AVP(s) that either ...... " to: " The rules are strict in the case where the AVP(s) to be added is mandatory. As defined in [1], a mandatory AVP is an AVP that has its M-bit flag set which requires a receiver to understand, correctly interpret and process the AVP when it is present in a message. This rule is independent of whether the AVP is defined as required or optional to exist in a message. As long as the AVP is to be added to a messages' ABNF then this rule will apply. Note that this mandatory AVP rule applies to AVP(s) that either ...... " > > 2) 4.1 > "This means that the M-bit is set and the AVP(s) is required to exist in > command ABNF." > I think even if the AVP is not required to exist in the command ABNF, > i.e. it is optional, it still changes the semantics of an existing > application. If it is received (it can be received because it is > optional on command ABNF), it has to be understood and processed. IMHO, > "and the AVP(s) is required to exist in command ABNF" should be removed. > Ok. The changes above should cover this as well. > 3) I propose that we add the following items to the 5.9 system > Architecture and Deployment: > > o Applications are encouraged to define their own application layer > timers to guard against requests not being delivered to the final > destination due to the transport errors. Relying on base protocol timer > Tw for that purpose may be problematic because Tw is a hop-by-hop timer > and its provisioning through the whole path may not be under the control > of the administrative entity operating originator of the request. > Furthermore, applications may have different characteristics regarding > timeout values to determine a non-delivery of a request. > The last bullet point in Sec 5.9 might also covers this item. Do you wish to have a more specific recommendation for timers ? If so, we can re-focus the exiting item. > o Applications should specify any AVP, which could be used for duplicate > detection and how these could be used for that purpose. This could help > to ease duplicate detection process for certain cases. > Ok. Some editorial changes: " Applications should specify AVPs which could be used to further aid in duplication detection. [Can you add the case here to provide an example ?] It is recommended that these AVPs be used only for this purpose. " regards, victor > Thanks, > Tolga > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 03 10:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjchp-0000Gc-Dn; Thu, 03 May 2007 10:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjchj-0008Rn-Fh for dime@ietf.org; Thu, 03 May 2007 10:54:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjcZc-0002NM-SW for dime@ietf.org; Thu, 03 May 2007 10:46:25 -0400 Received: (qmail invoked by alias); 03 May 2007 14:46:24 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp034) with SMTP; 03 May 2007 16:46:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1833esgn+g33VVZ1x7RGR4umoWvPGvQXhuESH2k4b dxUF2wVAq6kOUu Message-ID: <4639F5BB.3080403@gmx.net> Date: Thu, 03 May 2007 16:46:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Dime] Diameter Mobility: Status Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, here is a short status update of the Diameter mobility work. We are currently in the progress of updating the draft. Some of you have already provided feedback on individual items. More feedback is, however, appreciated. Diameter Mobile IPv6: NAS <-> HAAA Support ------------------------------------------ http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-03.txt The following changes will be made to the document: Issue 1: Come up with a new revision that has the grouped AVP based on http://www1.ietf.org/mail-archive/web/dime/current/msg01384.html Issue 2: Add a capability AVP for local HA assignment http://www1.ietf.org/mail-archive/web/dime/current/msg01383.html Issue 3: Address Kuntal's concern on NASes that are not able to perform DNS query via indicating it in capability AVP. Diameter Mobile IPv6: HA-to-AAAH support ---------------------------------------- http://tools.ietf.org/html/draft-ietf-dime-mip6-split-01 The following changes will be made to the document: Issue A: Moving forward with one Application for Authn and Authz Based on the recent consensus call, the WG agree to move with this. Yoshi is ok with moving in this direction. Issue B: One or two command to support MIP6 Authentication Option as defined in RFC 4285. Julien posted a message regarding this issue: http://www1.ietf.org/mail-archive/web/dime/current/msg01399.html Madjid and Julien are in favor of having one command for EAP-Based and One command for RFC 4285-based authentication. ACTION ITEM: WG members are invited to respond to the issue and to express their preference. Issue C: How does the HA know if IKEv2 is used for VPN access or MIP6 service? Out-of scope of the document. However, we agree to add some text on this. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 03 12:44:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjeQ1-0005vf-Ks; Thu, 03 May 2007 12:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjeQ0-0005vY-Ml for dime@ietf.org; Thu, 03 May 2007 12:44:36 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjeQ0-0002w9-Cj for dime@ietf.org; Thu, 03 May 2007 12:44:36 -0400 Received: from sonusmail01.sonusnet.com (sonusmail01.sonusnet.com [10.128.32.75]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l43GiaDi023642 for ; Thu, 3 May 2007 12:44:36 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 May 2007 12:44:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Comments for draft-fajardo-dime-app-design-guide-02.txt Date: Thu, 3 May 2007 12:44:35 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702E014@sonusmail04.sonusnet.com> In-Reply-To: <46390C55.9000208@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments for draft-fajardo-dime-app-design-guide-02.txt Thread-Index: AceNBsSweKlDFb2FRlWebHIc4mXL8QAmq1MA References: <033458F56EC2A64E8D2D7B759FA3E7E702E011@sonusmail04.sonusnet.com> <46390C55.9000208@tari.toshiba.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 03 May 2007 16:44:36.0100 (UTC) FILETIME=[55707440:01C78DA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, May 02, 2007 6:10 PM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: Re: [Dime] Comments for draft-fajardo-dime-app-design-guide- > 02.txt >=20 > Hi Tolga, >=20 > > 1)It could be a good idea to give a description of "mandatory AVP". I > > propose to use the following terminology: > > mandatory AVP: An AVP with M-bit set. A mandatory AVP has to be > > understood and processed by its receiver. > > >=20 > Ok. How about in Sec 4.1 we re-phrase the first few sentence of the > paragraph: >=20 > " > The rules are strict in the case where the AVP(s) to be added is > mandatory to be understood and interpreted. This means that the > M-bit is set and the AVP(s) is required to exist in command ABNF. > Note that this mandatory AVP rule applies to AVP(s) that either > ...... > " >=20 > to: >=20 > " > The rules are strict in the case where the AVP(s) to be added is > mandatory. As defined in [1], a mandatory AVP is an AVP that has its > M-bit flag set which requires a receiver to understand, correctly > interpret and process the AVP when it is present in a message. > This rule is independent of whether the AVP is defined as required > or optional to exist in a message. As long as the AVP is to be added > to a messages' ABNF then this rule will apply. >=20 > Note that this mandatory AVP rule applies to AVP(s) that either > ...... > " >=20 >=20 > > > > 2) 4.1 > > "This means that the M-bit is set and the AVP(s) is required to exist in > > command ABNF." > > I think even if the AVP is not required to exist in the command ABNF, > > i.e. it is optional, it still changes the semantics of an existing > > application. If it is received (it can be received because it is > > optional on command ABNF), it has to be understood and processed. IMHO, > > "and the AVP(s) is required to exist in command ABNF" should be removed. > > >=20 >=20 > Ok. The changes above should cover this as well. [TOLGA]That sounds good to me. >=20 >=20 > > 3) I propose that we add the following items to the 5.9 system > > Architecture and Deployment: > > > > o Applications are encouraged to define their own application layer > > timers to guard against requests not being delivered to the final > > destination due to the transport errors. Relying on base protocol timer > > Tw for that purpose may be problematic because Tw is a hop-by-hop timer > > and its provisioning through the whole path may not be under the control > > of the administrative entity operating originator of the request. > > Furthermore, applications may have different characteristics regarding > > timeout values to determine a non-delivery of a request. [TOLGA]Yes you are right. I should have read it more carefully. Current text covers this well. > > >=20 >=20 > The last bullet point in Sec 5.9 might also covers this item. Do you > wish to have a more specific recommendation for timers ? If so, we can > re-focus the exiting item. >=20 >=20 > > o Applications should specify any AVP, which could be used for duplicate > > detection and how these could be used for that purpose. This could help > > to ease duplicate detection process for certain cases. > > >=20 >=20 > Ok. Some editorial changes: >=20 > " > Applications should specify AVPs which could be used to further aid in > duplication > detection. [Can you add the case here to provide an example ?] It is > recommended > that these AVPs be used only for this purpose. > " [TOLGA]Example: Possible use of Session-Id and CC-Request-Number AVPs for duplicate detection purposes in certain cases by DCCA >=20 >=20 > regards, > victor >=20 > > Thanks, > > Tolga > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 03 18:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjk8M-0006Tr-K0; Thu, 03 May 2007 18:50:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjk89-00062W-8y; Thu, 03 May 2007 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hjk88-0004O6-U7; Thu, 03 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B6CC817625; Thu, 3 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hjk7e-00062F-Ck; Thu, 03 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 03 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-split-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --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: HA <-> HAAA Support Author(s) : J. Bournelle, et al. Filename : draft-ietf-dime-mip6-split-02.txt Pages : 15 Date : 2007-5-3 In a Mobile IPv6 deployment the need for an interaction between the Home Agent, the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA) has been identified. This document describes a new Diameter application, called Mobile IPv6 Authorization Application, used in conjunction with the Diameter EAP Application is used to perform the necessary AAA functions before executing Mobile IPv6 services. This document also specifies the role of the Home Agent as part of the AAA infrastructure supporting the Diameter Mobile IPv6 Authorization Application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-split-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-split-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-3163928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-3163928.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Fri May 04 07:19:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjvom-0005Ny-Jt; Fri, 04 May 2007 07:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjvol-0005Nt-Rw for dime@ietf.org; Fri, 04 May 2007 07:19:19 -0400 Received: from gws04.hcl.in ([203.105.186.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjvoj-0001nN-A8 for dime@ietf.org; Fri, 04 May 2007 07:19:19 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 365AA36009F; Fri, 4 May 2007 16:48:20 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid 190383600BD; Fri, 4 May 2007 16:48:20 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 16:49:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 May 2007 16:49:06 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6013AA2AA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Doubt regarding RTR message flow. Thread-Index: AceOPaRQ/hQH9Hz5RK6PIYJHC0xilQAAF1Qw From: "Balamurugan T, TLS-Chennai" To: , X-OriginalArrivalTime: 04 May 2007 11:19:13.0355 (UTC) FILETIME=[0B63B9B0:01C78E3E] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-14.3434 TC:1F TRN:43 TV:3.6.1039(15154.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Type: multipart/mixed; boundary="=_Boundary_r4GS0fF9Pre3iH6kRxyT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Subject: [Dime] Doubt regarding RTR message flow. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --=_Boundary_r4GS0fF9Pre3iH6kRxyT Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Doubt regarding RTR message flow.

Hi All,

    We need some clarification regarding RTR message flow in = CX/Dx application. According to RFC 3588 the Auth server
    stateless fsm  receives all service specific requests and = responding with answer. No outgoing messages from stateless = server.

    But Cx/Dx interface = specification  3GPP TS 29.228 V7.2.0 says RTR = should be sent from HSS to S-CSCF. Here the HSS is

    a server component. Also the RTR flows = from Auth stateful/stateless server is not available in diameter base RFC.

    The doubt here is which component will send = RTR first ...Auth server or Auth client?.
    If it is from Auth state less server = what   are the action functionalities to be done for = implementation
    of auth server stateless FSM .

Thanks & = Regards,
Bala
  

    =

--=_Boundary_r4GS0fF9Pre3iH6kRxyT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- --=_Boundary_r4GS0fF9Pre3iH6kRxyT Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --=_Boundary_r4GS0fF9Pre3iH6kRxyT-- From dime-bounces@ietf.org Fri May 04 08:40:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjx55-0005EN-EW; Fri, 04 May 2007 08:40:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjx54-0005EH-N8 for dime@ietf.org; Fri, 04 May 2007 08:40:14 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjx53-0005PX-Ee for dime@ietf.org; Fri, 04 May 2007 08:40:14 -0400 Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l44CeDTS016838 for ; Fri, 4 May 2007 08:40:13 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 08:40:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Doubt regarding RTR message flow. Date: Fri, 4 May 2007 08:40:12 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702E018@sonusmail04.sonusnet.com> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6013AA2AA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Doubt regarding RTR message flow. Thread-Index: AceOPaRQ/hQH9Hz5RK6PIYJHC0xilQAAF1QwAAJjtgA= References: <66E8AEE9980BB44CA5FCAD39EBA56AC6013AA2AA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 04 May 2007 12:40:12.0843 (UTC) FILETIME=[5BDEBFB0:01C78E49] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Bala, I think this is more a 3GPP issue rather than Dime but: Like you have said, RTR is sent from HSS to S-CSCF. It seems decoupled = from UAR/UAA exchange from Diameter sessions point of view (the session = for UAR/UAA exchange is over after the answer is sent). So, RTR/RTA = exchange will constitute a new Diameter session. In the context of this = second session, you can think HSS as the client and S-CSCF as the = server. In any case, this is a separate session than the first one, = which seems to be inline with the authentication session state machine = in RFC3588. AFAICS, there is no equivalent for RTR/RTA session in = RFC3588, it simply is something different. It seems 3GPP wants to use both a stateless approach (from Diameter = session perspective) but still wants have the capability to terminate = the service from server, hence they have RTR. Overall, if you stick to descriptions in 3GPP documents, you shouldn't = have problems from implementation point of view. They refer to RFCs = whenever necessary. Thanks, Tolga ________________________________________ From: Balamurugan T, TLS-Chennai [mailto:tbalamurugan@hcl.in]=20 Sent: Friday, May 04, 2007 7:19 AM To: dime@ietf.org; diameter-developers@lists.sourceforge.net Subject: [Dime] Doubt regarding RTR message flow. Hi All,=20 =A0 =A0 We need some clarification regarding RTR message flow in CX/Dx = application. According to RFC 3588 the Auth server=20 =A0=A0=A0 stateless fsm=A0 receives all service specific requests and = responding with answer. No outgoing messages from stateless server. =A0=A0=A0 But Cx/Dx interface specification=A0 3GPP TS 29.228 V7.2.0 = says RTR should be sent from HSS to S-CSCF. Here the HSS is=20 =A0=A0=A0 a server component. Also the RTR flows from Auth = stateful/stateless server is not available in diameter base RFC.=20 =A0=A0=A0 The doubt here is which component will send RTR first ...Auth = server or Auth client?.=20 =A0=A0=A0 If it is from Auth state less server what=A0=A0 are the action = functionalities to be done for implementation=20 =A0=A0=A0 of auth server stateless FSM .=20 Thanks & Regards,=20 Bala=20 =A0=A0=20 =A0=A0=A0=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 07 03:18:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkxU0-0002LN-Um; Mon, 07 May 2007 03:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkxTz-0002LI-KJ for dime@ietf.org; Mon, 07 May 2007 03:18:07 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkxTy-0006eE-6r for dime@ietf.org; Mon, 07 May 2007 03:18:07 -0400 Received: (qmail invoked by alias); 07 May 2007 07:18:05 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp038) with SMTP; 07 May 2007 09:18:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+fWuc7MCif0rFwGKnovA4w73E9ID52JQU1HuDyJf T393kuWPagPLwV Message-ID: <463ED2AA.6030403@gmx.net> Date: Mon, 07 May 2007 09:18:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Dime] [Fwd: Diameter QoS: Feedback ] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org -- Here is a review by Victor Ciao Hannes -------------------- Hannes, >> Victor: Could you check the Diameter QoS approach against the >> suggestions / guidelines for Diameter Application Design Guidelines >> draft? Sorry for the late reply. I did a quick review and my comments are as follows: a. QAR/QAA and QIR/QAA seems to be straight forward in terms of app-id and avp assignments and structure. One minor item in 8.2, QoS info is said to be "MUST carry" type information but the ABNF has all of the Qos avp as optional. It maybe better to clearly define the meaning of their presence/absence in case some other SDOs decide to reuse these messages and we end up having dual or overlapping meaning with other optional avps. b. ACR/ACA ABNF definition also has optional avps for "MUST carry" type information same as (a) above. Carrying this avps as "required to exist" will also solidify justification of NOT using base accounting. c. In Sec 6, STR/STA, ASR/ASA, and RAR/RAA commands must carry the app-id of diameter QoS and not zero(0); I think all messages in diameter Qos should carry the app-id of diameter Qos, including ACR/ACA. d. For Qos accounting, it may also be beneficial to refer to the "Coupled Accounting Service" model defined in Sec 9.3 of 3588bis. Note that when using this model, we assume that the accounting messages will most likely be routed towards the Authorizing entity. If this is the intent then it probably works well since your trying to co-relate Qos signaling session, diameter session and application session anyway. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 07 03:34:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkxjP-0002JT-3s; Mon, 07 May 2007 03:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkxjO-0002JO-M9 for dime@ietf.org; Mon, 07 May 2007 03:34:02 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkxjN-0000kY-8v for dime@ietf.org; Mon, 07 May 2007 03:34:02 -0400 Received: (qmail invoked by alias); 07 May 2007 07:33:58 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 07 May 2007 09:33:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ynoRv/aWyJtxSkmpmMDrVv1g1Nt9rLMq1aaf48H U88wFnPqgdDRsQ Message-ID: <463ED665.9020004@gmx.net> Date: Mon, 07 May 2007 09:33:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Punz, Gottfried" Subject: [Dime] draft-ietf-dime-mip6-integrated-03.txt Feedback X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, I asked Gottfried Punz, a co-worker of mine and a long-time 3GPP participant, to review our Diameter Mobility documents. With respect to draft-ietf-dime-mip6-integrated-03.txt he responded: " Unfortunately I could not understand this draft fully, and I fear this will be the same with other SA2 delegates. I understand that the target is to bootstrap MIPv6 via AAA procedures. But there is no simple depiction of messages flows. Rather it is a jump start into commands, AVPs, etc. Section 6, on the other hand, presents 3 scenarios rudimentarily in the very special nomenclature of this draft(s); it would be better for our purposes to see an overall procedure, i.e. a complete attach or HO procedure. I think chapter 3 should be reworked with general message names, and chapter 6 could then show how they map onto concrete messages names, after defining them in chapter 4. " Maybe we should check our documents for readability since we cannot assume that everyone has followed the MIP6 working group discussions on MIPv6 bootstrapping the last few years. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 07 16:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl9hh-0006r3-42; Mon, 07 May 2007 16:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl9hg-0006qv-5D for dime@ietf.org; Mon, 07 May 2007 16:21:04 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hl9hd-0000oK-NT for dime@ietf.org; Mon, 07 May 2007 16:21:04 -0400 Received: (qmail invoked by alias); 07 May 2007 20:21:00 -0000 Received: from p54985C23.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.92.35] by mail.gmx.net (mp041) with SMTP; 07 May 2007 22:21:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/livNy+yjlcjd/7tLQC50GuoKBvV2OtJ3c6bDdoQ unsinBJbfyQskn Message-ID: <463F8A2B.9080906@gmx.net> Date: Mon, 07 May 2007 22:20:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Dime] Making decisions regarding QoS Work X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, working on the WG status update I noticed that we are behind schedule with our Diameter QoS work and subsequently I have had a chat with Dan about this subject. At the last IETF meeting we had a presentation regarding recently submitted QoS documents (see http://www1.ietf.org/mail-archive/web/dime/current/msg01338.html). In short, we made a document management action by splitting the work into: 1) Quality of Service Parameters http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-parameters-00.txt This document just describes the different QoS parameters. 2) Quality of Service Attribute http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attributes-00.txt This document redefines the QoS-Filter-Rule AVP based on the previously mentioned QoS parameters. It needs to be aligned with http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.txt as that document progresses. This is a short document. 3) Quality of Service Application This document describes the Diameter QoS application. Document #2 (and therefore document #1) is needed by the 3GPP for Rel.7 (from a functionality point of view although the current reference points to the Diameter QoS application draft). Hence, there is a considerable amount of pressure to get the work done. #3 needs more work particularly with respect to question (c) below. We need to make three decisions in order to move the work forward. a) Are there objections to turn draft-korhonen-dime-qos-parameters-00.txt into a WG item? b) Are there objections to turn draft-korhonen-dime-qos-attributes-00.txt into a WG item? c) What content from http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requirements-01 should be incorporated into http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 and pushed to future work? Please respond to (a), (b) and/or (c) by 19th May 2007. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 07 17:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlAUB-0003kU-Ge; Mon, 07 May 2007 17:11:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlAU9-0003i5-H9 for dime@ietf.org; Mon, 07 May 2007 17:11:09 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlAU8-0008Pl-1k for dime@ietf.org; Mon, 07 May 2007 17:11:09 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 726AC90014 for ; Mon, 7 May 2007 17:11:02 -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 25395-13 for ; Mon, 7 May 2007 17:10:57 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 7 May 2007 17:10:57 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 17:10:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] draft-ietf-dime-mip6-integrated-03.txt Feedback Date: Mon, 7 May 2007 17:10:57 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9F91@exchtewks2.starentnetworks.com> In-Reply-To: <463ED665.9020004@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-mip6-integrated-03.txt Feedback Thread-Index: AceQehz/NpYqq0vtR8y64q8/VWI7AwAb6Uow From: "Chowdhury, Kuntal" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 07 May 2007 21:10:57.0572 (UTC) FILETIME=[34CA8E40:01C790EC] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Punz, Gottfried" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, I think understanding of the mip6 bootstrapping scenario as a whole and the relevant solutions (split/integrated) require some background reading. Perhaps start from the mip6 bootstrap ps document and review of the bootstrap solutions documents will provide better understanding of the parts of the solution such as this nas-haaa diameter part. The AAA goals document is a good reference as well. -Kuntal > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, May 07, 2007 2:34 AM > To: dime@ietf.org > Cc: Punz, Gottfried > Subject: [Dime] draft-ietf-dime-mip6-integrated-03.txt Feedback >=20 > Hi all, >=20 > I asked Gottfried Punz, a co-worker of mine and a long-time 3GPP > participant, to review our Diameter Mobility documents. > With respect to draft-ietf-dime-mip6-integrated-03.txt he responded: >=20 > " > Unfortunately I could not understand this draft fully, and I fear this > will be the same with other SA2 delegates. >=20 > I understand that the target is to bootstrap MIPv6 via AAA procedures. > But there is no simple depiction of messages flows. >=20 > Rather it is a jump start into commands, AVPs, etc. Section 6, on the > other hand, presents 3 scenarios rudimentarily in the very special > nomenclature of this draft(s); it would be better for our purposes to > see an overall procedure, i.e. a complete attach or HO procedure. I > think chapter 3 should be reworked with general message names, and > chapter 6 could then show how they map onto concrete messages names, > after defining them in chapter 4. > " >=20 > Maybe we should check our documents for readability since we cannot > assume that everyone has followed the MIP6 working group discussions on > MIPv6 bootstrapping the last few years. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue May 08 04:15:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlKqo-0007h7-37; Tue, 08 May 2007 04:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlKqm-0007gs-Rf for dime@ietf.org; Tue, 08 May 2007 04:15:12 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HlKql-0004mJ-JC for dime@ietf.org; Tue, 08 May 2007 04:15:12 -0400 Received: (qmail invoked by alias); 08 May 2007 08:15:08 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp047) with SMTP; 08 May 2007 10:15:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18lWFJr2/8lqD+JfMMX/V7LJYa5GH+qeGKM9/3tMI EN+GCq4C6NbTej Message-ID: <4640318A.1070404@gmx.net> Date: Tue, 08 May 2007 10:15:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Dime] DIME WG Status Update (May 2007) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all here the status update for this month: http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue May 08 23:46:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hld85-0000TK-EL; Tue, 08 May 2007 23:46:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hld83-0000TE-Kg for dime@ietf.org; Tue, 08 May 2007 23:46:15 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hld83-0004gf-5n for dime@ietf.org; Tue, 08 May 2007 23:46:15 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 05:46:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Making decisions regarding QoS Work Date: Wed, 9 May 2007 05:46:06 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301D81098@SEHAN021MB.tcad.telia.se> In-Reply-To: <463F8A2B.9080906@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Making decisions regarding QoS Work Thread-Index: AceQ5Ug7g54oA2YcSBiwcLgsaXGBAABAC1uw References: <463F8A2B.9080906@gmx.net> From: To: , X-OriginalArrivalTime: 09 May 2007 03:46:13.0318 (UTC) FILETIME=[96E3F660:01C791EC] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Having my own vested interests on these I support having a) & b) as WG items. No comment on c) yet. Cheers, Jouni > Hi all, >=20 > working on the WG status update I noticed that we are behind=20 > schedule with our Diameter QoS work and subsequently I have=20 > had a chat with Dan about this subject. >=20 > At the last IETF meeting we had a presentation regarding=20 > recently submitted QoS documents (see=20 > http://www1.ietf.org/mail-archive/web/dime/current/msg01338.ht > ml). In short, we made a document management action by=20 > splitting the work into: >=20 > 1) Quality of Service Parameters > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-paramete > rs-00.txt >=20 > This document just describes the different QoS parameters. >=20 >=20 > 2) Quality of Service Attribute > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attribut > es-00.txt >=20 > This document redefines the QoS-Filter-Rule AVP based on the=20 > previously mentioned QoS parameters. It needs to be aligned=20 > with=20 > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-r > ules-02.txt > as that document progresses. This is a short document. >=20 >=20 > 3) Quality of Service Application >=20 > This document describes the Diameter QoS application. >=20 >=20 > Document #2 (and therefore document #1) is needed by the 3GPP=20 > for Rel.7 (from a functionality point of view although the=20 > current reference points to the Diameter QoS application=20 > draft). Hence, there is a considerable amount of pressure to=20 > get the work done. #3 needs more work particularly with=20 > respect to question (c) below. >=20 > We need to make three decisions in order to move the work forward. >=20 > a) Are there objections to turn > draft-korhonen-dime-qos-parameters-00.txt into a WG item? >=20 > b) Are there objections to turn > draft-korhonen-dime-qos-attributes-00.txt into a WG item? >=20 > c) What content from > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-co > ntrol-requirements-01 > should be incorporated into > http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00=20 > and pushed to future work? >=20 > Please respond to (a), (b) and/or (c) by 19th May 2007. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 09 06:05:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlj30-0006bd-QS; Wed, 09 May 2007 06:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlj2z-0006bY-Us for dime@ietf.org; Wed, 09 May 2007 06:05:25 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlj2z-0007h2-CC for dime@ietf.org; Wed, 09 May 2007 06:05:25 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHR0023FQNKVJ@szxga02-in.huawei.com> for dime@ietf.org; Wed, 09 May 2007 18:04:32 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JHR0007AQNJPH@szxga02-in.huawei.com> for dime@ietf.org; Wed, 09 May 2007 18:04:32 +0800 (CST) Received: from z24109a ([10.70.76.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHR00GGEQNJTC@szxml03-in.huawei.com> for dime@ietf.org; Wed, 09 May 2007 18:04:31 +0800 (CST) Date: Wed, 09 May 2007 18:04:31 +0800 From: Tina TSOU Subject: Re: [Dime] Making decisions regarding QoS Work To: dime@ietf.org, Hannes.Tschofenig@gmx.net, jouni.korhonen@teliasonera.com Message-id: <011101c79221$7007bd80$514c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <463F8A2B.9080906@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED301D81098@SEHAN021MB.tcad.telia.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, c) I think the following from Sun's draft could be moved to the QoS draft: (1) 2.2 Resource Control models which give an overview of push & pull models (2) 2.4 Functional framework & 2.5 its use cases (3) We need section 3 describing new "server-initiated" commands. However the AVPs need more consideration for e.g. some AVP like QoS-Authorization-Resources to be added? Also PI-Request-Type AVP is unnecessary as the RCDE will use ASR, RAR for terminate, update purposes. (4) Section 4 which describe session initiation, update & termination for push model. This draft implies extending & using the RFC 3588 server state machine at RCDE. But this is not agreed by the WG yet. B. R. Tina +86-755-28972912 (Office) +86-13922884380 (Mobile) Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com ----- Original Message ----- From: To: ; Sent: Wednesday, May 09, 2007 11:46 AM Subject: RE: [Dime] Making decisions regarding QoS Work Hi all, Having my own vested interests on these I support having a) & b) as WG items. No comment on c) yet. Cheers, Jouni > Hi all, > > working on the WG status update I noticed that we are behind > schedule with our Diameter QoS work and subsequently I have > had a chat with Dan about this subject. > > At the last IETF meeting we had a presentation regarding > recently submitted QoS documents (see > http://www1.ietf.org/mail-archive/web/dime/current/msg01338.ht > ml). In short, we made a document management action by > splitting the work into: > > 1) Quality of Service Parameters > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-paramete > rs-00.txt > > This document just describes the different QoS parameters. > > > 2) Quality of Service Attribute > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attribut > es-00.txt > > This document redefines the QoS-Filter-Rule AVP based on the > previously mentioned QoS parameters. It needs to be aligned > with > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-r > ules-02.txt > as that document progresses. This is a short document. > > > 3) Quality of Service Application > > This document describes the Diameter QoS application. > > > Document #2 (and therefore document #1) is needed by the 3GPP > for Rel.7 (from a functionality point of view although the > current reference points to the Diameter QoS application > draft). Hence, there is a considerable amount of pressure to > get the work done. #3 needs more work particularly with > respect to question (c) below. > > We need to make three decisions in order to move the work forward. > > a) Are there objections to turn > draft-korhonen-dime-qos-parameters-00.txt into a WG item? > > b) Are there objections to turn > draft-korhonen-dime-qos-attributes-00.txt into a WG item? > > c) What content from > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-co > ntrol-requirements-01 > should be incorporated into > http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 > and pushed to future work? > > Please respond to (a), (b) and/or (c) by 19th May 2007. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 09 16:50:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlt7P-00070z-La; Wed, 09 May 2007 16:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlt7O-00070s-7l for dime@ietf.org; Wed, 09 May 2007 16:50:38 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlt7M-0008Bi-Qa for dime@ietf.org; Wed, 09 May 2007 16:50:38 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l49KoQWc026344 for ; Wed, 9 May 2007 15:50:36 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 15:50:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Making decisions regarding QoS Work Date: Wed, 9 May 2007 15:50:32 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520837@ILEXC2U01.ndc.lucent.com> In-Reply-To: <011101c79221$7007bd80$514c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Making decisions regarding QoS Work thread-index: AceSIZ209vbM8EFMSyy+KcIy5gjF6AAVXRcg References: <463F8A2B.9080906@gmx.net><59D7431DE2527D4CB0F1EFEDA5683ED301D81098@SEHAN021MB.tcad.telia.se> <011101c79221$7007bd80$514c460a@china.huawei.com> From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 09 May 2007 20:50:33.0798 (UTC) FILETIME=[B030F660:01C7927B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, Concerning the item c) - QoS application, as I commented some time ago, the current draft only covers the NE (e.g. router)/endpoint initiated policy Pull model, however, the Push model in which the QoS attributes are proactively installed by the policy server is not yet addressed.=20 A bunch of network technologies and deployment scenarios are requiring the Push model now, and several SDOs have defined the Push model as a requirement in policy control framework, e.g. ETSI TISPAN, DSL Forum, ITU-T NGN and CableLabs (maybe WiMAX forum), it is also envisaged as the evolution of policy control mechanism since it can mitigate the dependence of the QoS control on the endpoint's capability and simplify the endpoint's implementation.=20 Two options to move forward this QoS application work in my mind: 1) Define a single WG item to cover both Pull and Push models 2) Define two WG items to address Pull and Push model separately I personally prefer to create a single WG item to address both Pull and Push models. Certainly, we need to look into details how to integrate the Resource-control-application ID into the QoS application draft. Cheers, Dong =20 -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Wednesday, May 09, 2007 6:05 AM To: dime@ietf.org; Hannes.Tschofenig@gmx.net; jouni.korhonen@teliasonera.com Subject: Re: [Dime] Making decisions regarding QoS Work Hi all, c) I think the following from Sun's draft could be moved to the QoS draft: (1) 2.2 Resource Control models which give an overview of push & pull models (2) 2.4 Functional framework & 2.5 its use cases (3) We need section 3 describing new "server-initiated" commands. However the AVPs need more consideration for e.g. some AVP like QoS-Authorization-Resources to be added? Also PI-Request-Type AVP is unnecessary as the RCDE will use ASR, RAR for terminate, update purposes. (4) Section 4 which describe session initiation, update & termination for push model. This draft implies extending & using the RFC 3588 server state machine at RCDE. But this is not agreed by the WG yet. B. R. Tina +86-755-28972912 (Office) +86-13922884380 (Mobile) Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com ----- Original Message ----- From: To: ; Sent: Wednesday, May 09, 2007 11:46 AM Subject: RE: [Dime] Making decisions regarding QoS Work Hi all, Having my own vested interests on these I support having a) & b) as WG items. No comment on c) yet. Cheers, Jouni > Hi all, > > working on the WG status update I noticed that we are behind > schedule with our Diameter QoS work and subsequently I have > had a chat with Dan about this subject. > > At the last IETF meeting we had a presentation regarding > recently submitted QoS documents (see > http://www1.ietf.org/mail-archive/web/dime/current/msg01338.ht > ml). In short, we made a document management action by > splitting the work into: > > 1) Quality of Service Parameters > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-paramete > rs-00.txt > > This document just describes the different QoS parameters. > > > 2) Quality of Service Attribute > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attribut > es-00.txt > > This document redefines the QoS-Filter-Rule AVP based on the > previously mentioned QoS parameters. It needs to be aligned > with > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-r > ules-02.txt > as that document progresses. This is a short document. > > > 3) Quality of Service Application > > This document describes the Diameter QoS application. > > > Document #2 (and therefore document #1) is needed by the 3GPP > for Rel.7 (from a functionality point of view although the > current reference points to the Diameter QoS application > draft). Hence, there is a considerable amount of pressure to > get the work done. #3 needs more work particularly with > respect to question (c) below. > > We need to make three decisions in order to move the work forward. > > a) Are there objections to turn > draft-korhonen-dime-qos-parameters-00.txt into a WG item? > > b) Are there objections to turn > draft-korhonen-dime-qos-attributes-00.txt into a WG item? > > c) What content from > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-co > ntrol-requirements-01 > should be incorporated into > http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 > and pushed to future work? > > Please respond to (a), (b) and/or (c) by 19th May 2007. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 10 15:14:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmE60-0007rM-44; Thu, 10 May 2007 15:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmE4o-0006T0-3d for dime@ietf.org; Thu, 10 May 2007 15:13:22 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmE0b-0007tj-Bt for dime@ietf.org; Thu, 10 May 2007 15:09:01 -0400 Received: by py-out-1112.google.com with SMTP id f31so559131pyh for ; Thu, 10 May 2007 12:09:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=tLbjs/S9jRCJcgnwbUc6g0lCCFs5f+lOpjiMjCR4uQZYrRtH85x4ZhuQVjuTozdi/pGrH5iKKjn/GglDzHoZO8HvAw4TCOdd+V1XQf+pi4BmSiF0W68l07OlAaQmc5z9ogswbUO+QcLk0T5Idzu588xmNpweUVLGDpuU+8rLUvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=juzgVFqxlGYnJroDUfpxURFDK/zl8keWCSGV5gW8wC53mXc6VTpa1/2Xjy28djiEt9fMX4Pf2T5sB/NthH7F9f03LgVlL0zg+KQwBvpaVXIRiuMQxL3BjULALSq2ODOOs6G7FeLBFYOKZ6gqADxAupi01ZDNtHsT6Ezgrqeb3Ik= Received: by 10.65.181.17 with SMTP id i17mr3834638qbp.1178824140655; Thu, 10 May 2007 12:09:00 -0700 (PDT) Received: by 10.65.177.5 with HTTP; Thu, 10 May 2007 12:09:00 -0700 (PDT) Message-ID: <9b0e41640705101209m2e0024f1n64e1eb9d49c051f@mail.gmail.com> Date: Thu, 10 May 2007 16:09:00 -0300 From: "Christian Esteve" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: ea27f35c839b25cb X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Subject: [Dime] RE: Making decisions regarding QoS Work X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi folks, I support a) and b) as WG items. Regarding c) I am in favor of working towards a combined document addressing the Push and Pull modes of operations.. I would like to see from draft-sun-dime-diameter-resource-control-requirements-01 the implications of end user capabilities and QoS mechanisms of section 2.1. I also agree that we should import the resource control functional framework (AF - resource control PDP - resource PEP) in sections 2.2. and 2.4. The functional framework reflects the architecture evolution trends of the different SDOs (btw. the WiMAX Forum NWG also considers the push model). In this context, I would like to incorporate references to the concrete needs of SDOs, e.g the ITU-T RACF that has the broadest scope of all the SDOs. I am not apelling for a heavy ITU-T-oriented I-D like draft-zhang-nsis-interdomain-qosm-04.txt, but I would like to make sure that the diameter QoS application satisfies evolving SDOs policy-based resource control requirements. In the short term the work around 3GPP is the most time critical and has the most advanced Diameter-based policy and charging control fucntion. My 2 cents. Best regards, Christian On 5/10/07, dime-request@ietf.org wrote: > Send DiME mailing list submissions to > dime@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/dime > or, via email, send a message with subject or body 'help' to > dime-request@ietf.org > > You can reach the person managing the list at > dime-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DiME digest..." > > > Today's Topics: > > 1. RE: Making decisions regarding QoS Work (Sun, Dong (Dong)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 May 2007 15:50:32 -0500 > From: "Sun, Dong \(Dong\)" > Subject: RE: [Dime] Making decisions regarding QoS Work > To: > Message-ID: > <09C9068466B79E4C938DC7737562404D520837@ILEXC2U01.ndc.lucent.com> > Content-Type: text/plain; charset="us-ascii" > > > Hi All, > > Concerning the item c) - QoS application, as I commented some time ago, > the current draft only covers the NE (e.g. router)/endpoint initiated > policy Pull model, however, the Push model in which the QoS attributes > are proactively installed by the policy server is not yet addressed. > > A bunch of network technologies and deployment scenarios are requiring > the Push model now, and several SDOs have defined the Push model as a > requirement in policy control framework, e.g. ETSI TISPAN, DSL Forum, > ITU-T NGN and CableLabs (maybe WiMAX forum), it is also envisaged as the > evolution of policy control mechanism since it can mitigate the > dependence of the QoS control on the endpoint's capability and simplify > the endpoint's implementation. > > Two options to move forward this QoS application work in my mind: > 1) Define a single WG item to cover both Pull and Push models > 2) Define two WG items to address Pull and Push model separately > > I personally prefer to create a single WG item to address both Pull and > Push models. Certainly, we need to look into details how to integrate > the Resource-control-application ID into the QoS application draft. > > Cheers, > Dong > > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Wednesday, May 09, 2007 6:05 AM > To: dime@ietf.org; Hannes.Tschofenig@gmx.net; > jouni.korhonen@teliasonera.com > Subject: Re: [Dime] Making decisions regarding QoS Work > > Hi all, > c) > I think the following from Sun's draft could be moved to the QoS draft: > > (1) 2.2 Resource Control models which give an overview of push & pull > models > (2) 2.4 Functional framework & 2.5 its use cases > (3) We need section 3 describing new "server-initiated" commands. > However the AVPs need more consideration for e.g. some AVP like > QoS-Authorization-Resources to be added? Also PI-Request-Type AVP is > unnecessary as the RCDE will use ASR, RAR for terminate, update > purposes. > (4) Section 4 which describe session initiation, update & termination > for push model. This draft implies extending & using the RFC 3588 server > state machine at RCDE. But this is not agreed by the WG yet. > > B. R. > Tina > +86-755-28972912 (Office) +86-13922884380 (Mobile) > Messengers: > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU > Jabber: > tina@jabber.org Google talk: tinatsou6@gmail.com > > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, May 09, 2007 11:46 AM > Subject: RE: [Dime] Making decisions regarding QoS Work > > > Hi all, > > Having my own vested interests on these I support having > a) & b) as WG items. > > No comment on c) yet. > > Cheers, > Jouni > > > > Hi all, > > > > working on the WG status update I noticed that we are behind > > schedule with our Diameter QoS work and subsequently I have > > had a chat with Dan about this subject. > > > > At the last IETF meeting we had a presentation regarding > > recently submitted QoS documents (see > > http://www1.ietf.org/mail-archive/web/dime/current/msg01338.ht > > ml). In short, we made a document management action by > > splitting the work into: > > > > 1) Quality of Service Parameters > > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-paramete > > rs-00.txt > > > > This document just describes the different QoS parameters. > > > > > > 2) Quality of Service Attribute > > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attribut > > es-00.txt > > > > This document redefines the QoS-Filter-Rule AVP based on the > > previously mentioned QoS parameters. It needs to be aligned > > with > > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-r > > ules-02.txt > > as that document progresses. This is a short document. > > > > > > 3) Quality of Service Application > > > > This document describes the Diameter QoS application. > > > > > > Document #2 (and therefore document #1) is needed by the 3GPP > > for Rel.7 (from a functionality point of view although the > > current reference points to the Diameter QoS application > > draft). Hence, there is a considerable amount of pressure to > > get the work done. #3 needs more work particularly with > > respect to question (c) below. > > > > We need to make three decisions in order to move the work forward. > > > > a) Are there objections to turn > > draft-korhonen-dime-qos-parameters-00.txt into a WG item? > > > > b) Are there objections to turn > > draft-korhonen-dime-qos-attributes-00.txt into a WG item? > > > > c) What content from > > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-co > > ntrol-requirements-01 > > should be incorporated into > > http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 > > and pushed to future work? > > > > Please respond to (a), (b) and/or (c) by 19th May 2007. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > ------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > End of DiME Digest, Vol 17, Issue 8 > *********************************** > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 10 15:50:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEev-000698-RT; Thu, 10 May 2007 15:50:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEen-0005tx-SW; Thu, 10 May 2007 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HmEem-0007nq-ED; Thu, 10 May 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5E45317621; Thu, 10 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HmEeI-0002uo-4T; Thu, 10 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 10 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-app-design-guide-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-00.txt Pages : 16 Date : 2007-5-10 The Diameter Base protocol provides rules on how to extend Diameter and to create new Diameter applications. This is a companion document to clarify these rules. This document does not intended to add, remove or change these rules, rather it helps protocol designers to extend Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-app-design-guide-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-app-design-guide-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-10114822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-app-design-guide-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-10114822.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu May 10 17:23:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmG6I-0005v9-G5; Thu, 10 May 2007 17:23:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmG6H-0005uz-Bl for dime@ietf.org; Thu, 10 May 2007 17:23:01 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmG6E-0002Y8-UX for dime@ietf.org; Thu, 10 May 2007 17:23:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7E0359008C for ; Thu, 10 May 2007 17:22:55 -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 03732-18 for ; Thu, 10 May 2007 17:22:50 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 10 May 2007 17:22:50 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 17:22:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Making decisions regarding QoS Work Date: Thu, 10 May 2007 17:22:49 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9FE1@exchtewks2.starentnetworks.com> In-Reply-To: <463F8A2B.9080906@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Making decisions regarding QoS Work Thread-Index: AceQ5UkEvkUvQ2flRvuzD8QwviYhJgCY+b+g From: "Chowdhury, Kuntal" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 10 May 2007 21:22:50.0167 (UTC) FILETIME=[5CC52C70:01C79349] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Dear Hannes and all, I support making a) and b) WG documents. I need some more time to review and comment on the item c). -Kuntal > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, May 07, 2007 3:21 PM > To: dime@ietf.org > Subject: [Dime] Making decisions regarding QoS Work >=20 > Hi all, >=20 > working on the WG status update I noticed that we are behind schedule > with our Diameter QoS work and subsequently I have had a chat with Dan > about this subject. >=20 > At the last IETF meeting we had a presentation regarding recently > submitted QoS documents (see > http://www1.ietf.org/mail-archive/web/dime/current/msg01338.html). In > short, we made a document management action by splitting the work into: >=20 > 1) Quality of Service Parameters > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-parameters-00.txt >=20 > This document just describes the different QoS parameters. >=20 >=20 > 2) Quality of Service Attribute > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attributes-00.txt >=20 > This document redefines the QoS-Filter-Rule AVP based on the previously > mentioned QoS parameters. It needs to be aligned with > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.tx t > as that document progresses. This is a short document. >=20 >=20 > 3) Quality of Service Application >=20 > This document describes the Diameter QoS application. >=20 >=20 > Document #2 (and therefore document #1) is needed by the 3GPP for Rel.7 > (from a functionality point of view although the current reference > points to the Diameter QoS application draft). Hence, there is a > considerable amount of pressure to get the work done. #3 needs more work > particularly with respect to question (c) below. >=20 > We need to make three decisions in order to move the work forward. >=20 > a) Are there objections to turn > draft-korhonen-dime-qos-parameters-00.txt into a WG item? >=20 > b) Are there objections to turn > draft-korhonen-dime-qos-attributes-00.txt into a WG item? >=20 > c) What content from > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control- > requirements-01 > should be incorporated into > http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 and pushed to > future work? >=20 > Please respond to (a), (b) and/or (c) by 19th May 2007. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue May 15 08:25:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnw5O-0003RC-FO; Tue, 15 May 2007 08:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnw5N-0003R5-EJ for dime@ietf.org; Tue, 15 May 2007 08:25:01 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnw5N-0002N9-4t for dime@ietf.org; Tue, 15 May 2007 08:25:01 -0400 Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l4FCP0cf032164 for ; Tue, 15 May 2007 08:25:00 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 08:25:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Making decisions regarding QoS Work Date: Tue, 15 May 2007 08:24:59 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702E05F@sonusmail04.sonusnet.com> In-Reply-To: <463F8A2B.9080906@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Making decisions regarding QoS Work Thread-Index: AceQ5UbpGTcWXP7ZSbGfYdploFgR4QGBIQGA References: <463F8A2B.9080906@gmx.net> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 15 May 2007 12:25:00.0069 (UTC) FILETIME=[0E5BBD50:01C796EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org a) I think draft-korhonen-dime-qos-parameters-00.txt should be a WG item. b) I have mixed ideas about draft-korhonen-dime-qos-attributes-00.txt. The current document does not provide much information about semantics. >From syntax point of view, I guess even without this document, QoS AVPs could be added to relevant messages, if they have the AVP wildcard. Probably we first need to decide about the scope of this draft. c) AFAICS, although draft-ietf-dime-diameter-qos-00 is defining a generic mechanism, its tone does not provide enough emphasis on the "push-mode" operation, whereas in draft-sun-dime-diameter-resource-control-requirements-01 this mode is explained more clearly. IMHO, this is an area, where draft-ietf-dime-diameter-qos-00 can be improved. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, May 07, 2007 4:21 PM > To: dime@ietf.org > Subject: [Dime] Making decisions regarding QoS Work >=20 > Hi all, >=20 > working on the WG status update I noticed that we are behind schedule > with our Diameter QoS work and subsequently I have had a chat with Dan > about this subject. >=20 > At the last IETF meeting we had a presentation regarding recently > submitted QoS documents (see > http://www1.ietf.org/mail-archive/web/dime/current/msg01338.html). In > short, we made a document management action by splitting the work into: >=20 > 1) Quality of Service Parameters > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-parameters-00.txt >=20 > This document just describes the different QoS parameters. >=20 >=20 > 2) Quality of Service Attribute > http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attributes-00.txt >=20 > This document redefines the QoS-Filter-Rule AVP based on the previously > mentioned QoS parameters. It needs to be aligned with > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.tx t > as that document progresses. This is a short document. >=20 >=20 > 3) Quality of Service Application >=20 > This document describes the Diameter QoS application. >=20 >=20 > Document #2 (and therefore document #1) is needed by the 3GPP for Rel.7 > (from a functionality point of view although the current reference > points to the Diameter QoS application draft). Hence, there is a > considerable amount of pressure to get the work done. #3 needs more work > particularly with respect to question (c) below. >=20 > We need to make three decisions in order to move the work forward. >=20 > a) Are there objections to turn > draft-korhonen-dime-qos-parameters-00.txt into a WG item? >=20 > b) Are there objections to turn > draft-korhonen-dime-qos-attributes-00.txt into a WG item? >=20 > c) What content from > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control- > requirements-01 > should be incorporated into > http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 and pushed to > future work? >=20 > Please respond to (a), (b) and/or (c) by 19th May 2007. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 17 08:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HofRF-0007Ip-W3; Thu, 17 May 2007 08:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIdh-0002Af-5d for dime@ietf.org; Tue, 24 Apr 2007 06:52:53 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgIdf-00043M-Mb for dime@ietf.org; Tue, 24 Apr 2007 06:52:53 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC264213C5 for ; Tue, 24 Apr 2007 12:52:50 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-80-462de182a0b3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1F6F2058F for ; Tue, 24 Apr 2007 12:52:50 +0200 (CEST) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 12:52:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Apr 2007 12:52:49 +0200 Message-ID: <63A23507A6F0C344BE6D60303E9441D90181A578@esealmw114.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Integer32 encoding Thread-Index: AceGXrMqJsEZvVOpTqG/XO94eH5GEQ== From: "Roland Gecse \(IJ/ETH\)" To: X-OriginalArrivalTime: 24 Apr 2007 10:52:50.0637 (UTC) FILETIME=[B3E29FD0:01C7865E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Thu, 17 May 2007 08:50:37 -0400 Subject: [Dime] Integer32 encoding X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Dear DIME Members, I would be glad if someone could answer my question:=20 Where does the diameter base protocol specify how to encode a negative Integer32 AVP value? Please CC replies directly to my e-mail address, as I am not subscribed to this mailing list. Regards, Roland. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 17 09:00:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hofak-0005TY-QL; Thu, 17 May 2007 09:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hofak-0005TT-Cv for dime@ietf.org; Thu, 17 May 2007 09:00:26 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hofaj-0005YF-5M for dime@ietf.org; Thu, 17 May 2007 09:00:26 -0400 Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l4HD0PDX002797 for ; Thu, 17 May 2007 09:00:25 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 09:00:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 May 2007 09:00:24 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702E073@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-asveren-dime-state-recovery Thread-Index: AceYg1VOp1n47ytzTQi4daZ4JyWgUQ== From: "Asveren, Tolga" To: X-OriginalArrivalTime: 17 May 2007 13:00:24.0571 (UTC) FILETIME=[557C84B0:01C79883] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Dime] draft-asveren-dime-state-recovery X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Now there is a new version of draft-asveren-dime-state-recovery available: http://tools.ietf.org/wg/dime/draft-asveren-dime-state-recovery-01.txt As people may recall, the idea was to capture different design choices regarding protocol assisted recovery of sessions after failure situations. We really would appreciate comments about it and believe an examination of draft-bodin-dime-auditing-reqs-02.txt based on the criteria specified in draft-asveren-dime-state-recovery-01.txt would be useful as well. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 17 10:36:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoh5V-0000gT-Ll; Thu, 17 May 2007 10:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoh5V-0000gI-0P for dime@ietf.org; Thu, 17 May 2007 10:36:17 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoh5T-0003o2-H5 for dime@ietf.org; Thu, 17 May 2007 10:36:16 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 16:36:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Integer32 encoding Date: Thu, 17 May 2007 16:36:15 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301D8146D@SEHAN021MB.tcad.telia.se> In-Reply-To: <63A23507A6F0C344BE6D60303E9441D90181A578@esealmw114.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Integer32 encoding thread-index: AceGXrMqJsEZvVOpTqG/XO94eH5GEQSMUlkw References: <63A23507A6F0C344BE6D60303E9441D90181A578@esealmw114.eemea.ericsson.se> From: To: , X-OriginalArrivalTime: 17 May 2007 14:36:13.0903 (UTC) FILETIME=[B85AF5F0:01C79890] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Roland, Section 4.2. in RFC3588 says that Integer32 is a 32 bit _signed_ value, in network byte order. So the highest bit in the value defines the sign just like in normal signed integer arithmetic. E.g. 0x80000000 would be negative whereas 0x7fffffff would be positive. Cheers, Jouni > -----Original Message----- > From: Roland Gecse (IJ/ETH) [mailto:roland.gecse@ericsson.com]=20 > Sent: Tuesday, April 24, 2007 1:53 PM > To: dime@ietf.org > Subject: [Dime] Integer32 encoding >=20 > Dear DIME Members, >=20 > I would be glad if someone could answer my question:=20 >=20 > Where does the diameter base protocol specify how to encode a negative > Integer32 AVP value? >=20 > Please CC replies directly to my e-mail address, as I am not=20 > subscribed to this mailing list. >=20 > Regards, > Roland. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 18 02:18:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hovmx-0005JI-4d; Fri, 18 May 2007 02:18:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hovmv-0005JD-TV for dime@ietf.org; Fri, 18 May 2007 02:18:05 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hovmv-0001Bx-Fg for dime@ietf.org; Fri, 18 May 2007 02:18:05 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4I6HlHx019724 for ; Fri, 18 May 2007 01:18:04 -0500 (CDT) Received: from cnexp02.bj.lucent.com ([135.252.8.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 01:17:44 -0500 Received: from CNEXC1U02.bj.lucent.com ([135.252.8.27]) by cnexp02.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 14:17:41 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: [Dime] question about AVP flags Date: Fri, 18 May 2007 14:17:40 +0800 Message-ID: In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301D8146D@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] question about AVP flags Thread-Index: AceGXrMqJsEZvVOpTqG/XO94eH5GEQSMUlkwACBQugA= References: <63A23507A6F0C344BE6D60303E9441D90181A578@esealmw114.eemea.ericsson.se> <59D7431DE2527D4CB0F1EFEDA5683ED301D8146D@SEHAN021MB.tcad.telia.se> From: "Tang, Alan Shanjing \(Alan\)" To: X-OriginalArrivalTime: 18 May 2007 06:17:41.0114 (UTC) FILETIME=[3D5B55A0:01C79914] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2139628075==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2139628075== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79914.3D389DB7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79914.3D389DB7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello: =20 I have a general question about the AVP flags.=20 =20 In section 4.1 of RFC3588, it is clearly stated that the AVP code combined with the Vendor-Id field is used to identify the attribute uniquely. How do I understand the "uniqueness" of the attribute? Does the "attribute" here include the AVP flags also? Does this mean that the AVP flags must be unique as well? =20 For example, there are two AVPs used by two different applications. The AVP code and Vendor-Id for these two AVPs are both the same. Does this mean that the AVP flags must be the same for these "two" AVPs? =20 Excerpt from RFC3588, section 4.1 is at below, FYI. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 4.1. AVP Header =20 AVP Code The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA (see Section 11.1). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 Thanks in advance! Alan Tang Alcatel-Lucent =20 =20 ------_=_NextPart_001_01C79914.3D389DB7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello:

 

I have a general question about the AVP flags. =

 

In section 4.1 of RFC3588, it is clearly stated that the AVP code combined = with the Vendor-Id field is used to identify the attribute uniquely. How do I understand the “uniqueness” of the attribute? Does the = “attribute” here include the AVP flags also? Does this mean that the AVP flags must = be unique as well?

 

For example, there are two AVPs used by two different applications. The AVP = code and Vendor-Id for these two AVPs are both the same. Does this mean that = the AVP flags must be the same for these “two” = AVPs?

 

Excerpt from RFC3588, section 4.1 is at below, FYI.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

4.1.    AVP Header

 

      AVP Code

      The AVP Code, combined with the Vendor-Id field, identifies = the

      attribute uniquely.  AVP numbers 1 through 255 are reserved = for

      backward compatibility with RADIUS, without setting the = Vendor-Id

      field.  AVP numbers 256 and above are used for Diameter, which = are

      allocated by IANA (see Section 11.1).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Thanks in advance!

Alan Tang

Alcatel-Lucent

 

 

------_=_NextPart_001_01C79914.3D389DB7-- --===============2139628075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2139628075==-- From dime-bounces@ietf.org Fri May 18 04:48:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy8p-0007Th-5c; Fri, 18 May 2007 04:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy8o-0007Tc-HS for dime@ietf.org; Fri, 18 May 2007 04:48:50 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoy8l-00064c-O0 for dime@ietf.org; Fri, 18 May 2007 04:48:50 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:48:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Integer32 encoding Date: Fri, 18 May 2007 10:48:43 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301D81497@SEHAN021MB.tcad.telia.se> In-Reply-To: <63A23507A6F0C344BE6D60303E9441D901B268C4@esealmw114.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Integer32 encoding thread-index: AceGXrMqJsEZvVOpTqG/XO94eH5GEQSMUlkwAAGbjaAAJKgN8A== References: <63A23507A6F0C344BE6D60303E9441D90181A578@esealmw114.eemea.ericsson.se> <59D7431DE2527D4CB0F1EFEDA5683ED301D8146D@SEHAN021MB.tcad.telia.se> <63A23507A6F0C344BE6D60303E9441D901B268C4@esealmw114.eemea.ericsson.se> From: To: , X-OriginalArrivalTime: 18 May 2007 08:48:43.0834 (UTC) FILETIME=[5728A9A0:01C79929] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Funny.. I never came to think that Interger32 could be anything else than two's complement ;-) I guess you are right about this ambiguity. Cheers, Jouni > -----Original Message----- > From: Roland Gecse (IJ/ETH) [mailto:roland.gecse@ericsson.com]=20 > Sent: Thursday, May 17, 2007 6:36 PM > To: Korhonen, Jouni /TeliaSonera Finland Oyj; dime@ietf.org > Subject: RE: [Dime] Integer32 encoding >=20 > Hi Jouni, >=20 > first of all thanks for your mail. I had also the 1st idea to=20 > use two's complement representation of 32bits integer but=20 > this is _not_ explicitly stated in the RFC. There are a=20 > number of representations of signed numbers. OK, two's=20 > complement is the most common. But RFC3588 does not regulate=20 > this, so I could also use one's complement, sign-bit and=20 > magnitude or excess-(2^31-1) representation as common with=20 > some other protocols and still have a conforming=20 > implementation that most likely would not be able to=20 > interwork properly. I believe a clarification would be=20 > worth-while --- that's why the question. >=20 > Roland. >=20 > > -----Original Message----- > > From: jouni.korhonen@teliasonera.com > > [mailto:jouni.korhonen@teliasonera.com] > > Sent: Thursday, May 17, 2007 16:36 > > To: Roland Gecse (IJ/ETH); dime@ietf.org > > Subject: RE: [Dime] Integer32 encoding > >=20 > > Hi Roland, > >=20 > > Section 4.2. in RFC3588 says that Integer32 is a 32 bit _signed_=20 > > value, in network byte order. So the highest bit in the=20 > value defines=20 > > the sign just like in normal signed integer arithmetic. > >=20 > > E.g. 0x80000000 would be negative whereas 0x7fffffff would be=20 > > positive. > >=20 > > Cheers, > > Jouni > >=20 > > > -----Original Message----- > > > From: Roland Gecse (IJ/ETH) [mailto:roland.gecse@ericsson.com] > > > Sent: Tuesday, April 24, 2007 1:53 PM > > > To: dime@ietf.org > > > Subject: [Dime] Integer32 encoding > > >=20 > > > Dear DIME Members, > > >=20 > > > I would be glad if someone could answer my question:=20 > > >=20 > > > Where does the diameter base protocol specify how to encode > > a negative > > > Integer32 AVP value? > > >=20 > > > Please CC replies directly to my e-mail address, as I am not=20 > > > subscribed to this mailing list. > > >=20 > > > Regards, > > > Roland. > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 18 17:19:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp9rQ-0005U0-4b; Fri, 18 May 2007 17:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp9rP-0005Ts-HZ for dime@ietf.org; Fri, 18 May 2007 17:19:39 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hp9rM-0001K3-Un for dime@ietf.org; Fri, 18 May 2007 17:19:39 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1179523175!559449!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32235 invoked from network); 18 May 2007 21:19:35 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 18 May 2007 21:19:35 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4ILJZK9005621 for ; Fri, 18 May 2007 14:19:35 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l4ILJYNp015184 for ; Fri, 18 May 2007 16:19:35 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l4ILJYHl015171 for ; Fri, 18 May 2007 16:19:34 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Making decisions regarding QoS Work Date: Fri, 18 May 2007 17:19:32 -0400 Message-ID: In-Reply-To: <09C9068466B79E4C938DC7737562404D520837@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Making decisions regarding QoS Work thread-index: AceSIZ209vbM8EFMSyy+KcIy5gjF6AAVXRcgAcXw3fA= References: <463F8A2B.9080906@gmx.net><59D7431DE2527D4CB0F1EFEDA5683ED301D81098@SEHAN021MB.tcad.telia.se><011101c79221$7007bd80$514c460a@china.huawei.com> <09C9068466B79E4C938DC7737562404D520837@ILEXC2U01.ndc.lucent.com> From: "McCann Peter-A001034" To: "Sun, Dong \(Dong\)" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Support for the push model is already a part of=20 draft-ietf-dime-diameter-qos-00.txt, as outlined in Section 4.4. However, the text also notes the limitations of this model, in that the discovery problem needs to be solved. To initiate a session, the Authorizing Entity would need to discover the name of a Diameter Client for use in the Destination-Host AVP. I would like to see a scalable and open specification for how to do this on the global Internet before we add more text about the push model to the draft. I have heard some proposals from various SDOs such as keeping a giant table of IP addresses (of UEs) mapped to Diameter Clients. I think such solutions aren't scalable in scenarios where the Authorizing Entity is in a different administrative domain from the Network=20 Element. As noted in the draft, the push model is only applicable when the Authorizing Entity and the Network Element are local to each other, i.e., in the same administrative domain. I would hope that our=20 architecture does not require e.g., a SIP server to be local to the domain providing network access. We should keep in mind the end-to-end principle and not try to facilitate the creation of walled gardens. Personally, I would like to see endpoints deploy a network-layer protocol (such as NSIS) for requesting QoS from the network rather than relying on SIP for this purpose. SIP is an application layer that should be located anywhere on the Internet, not coupled to the packet path. I would like to see support for an authorization token in the form of an NAI that can be used for routing the request to the proper Authorizing Entity in the usual way (i.e., routing based on the User Name AVP). -Pete Sun, Dong (Dong) wrote: > Hi All, >=20 > Concerning the item c) - QoS application, as I commented some time > ago, the current draft only covers the NE (e.g. router)/endpoint > initiated policy Pull model, however, the Push model in which the QoS > attributes are proactively installed by the policy server is not yet > addressed. =20 >=20 > A bunch of network technologies and deployment scenarios are > requiring the Push model now, and several SDOs have defined the Push > model as a requirement in policy control framework, e.g. ETSI TISPAN, > DSL Forum, ITU-T NGN and CableLabs (maybe WiMAX forum), it is also > envisaged as the evolution of policy control mechanism since it can > mitigate the dependence of the QoS control on the endpoint's > capability and simplify the endpoint's implementation. =20 >=20 > Two options to move forward this QoS application work in my mind: > 1) Define a single WG item to cover both Pull and Push models > 2) Define two WG items to address Pull and Push model separately >=20 > I personally prefer to create a single WG item to address both Pull > and Push models. Certainly, we need to look into details how to > integrate the Resource-control-application ID into the QoS > application draft. =20 >=20 > Cheers, > Dong >=20 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Wednesday, May 09, 2007 6:05 AM > To: dime@ietf.org; Hannes.Tschofenig@gmx.net; > jouni.korhonen@teliasonera.com=20 > Subject: Re: [Dime] Making decisions regarding QoS Work >=20 > Hi all, > c) > I think the following from Sun's draft could be moved to the QoS > draft:=20 >=20 > (1) 2.2 Resource Control models which give an overview of push & pull > models (2) 2.4 Functional framework & 2.5 its use cases > (3) We need section 3 describing new "server-initiated" commands. > However the AVPs need more consideration for e.g. some AVP like > QoS-Authorization-Resources to be added? Also PI-Request-Type AVP is > unnecessary as the RCDE will use ASR, RAR for terminate, update > purposes. (4) Section 4 which describe session initiation, update & > termination for push model. This draft implies extending & using the > RFC 3588 server state machine at RCDE. But this is not agreed by the > WG yet. =20 >=20 > B. R. > Tina > +86-755-28972912 (Office) +86-13922884380 (Mobile) > Messengers: > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU > Jabber: > tina@jabber.org Google talk: tinatsou6@gmail.com >=20 > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, May 09, 2007 11:46 AM > Subject: RE: [Dime] Making decisions regarding QoS Work >=20 >=20 > Hi all, >=20 > Having my own vested interests on these I support having > a) & b) as WG items. >=20 > No comment on c) yet. >=20 > Cheers, > Jouni >=20 >=20 >> Hi all, >>=20 >> working on the WG status update I noticed that we are behind schedule >> with our Diameter QoS work and subsequently I have had a chat with >> Dan about this subject.=20 >>=20 >> At the last IETF meeting we had a presentation regarding recently >> submitted QoS documents (see >> http://www1.ietf.org/mail-archive/web/dime/current/msg01338.ht=20 >> ml). In short, we made a document management action by splitting the >> work into:=20 >>=20 >> 1) Quality of Service Parameters >> http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-paramete >> rs-00.txt=20 >>=20 >> This document just describes the different QoS parameters. >>=20 >>=20 >> 2) Quality of Service Attribute >> http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attribut >> es-00.txt=20 >>=20 >> This document redefines the QoS-Filter-Rule AVP based on the >> previously mentioned QoS parameters. It needs to be aligned with >> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-r >> ules-02.txt as that document progresses. This is a short document. >>=20 >>=20 >> 3) Quality of Service Application >>=20 >> This document describes the Diameter QoS application. >>=20 >>=20 >> Document #2 (and therefore document #1) is needed by the 3GPP for >> Rel.7 (from a functionality point of view although the current >> reference points to the Diameter QoS application draft). Hence, there >> is a considerable amount of pressure to get the work done. #3 needs >> more work particularly with respect to question (c) below. >>=20 >> We need to make three decisions in order to move the work forward. >>=20 >> a) Are there objections to turn >> draft-korhonen-dime-qos-parameters-00.txt into a WG item? >>=20 >> b) Are there objections to turn >> draft-korhonen-dime-qos-attributes-00.txt into a WG item? >>=20 >> c) What content from >> http://tools.ietf.org/html/draft-sun-dime-diameter-resource-co >> ntrol-requirements-01 should be incorporated into >> http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 >> and pushed to future work? >>=20 >> Please respond to (a), (b) and/or (c) by 19th May 2007. >>=20 >> Ciao >> Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 23 11:26:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqsjK-00036f-Uo; Wed, 23 May 2007 11:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqsjJ-00036V-ML for dime@ietf.org; Wed, 23 May 2007 11:26:25 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqsjH-0002bD-SZ for dime@ietf.org; Wed, 23 May 2007 11:26:25 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 21F8E37C011; Wed, 23 May 2007 20:53:00 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTPid 098BD37C00F; Wed, 23 May 2007 20:53:00 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 20:56:20 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 May 2007 20:55:20 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on Auth Server state machine Thread-Index: AcedTpMFB/4/veV/RCWe3qQAsfOk8w== From: "Balamurugan T, TLS-Chennai" To: , X-OriginalArrivalTime: 23 May 2007 15:26:20.0385 (UTC) FILETIME=[B6D63510:01C79D4E] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.5425 TC:1F TRN:29 TV:3.6.1039(15194.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Type: multipart/mixed; boundary="=_Boundary_uaoO4LEvkyNlMSASnLLQ" X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [Dime] Clarification on Auth Server state machine X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --=_Boundary_uaoO4LEvkyNlMSASnLLQ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Clarification on Auth Server state machine

Hi All,

    As per RFC3588, The = diameter server will send the RAR request to diameter client.But, In = AUTH SERVER state machine
    there is no state = table entry to send  Service specific requests from server. Also = Sh,GqGo interfaces send some request

    messages  from = server.

    Can you please = clarify this contradiction in RFC.

Regards,
Bala

--=_Boundary_uaoO4LEvkyNlMSASnLLQ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- --=_Boundary_uaoO4LEvkyNlMSASnLLQ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --=_Boundary_uaoO4LEvkyNlMSASnLLQ-- From dime-bounces@ietf.org Wed May 23 12:15:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqtUN-0006mS-6G; Wed, 23 May 2007 12:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqtUL-0006jj-Dq for dime@ietf.org; Wed, 23 May 2007 12:15:01 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqtUJ-00051F-NX for dime@ietf.org; Wed, 23 May 2007 12:15:01 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l4NGEBdM057123; Wed, 23 May 2007 12:14:11 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46546853.7000702@tari.toshiba.com> Date: Wed, 23 May 2007 12:14:11 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Balamurugan T, TLS-Chennai" Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > As per RFC3588, The diameter server will send the RAR request to > diameter client.But, In AUTH SERVER state machine > there is no state table entry to send Service specific requests > from server. Also Sh,GqGo interfaces send some request > Maybe we can separate your comments into two(2). First, RARs are not depicted in the stateful auth fsms. This should probably be fixed if this is the case. Second, I'm not sure that we should not consider RAR as "service specific requests". AFAIK, service specific request sent from the server is currently not allowed unless the server entity is generating a diameter client session. There are ongoing discussions about this topic in other threads (Qos). regards, victor > messages from server. > > Can you please clarify this contradiction in RFC. > > Regards, > Bala > > ------------------------------------------------------------------------ > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of > this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 24 08:10:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrC9Z-0002oz-8k; Thu, 24 May 2007 08:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrC9Y-0002on-MF for dime@ietf.org; Thu, 24 May 2007 08:10:48 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrC8w-00005i-Pc for dime@ietf.org; Thu, 24 May 2007 08:10:48 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 53A3036013D for ; Thu, 24 May 2007 17:38:46 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTP id 117FE36015Ffor ; Thu, 24 May 2007 17:38:46 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 17:39:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Clarification on Auth Server state machine Date: Thu, 24 May 2007 17:39:52 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601655160@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: AcedVadrB8pgeIS2T6yBIjdUdNbb/gAYe9vwAATAutAAC8dPgA== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 24 May 2007 12:09:55.0587 (UTC) FILETIME=[70F67D30:01C79DFC] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-24.7356 TC:1F TRN:94 TV:3.6.1039(15194.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.3 (/) X-Scan-Signature: 97b8643c8d9cc60b17ea5996f3e435cb X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1015502420==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1015502420== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79DFC.712361E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79DFC.712361E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Victor,=20 Thanks for the reply. Please suggest if it is correct to add the following additional state table entries to the "SERVER state full AUTH FSM" to add support for sending RAR and any other service specific requests initiation from server. =20 =20 Current State Event Action New State Open Home server wants to confirm authorization of the user=20 Send RAR Open Open Received RAA with some failure result code. Cleanup idle Open Received RAA with successful result code. Update the session=20 Open Open=20 RAR sent failed=20 resend RAR Open =20 =20 Thanks and Regards Bala=20 =20 =20 -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Wednesday, May 23, 2007 9:44 PM To: Balamurugan T, TLS-Chennai Cc: dime@ietf.org Subject: Re: [Dime] Clarification on Auth Server state machine =20 Hi, =20 > As per RFC3588, The diameter server will send the RAR request to=20 > diameter client.But, In AUTH SERVER state machine > there is no state table entry to send Service specific requests=20 > from server. Also Sh,GqGo interfaces send some request >=20 =20 Maybe we can separate your comments into two(2). First, RARs are not=20 depicted in the stateful auth fsms. This should probably be fixed if=20 this is the case. Second, I'm not sure that we should not consider RAR=20 as "service specific requests". AFAIK, service specific request sent=20 from the server is currently not allowed unless the server entity is=20 generating a diameter client session. There are ongoing discussions=20 about this topic in other threads (Qos). =20 regards, victor =20 > messages from server. >=20 > Can you please clarify this contradiction in RFC. >=20 > Regards, > Bala >=20 > ------------------------------------------------------------------------ >=20 > DISCLAIMER: > ------------------------------------------------------------------------ ----------------------------------------------- >=20 > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 > this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 > this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 > attachments please check them for viruses and defect. >=20 > ------------------------------------------------------------------------ ----------------------------------------------- > ------------------------------------------------------------------------ >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 =20 =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C79DFC.712361E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello! = Victor, 

Thanks for the = reply.=20 Please suggest if it is correct to add the following additional state table entries to the = “SERVER state full AUTH FSM” to = add support for sending RAR and any other = service specific=20 requests initiation=20 from server.

 

 

Current=20 State

Event

Action

New = State

Open

Home server wants to confirm = authorization of=20 the user

Send = RAR

Open

Open

Received RAA with some failure = result=20 code.

Cleanup

idle

Open

Received RAA with successful = result=20 code.

Update the session=20

Open

Open =

RAR sent failed =

resend = RAR

Open

 

 

Thanks and=20 Regards

Bala 

 

 

-----Original=20 Message-----

From: Victor Fajardo=20 [mailto:vfajardo@tari.toshiba.com]

Sent: Wednesday, May 23, 2007 9:44=20 PM

To: Balamurugan T,=20 TLS-Chennai

Cc: = dime@ietf.org

Subject: Re: [Dime] Clarification on Auth = Server state=20 machine

 

Hi,

 

>     As per RFC3588, = The=20 diameter server will send the RAR request to =

> diameter client.But, In AUTH SERVER = state=20 machine

>     there is no = state table=20 entry to send  Service specific requests =

> from server. Also Sh,GqGo interfaces = send some=20 request

> 

 

Maybe we can separate your comments into = two(2).=20 First, RARs are not

depicted in the stateful auth fsms. This = should=20 probably be fixed if

this is the case. Second, I'm not sure that = we should=20 not consider RAR

as "service specific requests". AFAIK, = service=20 specific request sent

from the server is currently not allowed = unless the=20 server entity is

generating a diameter client session. There = are=20 ongoing discussions

about this topic in other threads=20 (Qos).

 

regards,

victor

 

>     messages  = from=20 server.

> 

>     Can you please = clarify=20 this contradiction in RFC.

> 

> Regards,

> Bala

> 

>=20 = ------------------------------------------------------------------------<= o:p>

> 

> = DISCLAIMER:

>=20 = -------------------------------------------------------------------------= ----------------------------------------------

> 

> The contents of this e-mail and any = attachment(s)=20 are confidential and intended for the named recipient(s)=20 only.

> It shall not attach any liability on = the=20 originator or HCL or its affiliates. Any views or opinions presented = in=20

> this email are solely those of the = author and may=20 not necessarily reflect the opinions of HCL or its=20 affiliates.

> Any form of reproduction, = dissemination, copying,=20 disclosure, modification, distribution and / or publication of=20

> this message without the prior written = consent of=20 the author of this e-mail is strictly prohibited. If you=20 have

> received this email in error please = delete it and=20 notify the sender immediately. Before opening any mail and=20

> attachments please check them for = viruses and=20 defect.

> 

>=20 = -------------------------------------------------------------------------= ----------------------------------------------

>=20 = ------------------------------------------------------------------------<= o:p>

> 

>=20 = _______________________________________________<= /P>

> DiME mailing = list

> = DiME@ietf.org

>=20 = https://www1.ietf.org/mailman/listinfo/dime

>   =

 

 

_______________________________________________

DiME mailing = list

DiME@ietf.org

https://www1.ietf.org/mailman/listinfo/dime

------_=_NextPart_001_01C79DFC.712361E4-- --===============1015502420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1015502420==-- From dime-bounces@ietf.org Thu May 24 19:04:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrMMZ-0002oQ-37; Thu, 24 May 2007 19:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrMMX-0002oD-AT for dime@ietf.org; Thu, 24 May 2007 19:04:53 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrMMV-0003bm-Sl for dime@ietf.org; Thu, 24 May 2007 19:04:53 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l4ON4HYl062927; Thu, 24 May 2007 19:04:18 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <465619F2.2000800@tari.toshiba.com> Date: Thu, 24 May 2007 19:04:18 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Balamurugan T, TLS-Chennai" Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601655160@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601655160@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l4ON4HYl062927 X-Spam-Score: -2.4 (--) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org It seems ok to me, maybe some folks have comments as well. Also, the=20 client side may also need to be defined. --victor > Hello! Victor, > > Thanks for the reply. Please suggest if it is correct to add the > following additional state table entries to the =93SERVER state ful= l > AUTH FSM=94 to add support for sending RAR and any other service > specific requests initiation from server. > > Current State > > =09 > > Event > > =09 > > Action > > =09 > > New State > > Open > > =09 > > Home server wants to confirm authorization of the user > > =09 > > Send RAR > > =09 > > Open > > Open > > =09 > > Received RAA with some failure result code. > > =09 > > Cleanup > > =09 > > idle > > Open > > =09 > > Received RAA with successful result code. > > =09 > > Update the session > > =09 > > Open > > Open > > =09 > > RAR sent failed > > =09 > > resend RAR > > =09 > > Open > > Thanks and Regards > > Bala > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Wednesday, May 23, 2007 9:44 PM > > To: Balamurugan T, TLS-Chennai > > Cc: dime@ietf.org > > Subject: Re: [Dime] Clarification on Auth Server state machine > > Hi, > > > As per RFC3588, The diameter server will send the RAR request to > > > diameter client.But, In AUTH SERVER state machine > > > there is no state table entry to send Service specific requests > > > from server. Also Sh,GqGo interfaces send some request > > > > > Maybe we can separate your comments into two(2). First, RARs are no= t > > depicted in the stateful auth fsms. This should probably be fixed i= f > > this is the case. Second, I'm not sure that we should not consider > RAR > > as "service specific requests". AFAIK, service specific request sen= t > > from the server is currently not allowed unless the server entity i= s > > generating a diameter client session. There are ongoing discussions > > about this topic in other threads (Qos). > > regards, > > victor > > > messages from server. > > > > > > Can you please clarify this contradiction in RFC. > > > > > > Regards, > > > Bala > > > > > > -----------------------------------------------------------------= ------- > > > > > > DISCLAIMER: > > > -----------------------------------------------------------------= ------------------------------------------------------ > > > > > > The contents of this e-mail and any attachment(s) are > confidential and intended for the named recipient(s) only. > > > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > > > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > > > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > > > this message without the prior written consent of the author of > this e-mail is strictly prohibited. If you have > > > received this email in error please delete it and notify the > sender immediately. Before opening any mail and > > > attachments please check them for viruses and defect. > > > > > > -----------------------------------------------------------------= ------------------------------------------------------ > > > -----------------------------------------------------------------= ------- > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -----------------------------------------------------------------------= - > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat May 26 00:31:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrnwF-0008WC-Iv; Sat, 26 May 2007 00:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrnwE-0008Vz-8P for dime@ietf.org; Sat, 26 May 2007 00:31:34 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrnwD-0003H5-2c for dime@ietf.org; Sat, 26 May 2007 00:31:34 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id EAFFF360006; Sat, 26 May 2007 10:00:17 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTPid BBD14360002; Sat, 26 May 2007 10:00:17 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 May 2007 10:01:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Clarification on Auth Server state machine Date: Sat, 26 May 2007 10:01:26 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601680A5D@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: AceeV+LcCmcru5W9S2yXgJ7JF6X/wwA8/1EA From: "Balamurugan T, TLS-Chennai" To: "Victor Fajardo" X-OriginalArrivalTime: 26 May 2007 04:31:29.0299 (UTC) FILETIME=[BAC38630:01C79F4E] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-23.3650 TC:1F TRN:67 TV:3.6.1039(15198.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, The following state table entries should be added in Auth client FSM for = RAR support. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D State Event Action New State =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Idle RAR Received Send RAA Idle for unknown session with Result-Code =3D UNKNOWN_ SESSION_ID Open RAR Received Send RAA Open with valid session with parameters. Result-Code =3D SUCCESS, =20 Open RAR Received Send RAA Open with invalid session with parameters. Result-Code =3D SUCCESS, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please add your comments if I missed some points. Regards, Bala -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: Friday, May 25, 2007 4:34 AM To: Balamurugan T, TLS-Chennai Cc: dime@ietf.org Subject: Re: [Dime] Clarification on Auth Server state machine It seems ok to me, maybe some folks have comments as well. Also, the=20 client side may also need to be defined. --victor > Hello! Victor, > > Thanks for the reply. Please suggest if it is correct to add the > following additional state table entries to the =93SERVER state = full > AUTH FSM=94 to add support for sending RAR and any other service > specific requests initiation from server. > > Current State > > =09 > > Event > > =09 > > Action > > =09 > > New State > > Open > > =09 > > Home server wants to confirm authorization of the user > > =09 > > Send RAR > > =09 > > Open > > Open > > =09 > > Received RAA with some failure result code. > > =09 > > Cleanup > > =09 > > idle > > Open > > =09 > > Received RAA with successful result code. > > =09 > > Update the session > > =09 > > Open > > Open > > =09 > > RAR sent failed > > =09 > > resend RAR > > =09 > > Open > > Thanks and Regards > > Bala > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Wednesday, May 23, 2007 9:44 PM > > To: Balamurugan T, TLS-Chennai > > Cc: dime@ietf.org > > Subject: Re: [Dime] Clarification on Auth Server state machine > > Hi, > > > As per RFC3588, The diameter server will send the RAR request to > > > diameter client.But, In AUTH SERVER state machine > > > there is no state table entry to send Service specific requests > > > from server. Also Sh,GqGo interfaces send some request > > > > > Maybe we can separate your comments into two(2). First, RARs are = not > > depicted in the stateful auth fsms. This should probably be fixed = if > > this is the case. Second, I'm not sure that we should not consider > RAR > > as "service specific requests". AFAIK, service specific request = sent > > from the server is currently not allowed unless the server entity = is > > generating a diameter client session. There are ongoing = discussions > > about this topic in other threads (Qos). > > regards, > > victor > > > messages from server. > > > > > > Can you please clarify this contradiction in RFC. > > > > > > Regards, > > > Bala > > > > > > = ------------------------------------------------------------------------ > > > > > > DISCLAIMER: > > > = -------------------------------------------------------------------------= ---------------------------------------------- > > > > > > The contents of this e-mail and any attachment(s) are > confidential and intended for the named recipient(s) only. > > > It shall not attach any liability on the originator or HCL or = its > affiliates. Any views or opinions presented in > > > this email are solely those of the author and may not = necessarily > reflect the opinions of HCL or its affiliates. > > > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > > > this message without the prior written consent of the author of > this e-mail is strictly prohibited. If you have > > > received this email in error please delete it and notify the > sender immediately. Before opening any mail and > > > attachments please check them for viruses and defect. > > > > > > = -------------------------------------------------------------------------= ---------------------------------------------- > > > = ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > = ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun May 27 23:58:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsWNf-0002oo-Cp; Sun, 27 May 2007 23:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsWNe-0002oe-7z for dime@ietf.org; Sun, 27 May 2007 23:58:50 -0400 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsWNZ-0000Y2-Fc for dime@ietf.org; Sun, 27 May 2007 23:58:50 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 294E337C026; Mon, 28 May 2007 09:25:11 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid ECE5E37C01B; Mon, 28 May 2007 09:25:10 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 09:28:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Clarification on Auth Server state machine Date: Mon, 28 May 2007 09:26:44 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601680B80@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: AceeV+LcCmcru5W9S2yXgJ7JF6X/wwA8/1EAAGPWneA= References: <66E8AEE9980BB44CA5FCAD39EBA56AC601680A5D@CHN-HCLT-EVS02.HCLT.CO RP.HCL.IN> From: "Arun Santhanam, TLS-Chennai" To: "Balamurugan T, TLS-Chennai" , "Victor Fajardo" X-OriginalArrivalTime: 28 May 2007 03:58:42.0109 (UTC) FILETIME=[7B0DA6D0:01C7A0DC] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-24.1948 TC:1F TRN:74 TV:3.6.1039(15198.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Bala, Open RAR Received Send RAA Open with invalid session with parameters. Result-Code =3D SUCCESS, For the above said State I think The state should be "Idle" Since the RAR received is with Invalid session Parameter Pls. refer section 8.3 in RFC 3588 It says that the RAR received should have the correct session-Id that is in Progress. And also the result code should have UNKNOWN_SESSION_ID rather than SUCCESS. Thx -Arun -----Original Message----- From: Balamurugan T, TLS-Chennai [mailto:tbalamurugan@hcl.in]=20 Sent: Saturday, May 26, 2007 10:01 AM To: Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Clarification on Auth Server state machine Hi Victor, The following state table entries should be added in Auth client FSM for RAR support. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D State Event Action New State =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Idle RAR Received Send RAA Idle for unknown session with Result-Code =3D UNKNOWN_ SESSION_ID Open RAR Received Send RAA Open with valid session with parameters. Result-Code =3D SUCCESS, =20 Open RAR Received Send RAA Open with invalid session with parameters. Result-Code =3D SUCCESS, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please add your comments if I missed some points. Regards, Bala -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: Friday, May 25, 2007 4:34 AM To: Balamurugan T, TLS-Chennai Cc: dime@ietf.org Subject: Re: [Dime] Clarification on Auth Server state machine It seems ok to me, maybe some folks have comments as well. Also, the=20 client side may also need to be defined. --victor > Hello! Victor, > > Thanks for the reply. Please suggest if it is correct to add the > following additional state table entries to the "SERVER state full > AUTH FSM" to add support for sending RAR and any other service > specific requests initiation from server. > > Current State > > =09 > > Event > > =09 > > Action > > =09 > > New State > > Open > > =09 > > Home server wants to confirm authorization of the user > > =09 > > Send RAR > > =09 > > Open > > Open > > =09 > > Received RAA with some failure result code. > > =09 > > Cleanup > > =09 > > idle > > Open > > =09 > > Received RAA with successful result code. > > =09 > > Update the session > > =09 > > Open > > Open > > =09 > > RAR sent failed > > =09 > > resend RAR > > =09 > > Open > > Thanks and Regards > > Bala > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Wednesday, May 23, 2007 9:44 PM > > To: Balamurugan T, TLS-Chennai > > Cc: dime@ietf.org > > Subject: Re: [Dime] Clarification on Auth Server state machine > > Hi, > > > As per RFC3588, The diameter server will send the RAR request to > > > diameter client.But, In AUTH SERVER state machine > > > there is no state table entry to send Service specific requests > > > from server. Also Sh,GqGo interfaces send some request > > > > > Maybe we can separate your comments into two(2). First, RARs are not > > depicted in the stateful auth fsms. This should probably be fixed if > > this is the case. Second, I'm not sure that we should not consider > RAR > > as "service specific requests". AFAIK, service specific request sent > > from the server is currently not allowed unless the server entity is > > generating a diameter client session. There are ongoing discussions > > about this topic in other threads (Qos). > > regards, > > victor > > > messages from server. > > > > > > Can you please clarify this contradiction in RFC. > > > > > > Regards, > > > Bala > > > > > > ------------------------------------------------------------------------ > > > > > > DISCLAIMER: > > > ------------------------------------------------------------------------ ----------------------------------------------- > > > > > > The contents of this e-mail and any attachment(s) are > confidential and intended for the named recipient(s) only. > > > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > > > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > > > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > > > this message without the prior written consent of the author of > this e-mail is strictly prohibited. If you have > > > received this email in error please delete it and notify the > sender immediately. Before opening any mail and > > > attachments please check them for viruses and defect. > > > > > > ------------------------------------------------------------------------ ----------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 28 06:07:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsc8G-0006NB-Fo; Mon, 28 May 2007 06:07:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsc8F-0006N3-PQ for dime@ietf.org; Mon, 28 May 2007 06:07:19 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsc8E-0001XX-K4 for dime@ietf.org; Mon, 28 May 2007 06:07:19 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JIQ00MHMXEV9M@szxga03-in.huawei.com> for dime@ietf.org; Mon, 28 May 2007 18:06:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JIQ00HTXXEU46@szxga03-in.huawei.com> for dime@ietf.org; Mon, 28 May 2007 18:06:31 +0800 (CST) Received: from huawei1515 ([10.18.4.137]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIQ00J5OXEP9X@szxml04-in.huawei.com> for dime@ietf.org; Mon, 28 May 2007 18:06:30 +0800 (CST) Date: Mon, 28 May 2007 15:36:25 +0530 From: Rajith R Subject: RE: [Dime] Clarification on Auth Server state machine In-reply-to: <66E8AEE9980BB44CA5FCAD39EBA56AC601680A5D@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> To: "'Balamurugan T, TLS-Chennai'" , 'Victor Fajardo' Message-id: <00d701c7a10f$da8c7d10$8904120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceeV+LcCmcru5W9S2yXgJ7JF6X/wwA8/1EAAHD0GIA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org What if client receives an RAR and chooses not to comply? >-----Original Message----- >From: Balamurugan T, TLS-Chennai [mailto:tbalamurugan@hcl.in] >Sent: Saturday, May 26, 2007 10:01 AM >To: Victor Fajardo >Cc: dime@ietf.org >Subject: RE: [Dime] Clarification on Auth Server state machine > >Hi Victor, > >The following state table entries should be added in Auth >client FSM for RAR support. > >===================================================================== >State Event Action New State >===================================================================== >Idle RAR Received Send RAA Idle > for unknown session with > Result-Code > = UNKNOWN_ > SESSION_ID > >Open RAR Received Send RAA Open > with valid session with > parameters. Result-Code > = SUCCESS, > >Open RAR Received Send RAA Open > with invalid session with > parameters. Result-Code > = SUCCESS, >====================================================================== > > Please add your comments if I missed some points. > >Regards, >Bala > > > > > > > > > > >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Friday, May 25, 2007 4:34 AM >To: Balamurugan T, TLS-Chennai >Cc: dime@ietf.org >Subject: Re: [Dime] Clarification on Auth Server state machine > > >It seems ok to me, maybe some folks have comments as well. >Also, the client side may also need to be defined. > >--victor > >> Hello! Victor, >> >> Thanks for the reply. Please suggest if it is correct to add the >> following additional state table entries to the "SERVER >state full >> AUTH FSM" to add support for sending RAR and any other service >> specific requests initiation from server. >> >> Current State >> >> >> >> Event >> >> >> >> Action >> >> >> >> New State >> >> Open >> >> >> >> Home server wants to confirm authorization of the user >> >> >> >> Send RAR >> >> >> >> Open >> >> Open >> >> >> >> Received RAA with some failure result code. >> >> >> >> Cleanup >> >> >> >> idle >> >> Open >> >> >> >> Received RAA with successful result code. >> >> >> >> Update the session >> >> >> >> Open >> >> Open >> >> >> >> RAR sent failed >> >> >> >> resend RAR >> >> >> >> Open >> >> Thanks and Regards >> >> Bala >> >> -----Original Message----- >> >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> >> Sent: Wednesday, May 23, 2007 9:44 PM >> >> To: Balamurugan T, TLS-Chennai >> >> Cc: dime@ietf.org >> >> Subject: Re: [Dime] Clarification on Auth Server state machine >> >> Hi, >> >> > As per RFC3588, The diameter server will send the RAR >request to >> >> > diameter client.But, In AUTH SERVER state machine >> >> > there is no state table entry to send Service specific requests >> >> > from server. Also Sh,GqGo interfaces send some request >> >> > >> >> Maybe we can separate your comments into two(2). First, RARs are >> not >> >> depicted in the stateful auth fsms. This should probably >be fixed >> if >> >> this is the case. Second, I'm not sure that we should >not consider >> RAR >> >> as "service specific requests". AFAIK, service specific request >> sent >> >> from the server is currently not allowed unless the >server entity >> is >> >> generating a diameter client session. There are ongoing >> discussions >> >> about this topic in other threads (Qos). >> >> regards, >> >> victor >> >> > messages from server. >> >> > >> >> > Can you please clarify this contradiction in RFC. >> >> > >> >> > Regards, >> >> > Bala >> >> > >> >> > >> >---------------------------------------------------------------------- >> -- >> >> > >> >> > DISCLAIMER: >> >> > >> >---------------------------------------------------------------------- >> ------------------------------------------------- >> >> > >> >> > The contents of this e-mail and any attachment(s) are >> confidential and intended for the named recipient(s) only. >> >> > It shall not attach any liability on the originator or >HCL or its >> affiliates. Any views or opinions presented in >> >> > this email are solely those of the author and may not >necessarily >> reflect the opinions of HCL or its affiliates. >> >> > Any form of reproduction, dissemination, copying, disclosure, >> modification, distribution and / or publication of >> >> > this message without the prior written consent of the author of >> this e-mail is strictly prohibited. If you have >> >> > received this email in error please delete it and notify the >> sender immediately. Before opening any mail and >> >> > attachments please check them for viruses and defect. >> >> > >> >> > >> >---------------------------------------------------------------------- >> ------------------------------------------------- >> >> > >> >---------------------------------------------------------------------- >> -- >> >> > >> >> > _______________________________________________ >> >> > DiME mailing list >> >> > DiME@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/dime >> >> > >> >> _______________________________________________ >> >> DiME mailing list >> >> DiME@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/dime >> >> >---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue May 29 08:18:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0eH-0003UH-7C; Tue, 29 May 2007 08:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0eG-0003Qt-CZ for dime@ietf.org; Tue, 29 May 2007 08:18:00 -0400 Received: from correo9.acens.net ([217.116.0.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht0eC-0000zj-Fi for dime@ietf.org; Tue, 29 May 2007 08:18:00 -0400 Received: (qmail 25305 invoked from network); 29 May 2007 12:17:54 -0000 Received: from unknown (HELO [192.168.1.21]) (miguel.nunez.mantica-solutions.com@[85.52.193.241]) (envelope-sender ) by correo9.acens.net (qmail-ldap-1.03) with SMTP for ; 29 May 2007 12:17:54 -0000 Subject: Re: [Dime] Clarification on Auth Server state machine From: "Miguel A." =?ISO-8859-1?Q?Nu=F1ez?= To: Victor Fajardo In-Reply-To: <46546853.7000702@tari.toshiba.com> References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> Organization: Mantica Solutions S.L. Date: Tue, 29 May 2007 14:17:56 +0200 Message-Id: <1180441076.6206.112.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0097684211==" Errors-To: dime-bounces@ietf.org --===============0097684211== Content-Type: multipart/alternative; boundary="=-Mg/FN6Es2Hr83IE1q4ee" --=-Mg/FN6Es2Hr83IE1q4ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, I have checked auth stateful server fsm at rfc 3588 and in fact it does not allow to send service specific requests. Checking the auth stateless server fsm, it neither allows to send service specific requests. This is a bit surprising because i.e. Sh interface servers, that work in stateless mode, can send PNR requests. This seems to be against the spirit of diameter being a peer-to-peer protocol from a transport point of view. Although peers are simetric from a transport point of view, servers cannot send requests (except ASR as per the fsm). And more, there is a contradiction between RFC 3588 and some 3GPP specs. Victor, do you know if there are plans to modify the fsms in the new drafts evolving rfc3588? regards, Miguel Angel On mié, 2007-05-23 at 12:14 -0400, Victor Fajardo wrote: > Hi, > > > As per RFC3588, The diameter server will send the RAR request to > > diameter client.But, In AUTH SERVER state machine > > there is no state table entry to send Service specific requests > > from server. Also Sh,GqGo interfaces send some request > > > > Maybe we can separate your comments into two(2). First, RARs are not > depicted in the stateful auth fsms. This should probably be fixed if > this is the case. Second, I'm not sure that we should not consider RAR > as "service specific requests". AFAIK, service specific request sent > from the server is currently not allowed unless the server entity is > generating a diameter client session. There are ongoing discussions > about this topic in other threads (Qos). > > regards, > victor > > > messages from server. > > > > Can you please clarify this contradiction in RFC. > > > > Regards, > > Bala > > > > ------------------------------------------------------------------------ > > > > DISCLAIMER: > > ----------------------------------------------------------------------------------------------------------------------- > > > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > > It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in > > this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. > > Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of > > this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have > > received this email in error please delete it and notify the sender immediately. Before opening any mail and > > attachments please check them for viruses and defect. > > > > ----------------------------------------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > --=-Mg/FN6Es2Hr83IE1q4ee Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I have checked auth stateful server fsm at rfc 3588 and in fact it does not allow to send service specific requests.

Checking the auth stateless server fsm, it neither allows to send service specific requests. This is a bit surprising because i.e. Sh interface servers, that work in stateless mode, can send PNR requests.

This seems to be against the spirit of diameter being a peer-to-peer protocol from a transport point of view. Although peers are simetric from a transport point of view, servers cannot send requests (except ASR as per the fsm). And more, there is a contradiction between RFC 3588 and some 3GPP specs.

Victor, do you know if there are plans to modify the fsms in the new drafts evolving rfc3588?


regards,
Miguel Angel




On mié, 2007-05-23 at 12:14 -0400, Victor Fajardo wrote: 
Hi,

>     As per RFC3588, The diameter server will send the RAR request to 
> diameter client.But, In AUTH SERVER state machine
>     there is no state table entry to send  Service specific requests 
> from server. Also Sh,GqGo interfaces send some request
>

Maybe we can separate your comments into two(2). First, RARs are not 
depicted in the stateful auth fsms. This should probably be fixed if 
this is the case. Second, I'm not sure that we should not consider RAR 
as "service specific requests". AFAIK, service specific request sent 
from the server is currently not allowed unless the server entity is 
generating a diameter client session. There are ongoing discussions 
about this topic in other threads (Qos).

regards,
victor

>     messages  from server.
>
>     Can you please clarify this contradiction in RFC.
>
> Regards,
> Bala
>
> ------------------------------------------------------------------------
>
> DISCLAIMER:
> -----------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
> this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
> this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender immediately. Before opening any mail and 
> attachments please check them for viruses and defect.
>
> -----------------------------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>   


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--=-Mg/FN6Es2Hr83IE1q4ee-- --===============0097684211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0097684211==-- From dime-bounces@ietf.org Tue May 29 09:18:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1ar-0000Yj-1O; Tue, 29 May 2007 09:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1ap-0000Yd-LD for dime@ietf.org; Tue, 29 May 2007 09:18:31 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht1ao-0004ZJ-9v for dime@ietf.org; Tue, 29 May 2007 09:18:31 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l4TDHrUo087969; Tue, 29 May 2007 09:17:53 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <465C2801.5050201@tari.toshiba.com> Date: Tue, 29 May 2007 09:17:53 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: =?UTF-8?B?IlwiTWlndWVsIEEuXCIgTnXDsWV6Ig==?= Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> In-Reply-To: <1180441076.6206.112.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Miguel, Comments inline: > > I have checked auth stateful server fsm at rfc 3588 and in fact it > does not allow to send service specific requests. > > Checking the auth stateless server fsm, it neither allows to send > service specific requests. This is a bit surprising because i.e. Sh > interface servers, that work in stateless mode, can send PNR requests. > > This seems to be against the spirit of diameter being a peer-to-peer > protocol from a transport point of view. Although peers are simetric > from a transport point of view, servers cannot send requests (except > ASR as per the fsm). And more, there is a contradiction between RFC > 3588 and some 3GPP specs. I guess we can also consider diameter as a two(2) part protocol where the peer fsm is the peer-to-peer part and the sessions fsm is the client/server application part. The current discussion is focused more on the session fsm part so we can separate the "peer-to-peer transport" aspect and not use its current behavior as a justification to change the session fsm side. The current session fsm seems to function in a traditional client/server way where application specific conversations are always client initiated. I cannot speak for why 3GPP or other apps does not follow this and they may gave good technical reasons for doing so. In any case, we can probably sub-divide the discussion into two(2) issues (this includes discussions in other threads): 1. where the first app specific exchange is initiated by the server - I still have doubts about this since this maybe solved by other means such as having the "application server" create diameter client sessions to initiate a conversation. 2. where subsequent app specific exchanges are initiated by the server - this maybe acceptable in stateful sessions where applications may need similar msg exchange behavior like RAR. However, for stateless sessions, this not applicable and solutions becomes similar to (1). I hope more folks can add their input to this so we can move forward more quickly on this issue. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue May 29 09:24:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1gd-0004A9-CX; Tue, 29 May 2007 09:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1gc-00049y-3v for dime@ietf.org; Tue, 29 May 2007 09:24:30 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht1gZ-0005dO-LY for dime@ietf.org; Tue, 29 May 2007 09:24:30 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l4TDNsVG088577; Tue, 29 May 2007 09:23:54 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <465C296A.1090706@tari.toshiba.com> Date: Tue, 29 May 2007 09:23:54 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601680A5D@CHN-HCLT-EVS02.HCLT.CO RP.HCL.IN> <66E8AEE9980BB44CA5FCAD39EBA56AC601680B80@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601680B80@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, The current discussion has been recorded in issue 53 of diameter base issue tracker (http://www.tschofenig.priv.at:8080/diameter-interop/index). regards, victor > Hi Bala, > > Open RAR Received Send RAA Open > with invalid session with > parameters. Result-Code > = SUCCESS, > For the above said State I think The state should be "Idle" Since > the RAR received is with Invalid session Parameter Pls. refer section > 8.3 in RFC 3588 It says that the RAR received should have the correct > session-Id that is in Progress. And also the result code should have > UNKNOWN_SESSION_ID rather than SUCCESS. > > Thx > -Arun > > > > -----Original Message----- > From: Balamurugan T, TLS-Chennai [mailto:tbalamurugan@hcl.in] > Sent: Saturday, May 26, 2007 10:01 AM > To: Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Clarification on Auth Server state machine > > Hi Victor, > > The following state table entries should be added in Auth client FSM for > RAR support. > > ===================================================================== > State Event Action New State > ===================================================================== > Idle RAR Received Send RAA Idle > for unknown session with > Result-Code > = UNKNOWN_ > SESSION_ID > > Open RAR Received Send RAA Open > with valid session with > parameters. Result-Code > = SUCCESS, > > Open RAR Received Send RAA Open > with invalid session with > parameters. Result-Code > = SUCCESS, > ====================================================================== > > Please add your comments if I missed some points. > > Regards, > Bala > > > > > > > > > > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Friday, May 25, 2007 4:34 AM > To: Balamurugan T, TLS-Chennai > Cc: dime@ietf.org > Subject: Re: [Dime] Clarification on Auth Server state machine > > > It seems ok to me, maybe some folks have comments as well. Also, the > client side may also need to be defined. > > --victor > > >> Hello! Victor, >> >> Thanks for the reply. Please suggest if it is correct to add the >> following additional state table entries to the "SERVER state full >> AUTH FSM" to add support for sending RAR and any other service >> specific requests initiation from server. >> >> Current State >> >> >> >> Event >> >> >> >> Action >> >> >> >> New State >> >> Open >> >> >> >> Home server wants to confirm authorization of the user >> >> >> >> Send RAR >> >> >> >> Open >> >> Open >> >> >> >> Received RAA with some failure result code. >> >> >> >> Cleanup >> >> >> >> idle >> >> Open >> >> >> >> Received RAA with successful result code. >> >> >> >> Update the session >> >> >> >> Open >> >> Open >> >> >> >> RAR sent failed >> >> >> >> resend RAR >> >> >> >> Open >> >> Thanks and Regards >> >> Bala >> >> -----Original Message----- >> >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> >> Sent: Wednesday, May 23, 2007 9:44 PM >> >> To: Balamurugan T, TLS-Chennai >> >> Cc: dime@ietf.org >> >> Subject: Re: [Dime] Clarification on Auth Server state machine >> >> Hi, >> >> > As per RFC3588, The diameter server will send the RAR request to >> >> > diameter client.But, In AUTH SERVER state machine >> >> > there is no state table entry to send Service specific requests >> >> > from server. Also Sh,GqGo interfaces send some request >> >> > >> >> Maybe we can separate your comments into two(2). First, RARs are >> > not > >> depicted in the stateful auth fsms. This should probably be fixed >> > if > >> this is the case. Second, I'm not sure that we should not consider >> RAR >> >> as "service specific requests". AFAIK, service specific request >> > sent > >> from the server is currently not allowed unless the server entity >> > is > >> generating a diameter client session. There are ongoing >> > discussions > >> about this topic in other threads (Qos). >> >> regards, >> >> victor >> >> > messages from server. >> >> > >> >> > Can you please clarify this contradiction in RFC. >> >> > >> >> > Regards, >> >> > Bala >> >> > >> >> > >> > ------------------------------------------------------------------------ > >> > >> >> > DISCLAIMER: >> >> > >> > ------------------------------------------------------------------------ > ----------------------------------------------- > >> > >> >> > The contents of this e-mail and any attachment(s) are >> confidential and intended for the named recipient(s) only. >> >> > It shall not attach any liability on the originator or HCL or >> > its > >> affiliates. Any views or opinions presented in >> >> > this email are solely those of the author and may not >> > necessarily > >> reflect the opinions of HCL or its affiliates. >> >> > Any form of reproduction, dissemination, copying, disclosure, >> modification, distribution and / or publication of >> >> > this message without the prior written consent of the author of >> this e-mail is strictly prohibited. If you have >> >> > received this email in error please delete it and notify the >> sender immediately. Before opening any mail and >> >> > attachments please check them for viruses and defect. >> >> > >> >> > >> > ------------------------------------------------------------------------ > ----------------------------------------------- > >> > >> > ------------------------------------------------------------------------ > >> > >> >> > _______________________________________________ >> >> > DiME mailing list >> >> > DiME@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/dime >> >> > >> >> _______________________________________________ >> >> DiME mailing list >> >> DiME@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue May 29 09:51:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht272-000272-8T; Tue, 29 May 2007 09:51:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht271-00026x-AI for dime@ietf.org; Tue, 29 May 2007 09:51:47 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ht26z-00038e-LB for dime@ietf.org; Tue, 29 May 2007 09:51:47 -0400 Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l4TDpjfF016708 for ; Tue, 29 May 2007 09:51:45 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 09:51:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Clarification on Auth Server state machine Date: Tue, 29 May 2007 09:51:45 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702E0F0@sonusmail04.sonusnet.com> In-Reply-To: <465C2801.5050201@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: Aceh899M11/pdJ+gRJq6/vKoHKidbAAAsVmw References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com><1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 29 May 2007 13:51:45.0422 (UTC) FILETIME=[7EC612E0:01C7A1F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor/Manuel, Please see below for comments. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Tuesday, May 29, 2007 9:18 AM > To: "\"Miguel A.\" Nu=F1ez" > Cc: dime@ietf.org > Subject: Re: [Dime] Clarification on Auth Server state machine >=20 > Hi Miguel, >=20 > Comments inline: >=20 > > > > I have checked auth stateful server fsm at rfc 3588 and in fact it > > does not allow to send service specific requests. > > > > Checking the auth stateless server fsm, it neither allows to send > > service specific requests. This is a bit surprising because i.e. Sh > > interface servers, that work in stateless mode, can send PNR = requests. > > > > This seems to be against the spirit of diameter being a peer-to-peer > > protocol from a transport point of view. Although peers are simetric > > from a transport point of view, servers cannot send requests (except > > ASR as per the fsm). And more, there is a contradiction between RFC > > 3588 and some 3GPP specs. >=20 > I guess we can also consider diameter as a two(2) part protocol where > the peer fsm is the peer-to-peer part and the sessions fsm is the > client/server application part. The current discussion is focused more > on the session fsm part so we can separate the "peer-to-peer = transport" > aspect and not use its current behavior as a justification to change = the > session fsm side. [TOLGA]I completely agree with this approach. Furthermore, we should = consider that Diameter base protocol functionality is used by many = different applications. Some of these are using Diameter as a transport = mechanism. IMHO, there is nothing wrong with that. Diameter base = protocol provides a nice networking layer and a mechanism to carry = different types of data in an efficient manner. So, it actually is a = really good choice. OTOH, using Diameter base protocol in such a way = means that an application, which is not an authentication/authorization = application per se, should define its own state machine rules. 3GPP Sh = interface is a good example for that. It is used to download/update user = profile between CSCF/HSS. The expected behavior is defined in relevant = 3GPP specifications, so I don't see why that message exchange should be = compliant with authentication/authorization state machine defined in = RFC3588. Similarly, I even don't see why it shouldn't be possible to = extend/modify authentication/authorization state machines defined in = RFC3588 in a different document, e.g. a 3GPP specification, as long as = this is a different application with a unique Application-Id. >=20 > The current session fsm seems to function in a traditional = client/server > way where application specific conversations are always client > initiated. I cannot speak for why 3GPP or other apps does not follow > this and they may gave good technical reasons for doing so. In any = case, > we can probably sub-divide the discussion into two(2) issues (this > includes discussions in other threads): >=20 > 1. where the first app specific exchange is initiated by the server - = I > still have doubts about this since this maybe solved by other means = such > as having the "application server" create diameter client sessions to > initiate a conversation. [TOLGA]I agree with this one as well. It is possible I am missing = something, but somebody should explain with an example why this is = technically such a bad thing. > 2. where subsequent app specific exchanges are initiated by the server = - > this maybe acceptable in stateful sessions where applications may need > similar msg exchange behavior like RAR. However, for stateless = sessions, > this not applicable and solutions becomes similar to (1). [TOLGA]Agreed. >=20 > I hope more folks can add their input to this so we can move forward > more quickly on this issue. >=20 > best regards, > victor >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue May 29 16:09:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht80a-0001fo-MY; Tue, 29 May 2007 16:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht80Z-0001fa-Qi for dime@ietf.org; Tue, 29 May 2007 16:09:31 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht80X-0005Ui-R0 for dime@ietf.org; Tue, 29 May 2007 16:09:31 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l4TK9Sgg021118 for ; Tue, 29 May 2007 22:09:28 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l4TK9SgU029893 for ; Tue, 29 May 2007 22:09:28 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 22:09:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 May 2007 22:09:27 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701BB3948@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG: I-D ACTION:draft-zorn-dime-diameter-base-protocol-mib-02.txt Thread-Index: AceiLUJVI0KOUv/3TXaQ8vumEX/e2A== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 29 May 2007 20:09:29.0094 (UTC) FILETIME=[435FFA60:01C7A22D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Dime] WG: I-D ACTION:draft-zorn-dime-diameter-base-protocol-mib-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org FYI -----Urspr=FCngliche Nachricht----- Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Gesendet: Dienstag, 29. Mai 2007 21:50 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-zorn-dime-diameter-base-protocol-mib-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Diameter Base Protocol MIB Author(s) : S. Comerica, G. Zorn Filename : draft-zorn-dime-diameter-base-protocol-mib-02.txt Pages : 53 Date : 2007-5-29 =09 Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zorn-dime-diameter-base-protoco= l-mib-02.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-zorn-dime-diameter-base-protocol-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-zorn-dime-diameter-base-protocol-mib-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 07:17:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtMB7-0006UY-5K; Wed, 30 May 2007 07:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtMB5-0006TJ-TS for dime@ietf.org; Wed, 30 May 2007 07:17:19 -0400 Received: from correo14.acens.net ([217.116.0.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtMB2-0005Nz-RP for dime@ietf.org; Wed, 30 May 2007 07:17:19 -0400 Received: (qmail 21988 invoked from network); 30 May 2007 11:17:15 -0000 Received: from unknown (HELO [192.168.1.21]) (miguel.nunez.mantica-solutions.com@[85.52.193.241]) (envelope-sender ) by correo14.acens.net (qmail-ldap-1.03) with SMTP for ; 30 May 2007 11:17:15 -0000 Subject: Re: [Dime] Clarification on Auth Server state machine From: "Miguel A." =?ISO-8859-1?Q?Nu=F1ez?= To: Victor Fajardo In-Reply-To: <465C2801.5050201@tari.toshiba.com> References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> Organization: Mantica Solutions S.L. Date: Wed, 30 May 2007 13:17:16 +0200 Message-Id: <1180523836.6206.227.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Spam-Score: 0.5 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0399693732==" Errors-To: dime-bounces@ietf.org --===============0399693732== Content-Type: multipart/alternative; boundary="=-AiyGfXESvR1YSaTz+a4V" --=-AiyGfXESvR1YSaTz+a4V Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Victor, Ok. Let's try to move forward. Let me first explain the sh case. I don't want to turn this into a 3gpp issue, but just use this case as an example of an application that uses the services provided by diameter base. We can try to discuss about the flexibility of diameter based on this example. Sh interface allows an AS to subscribe to modifications of a user's profile at the HSS. The dialogue begins by sending SNR, so AS gets subscribed to any specific field modifications. Whenever that modification happens, HSS sends PNR to notify about it. In all this scenario, by the moment, we will consider HSS is a diameter server and AS is a diameter client. Now please see my comments below, having in mind this use case. Best regards, Miguel Angel On mar, 2007-05-29 at 09:17 -0400, Victor Fajardo wrote: > Hi Miguel, > > Comments inline: > > > > > I have checked auth stateful server fsm at rfc 3588 and in fact it > > does not allow to send service specific requests. > > > > Checking the auth stateless server fsm, it neither allows to send > > service specific requests. This is a bit surprising because i.e. Sh > > interface servers, that work in stateless mode, can send PNR requests. > > > > This seems to be against the spirit of diameter being a peer-to-peer > > protocol from a transport point of view. Although peers are simetric > > from a transport point of view, servers cannot send requests (except > > ASR as per the fsm). And more, there is a contradiction between RFC > > 3588 and some 3GPP specs. > > I guess we can also consider diameter as a two(2) part protocol where > the peer fsm is the peer-to-peer part and the sessions fsm is the > client/server application part. The current discussion is focused more > on the session fsm part so we can separate the "peer-to-peer transport" > aspect and not use its current behavior as a justification to change the > session fsm side. > [MIG] I agree. > The current session fsm seems to function in a traditional client/server > way where application specific conversations are always client > initiated. I cannot speak for why 3GPP or other apps does not follow > this and they may gave good technical reasons for doing so. In any case, > we can probably sub-divide the discussion into two(2) issues (this > includes discussions in other threads): > > 1. where the first app specific exchange is initiated by the server - I > still have doubts about this since this maybe solved by other means such > as having the "application server" create diameter client sessions to > initiate a conversation. > 2. where subsequent app specific exchanges are initiated by the server - > this maybe acceptable in stateful sessions where applications may need > similar msg exchange behavior like RAR. However, for stateless sessions, > this not applicable and solutions becomes similar to (1). [MIG] The sh case fits well in the stateful model. All subscription messages are related to the same user, so it seems the most logic way to have all them into the same diameter session. If we try to create diameter client sessions, it implies to have the HSS acting first as diameter server and afterward as diameter client, creating a new session for a message exchange completely related to the previous one. You will have two sessions mixed all along the subscription duration (the subscription ends by sending another SNR that should be in the same session as the first SNR), being both sessions related to same subscription. Not a nice way to do things. In practice, this subscription dialogues can last for days, even months. >From an implementation point of view, you get almost obliged to use a stateless mode. And taking into consideration the other message exchanges that can happen at sh interface (UDR and PUR), they are profile downloads and updates, so it makes sense to do both in stateless mode. As a result, the whole sh becomes stateless, even if subscriptions should be stateful from a pure conceptual point of view. I would like diameter to be flexible enough to fit for this kind of applications, and allow servers to send requests at least in stateful mode. It would be even greater to have a completely flexible protocol that allows transaction exchanges whenever applications need them. There are protocols that work in this way. I can see that sh is not the only case (checking ITU-T Liason at http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) Someone should really explain me why it is so great to have a session layer with the limitations of a client-server model, when having available a great tranport layer without them. I would really like to see a list of advantages related to the client-server model. If folks provide good reasons, I will be more than happy to recognize that it is the model that better fits. In any case, I encourage folks to discuss models providing maximum flexibility. > > I hope more folks can add their input to this so we can move forward > more quickly on this issue. > > best regards, > victor > > --=-AiyGfXESvR1YSaTz+a4V Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Victor,

Ok. Let's try to move forward.

Let me first explain the sh case. I don't want to turn this into a 3gpp issue, but just use this case as an example of an application that uses the services provided by diameter base. We can try to discuss about the flexibility of diameter based on this example.

Sh interface allows an AS to subscribe to modifications of a user's profile at the HSS. The dialogue begins by sending SNR, so AS gets subscribed to any specific field modifications. Whenever that modification happens, HSS sends PNR to notify about it. In all this scenario, by the moment, we will consider HSS is a diameter server and AS is a diameter client.

Now please see my comments below, having in mind this use case.


Best regards,
Miguel Angel



On mar, 2007-05-29 at 09:17 -0400, Victor Fajardo wrote: 
Hi Miguel,

Comments inline:

>
> I have checked auth stateful server fsm at rfc 3588 and in fact it 
> does not allow to send service specific requests.
>
> Checking the auth stateless server fsm, it neither allows to send 
> service specific requests. This is a bit surprising because i.e. Sh 
> interface servers, that work in stateless mode, can send PNR requests.
>
> This seems to be against the spirit of diameter being a peer-to-peer 
> protocol from a transport point of view. Although peers are simetric 
> from a transport point of view, servers cannot send requests (except 
> ASR as per the fsm). And more, there is a contradiction between RFC 
> 3588 and some 3GPP specs.

I guess we can also consider diameter as a two(2) part protocol where 
the peer fsm is the peer-to-peer part and the sessions fsm is the 
client/server application part. The current discussion is focused more 
on the session fsm part so we can separate the "peer-to-peer transport" 
aspect and not use its current behavior as a justification to change the 
session fsm side.
[MIG] I agree.

The current session fsm seems to function in a traditional client/server 
way where application specific conversations are always client 
initiated. I cannot speak for why 3GPP or other apps does not follow 
this and they may gave good technical reasons for doing so. In any case, 
we can probably sub-divide the discussion into two(2) issues (this 
includes discussions in other threads):

1. where the first app specific exchange is initiated by the server - I 
still have doubts about this since this maybe solved by other means such 
as having the "application server" create diameter client sessions to 
initiate a conversation.
2. where subsequent app specific exchanges are initiated by the server - 
this maybe acceptable in stateful sessions where applications may need 
similar msg exchange behavior like RAR. However, for stateless sessions, 
this not applicable and solutions becomes similar to (1).
[MIG] The sh case fits well in the stateful model. All subscription messages are related to the same user, so it seems the most logic way to have all them into the same diameter session.

If we try to create diameter client sessions, it implies to have the HSS acting first as diameter server and afterward as diameter client, creating a new session for a message exchange completely related to the previous one. You will have two sessions mixed all along the subscription duration (the subscription ends by sending another SNR that should be in the same session as the first SNR), being both sessions related to same subscription. Not a nice way to do things.

In practice, this subscription dialogues can last for days, even months. From an implementation point of view, you get almost obliged to use a stateless mode. And taking into consideration the other message exchanges that can happen at sh interface (UDR and PUR), they are profile downloads and updates, so it makes sense to do both in stateless mode. As a result, the whole sh becomes stateless, even if subscriptions should be stateful from a pure conceptual point of view.

I would like diameter to be flexible enough to fit for this kind of applications, and allow servers to send requests at least in stateful mode. It would be even greater to have a completely flexible protocol that allows transaction exchanges whenever applications need them. There are protocols that work in this way. I can see that sh is not the only case (checking ITU-T Liason at http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap)

Someone should really explain me why it is so great to have a session layer with the limitations of a client-server model, when having available a great tranport layer without them.

I would really like to see a list of advantages related to the client-server model. If folks provide good reasons, I will be more than happy to recognize that it is the model that better fits. In any case, I encourage folks to discuss models providing maximum flexibility.



I hope more folks can add their input to this so we can move forward 
more quickly on this issue.

best regards,
victor
--=-AiyGfXESvR1YSaTz+a4V-- --===============0399693732== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0399693732==-- From dime-bounces@ietf.org Wed May 30 08:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtN4y-0004Hv-4v; Wed, 30 May 2007 08:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtMzp-0002b5-6Z for dime@ietf.org; Wed, 30 May 2007 08:09:45 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtMzo-0006f9-FB for dime@ietf.org; Wed, 30 May 2007 08:09:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UC9Gh5011844; Wed, 30 May 2007 15:09:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:09:28 +0300 Received: from esebe107.NOE.Nokia.com ([172.21.143.89]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:09:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Clarification on Auth Server state machine Date: Wed, 30 May 2007 15:09:25 +0300 Message-ID: <165947868C470B4889510CCB51416F6D023C5D4C@esebe107.NOE.Nokia.com> In-Reply-To: <1180523836.6206.227.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: AceirETEo2Lp2HQXRO6mFpfKeNsHmgAA6D7w References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN><46546853.7000702@tari.toshiba.com><1180441076.6206.112.camel@localhost.localdomain><465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> From: To: , , X-OriginalArrivalTime: 30 May 2007 12:09:27.0916 (UTC) FILETIME=[5EF2BAC0:01C7A2B3] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-Mailman-Approved-At: Wed, 30 May 2007 08:15:02 -0400 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > [MIG] The sh case fits well in the stateful model. All=20 > subscription messages are related to the same user, so it=20 > seems the most logic way to have all them into the same=20 > diameter session. > In practice, this subscription dialogues can last for days,=20 > even months. From an implementation point of view, you get=20 > almost obliged to use a stateless mode. And taking into=20 > consideration the other message exchanges that can happen at=20 > sh interface (UDR and PUR), they are profile downloads and=20 > updates, so it makes sense to do both in stateless mode. As a=20 > result, the whole sh becomes stateless, even if subscriptions=20 > should be stateful from a pure conceptual point of view. FYI, Sh spec 3GPP TS 29.329 states: "Whenever the definition and use of an AVP is not specified in this document, what is stated in 3GPP TS 29.229 [6] shall apply." 3GPP TS 29.229 in turn states: "The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 3588 [6]." So if you feel you need to clarify the state-machines in IETF RFC 3588 for the purposes of 3GPP Sh interface functionality, it would seem that the relevant state-machines in 3588 for Sh are 'CLIENT, STATELESS' and 'SERVER, STATELESS'. On the other hand, do we need to define a state machine at all for supposedly stateless operation? Best Regards, Mikko Aittola > -----Original Message----- > From: ext Nu=F1ez [mailto:miguel.nunez@mantica-solutions.com]=20 > Sent: 30 May, 2007 14:17 > To: Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] Clarification on Auth Server state machine >=20 > Hi Victor, >=20 > Ok. Let's try to move forward. >=20 > Let me first explain the sh case. I don't want to turn this=20 > into a 3gpp issue, but just use this case as an example of an=20 > application that uses the services provided by diameter base.=20 > We can try to discuss about the flexibility of diameter based=20 > on this example. >=20 > Sh interface allows an AS to subscribe to modifications of a=20 > user's profile at the HSS. The dialogue begins by sending=20 > SNR, so AS gets subscribed to any specific field=20 > modifications. Whenever that modification happens, HSS sends=20 > PNR to notify about it. In all this scenario, by the moment,=20 > we will consider HSS is a diameter server and AS is a diameter client. >=20 > Now please see my comments below, having in mind this use case. >=20 >=20 > Best regards, > Miguel Angel >=20 >=20 >=20 > On mar, 2007-05-29 at 09:17 -0400, Victor Fajardo wrote:=20 >=20 > Hi Miguel, > =09 > Comments inline: > =09 > > > > I have checked auth stateful server fsm at rfc 3588=20 > and in fact it=20 > > does not allow to send service specific requests. > > > > Checking the auth stateless server fsm, it neither=20 > allows to send=20 > > service specific requests. This is a bit surprising=20 > because i.e. Sh=20 > > interface servers, that work in stateless mode, can=20 > send PNR requests. > > > > This seems to be against the spirit of diameter being=20 > a peer-to-peer=20 > > protocol from a transport point of view. Although=20 > peers are simetric=20 > > from a transport point of view, servers cannot send=20 > requests (except=20 > > ASR as per the fsm). And more, there is a=20 > contradiction between RFC=20 > > 3588 and some 3GPP specs. > =09 > I guess we can also consider diameter as a two(2) part=20 > protocol where=20 > the peer fsm is the peer-to-peer part and the sessions=20 > fsm is the=20 > client/server application part. The current discussion=20 > is focused more=20 > on the session fsm part so we can separate the=20 > "peer-to-peer transport"=20 > aspect and not use its current behavior as a=20 > justification to change the=20 > session fsm side. > =09 > =09 >=20 > [MIG] I agree. >=20 >=20 >=20 > The current session fsm seems to function in a=20 > traditional client/server=20 > way where application specific conversations are always client=20 > initiated. I cannot speak for why 3GPP or other apps=20 > does not follow=20 > this and they may gave good technical reasons for doing=20 > so. In any case,=20 > we can probably sub-divide the discussion into two(2)=20 > issues (this=20 > includes discussions in other threads): > =09 > 1. where the first app specific exchange is initiated=20 > by the server - I=20 > still have doubts about this since this maybe solved by=20 > other means such=20 > as having the "application server" create diameter=20 > client sessions to=20 > initiate a conversation. > 2. where subsequent app specific exchanges are=20 > initiated by the server -=20 > this maybe acceptable in stateful sessions where=20 > applications may need=20 > similar msg exchange behavior like RAR. However, for=20 > stateless sessions,=20 > this not applicable and solutions becomes similar to (1). > =09 >=20 > [MIG] The sh case fits well in the stateful model. All=20 > subscription messages are related to the same user, so it=20 > seems the most logic way to have all them into the same=20 > diameter session. >=20 > If we try to create diameter client sessions, it implies to=20 > have the HSS acting first as diameter server and afterward as=20 > diameter client, creating a new session for a message=20 > exchange completely related to the previous one. You will=20 > have two sessions mixed all along the subscription duration=20 > (the subscription ends by sending another SNR that should be=20 > in the same session as the first SNR), being both sessions=20 > related to same subscription. Not a nice way to do things. >=20 > In practice, this subscription dialogues can last for days,=20 > even months. From an implementation point of view, you get=20 > almost obliged to use a stateless mode. And taking into=20 > consideration the other message exchanges that can happen at=20 > sh interface (UDR and PUR), they are profile downloads and=20 > updates, so it makes sense to do both in stateless mode. As a=20 > result, the whole sh becomes stateless, even if subscriptions=20 > should be stateful from a pure conceptual point of view. >=20 > I would like diameter to be flexible enough to fit for this=20 > kind of applications, and allow servers to send requests at=20 > least in stateful mode. It would be even greater to have a=20 > completely flexible protocol that allows transaction=20 > exchanges whenever applications need them. There are=20 > protocols that work in this way. I can see that sh is not the=20 > only case (checking ITU-T Liason at=20 > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) >=20 > Someone should really explain me why it is so great to have a=20 > session layer with the limitations of a client-server model,=20 > when having available a great tranport layer without them. >=20 > I would really like to see a list of advantages related to=20 > the client-server model. If folks provide good reasons, I=20 > will be more than happy to recognize that it is the model=20 > that better fits. In any case, I encourage folks to discuss=20 > models providing maximum flexibility. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 08:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtN4x-0004Hr-Vi; Wed, 30 May 2007 08:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoi0v-0000Jo-IZ for dime@ietf.org; Thu, 17 May 2007 11:35:37 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoi0t-0005Xs-SZ for dime@ietf.org; Thu, 17 May 2007 11:35:37 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 486E720A51; Thu, 17 May 2007 17:35:35 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-db-464c7647888c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3F687203EA; Thu, 17 May 2007 17:35:35 +0200 (CEST) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 17:35:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Integer32 encoding Date: Thu, 17 May 2007 17:35:33 +0200 Message-ID: <63A23507A6F0C344BE6D60303E9441D901B268C4@esealmw114.eemea.ericsson.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301D8146D@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Integer32 encoding Thread-Index: AceGXrMqJsEZvVOpTqG/XO94eH5GEQSMUlkwAAGbjaA= References: <63A23507A6F0C344BE6D60303E9441D90181A578@esealmw114.eemea.ericsson.se> <59D7431DE2527D4CB0F1EFEDA5683ED301D8146D@SEHAN021MB.tcad.telia.se> From: "Roland Gecse \(IJ/ETH\)" To: , X-OriginalArrivalTime: 17 May 2007 15:35:35.0055 (UTC) FILETIME=[02F7A1F0:01C79899] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 30 May 2007 08:15:02 -0400 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, first of all thanks for your mail. I had also the 1st idea to use two's complement representation of 32bits integer but this is _not_ explicitly stated in the RFC. There are a number of representations of signed numbers. OK, two's complement is the most common. But RFC3588 does not regulate this, so I could also use one's complement, sign-bit and magnitude or excess-(2^31-1) representation as common with some other protocols and still have a conforming implementation that most likely would not be able to interwork properly. I believe a clarification would be worth-while --- that's why the question. Roland. > -----Original Message----- > From: jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com]=20 > Sent: Thursday, May 17, 2007 16:36 > To: Roland Gecse (IJ/ETH); dime@ietf.org > Subject: RE: [Dime] Integer32 encoding >=20 > Hi Roland, >=20 > Section 4.2. in RFC3588 says that Integer32 is a 32 bit=20 > _signed_ value, in network byte order. So the highest bit in=20 > the value defines the sign just like in normal signed integer=20 > arithmetic. >=20 > E.g. 0x80000000 would be negative whereas 0x7fffffff would be=20 > positive. >=20 > Cheers, > Jouni >=20 > > -----Original Message----- > > From: Roland Gecse (IJ/ETH) [mailto:roland.gecse@ericsson.com] > > Sent: Tuesday, April 24, 2007 1:53 PM > > To: dime@ietf.org > > Subject: [Dime] Integer32 encoding > >=20 > > Dear DIME Members, > >=20 > > I would be glad if someone could answer my question:=20 > >=20 > > Where does the diameter base protocol specify how to encode=20 > a negative > > Integer32 AVP value? > >=20 > > Please CC replies directly to my e-mail address, as I am not=20 > > subscribed to this mailing list. > >=20 > > Regards, > > Roland. > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 08:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtN4y-0004Hv-4v; Wed, 30 May 2007 08:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtMzp-0002b5-6Z for dime@ietf.org; Wed, 30 May 2007 08:09:45 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtMzo-0006f9-FB for dime@ietf.org; Wed, 30 May 2007 08:09:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UC9Gh5011844; Wed, 30 May 2007 15:09:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:09:28 +0300 Received: from esebe107.NOE.Nokia.com ([172.21.143.89]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:09:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Clarification on Auth Server state machine Date: Wed, 30 May 2007 15:09:25 +0300 Message-ID: <165947868C470B4889510CCB51416F6D023C5D4C@esebe107.NOE.Nokia.com> In-Reply-To: <1180523836.6206.227.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: AceirETEo2Lp2HQXRO6mFpfKeNsHmgAA6D7w References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN><46546853.7000702@tari.toshiba.com><1180441076.6206.112.camel@localhost.localdomain><465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> From: To: , , X-OriginalArrivalTime: 30 May 2007 12:09:27.0916 (UTC) FILETIME=[5EF2BAC0:01C7A2B3] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-Mailman-Approved-At: Wed, 30 May 2007 08:15:02 -0400 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, > [MIG] The sh case fits well in the stateful model. All=20 > subscription messages are related to the same user, so it=20 > seems the most logic way to have all them into the same=20 > diameter session. > In practice, this subscription dialogues can last for days,=20 > even months. From an implementation point of view, you get=20 > almost obliged to use a stateless mode. And taking into=20 > consideration the other message exchanges that can happen at=20 > sh interface (UDR and PUR), they are profile downloads and=20 > updates, so it makes sense to do both in stateless mode. As a=20 > result, the whole sh becomes stateless, even if subscriptions=20 > should be stateful from a pure conceptual point of view. FYI, Sh spec 3GPP TS 29.329 states: "Whenever the definition and use of an AVP is not specified in this document, what is stated in 3GPP TS 29.229 [6] shall apply." 3GPP TS 29.229 in turn states: "The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 3588 [6]." So if you feel you need to clarify the state-machines in IETF RFC 3588 for the purposes of 3GPP Sh interface functionality, it would seem that the relevant state-machines in 3588 for Sh are 'CLIENT, STATELESS' and 'SERVER, STATELESS'. On the other hand, do we need to define a state machine at all for supposedly stateless operation? Best Regards, Mikko Aittola > -----Original Message----- > From: ext Nu=F1ez [mailto:miguel.nunez@mantica-solutions.com]=20 > Sent: 30 May, 2007 14:17 > To: Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] Clarification on Auth Server state machine >=20 > Hi Victor, >=20 > Ok. Let's try to move forward. >=20 > Let me first explain the sh case. I don't want to turn this=20 > into a 3gpp issue, but just use this case as an example of an=20 > application that uses the services provided by diameter base.=20 > We can try to discuss about the flexibility of diameter based=20 > on this example. >=20 > Sh interface allows an AS to subscribe to modifications of a=20 > user's profile at the HSS. The dialogue begins by sending=20 > SNR, so AS gets subscribed to any specific field=20 > modifications. Whenever that modification happens, HSS sends=20 > PNR to notify about it. In all this scenario, by the moment,=20 > we will consider HSS is a diameter server and AS is a diameter client. >=20 > Now please see my comments below, having in mind this use case. >=20 >=20 > Best regards, > Miguel Angel >=20 >=20 >=20 > On mar, 2007-05-29 at 09:17 -0400, Victor Fajardo wrote:=20 >=20 > Hi Miguel, > =09 > Comments inline: > =09 > > > > I have checked auth stateful server fsm at rfc 3588=20 > and in fact it=20 > > does not allow to send service specific requests. > > > > Checking the auth stateless server fsm, it neither=20 > allows to send=20 > > service specific requests. This is a bit surprising=20 > because i.e. Sh=20 > > interface servers, that work in stateless mode, can=20 > send PNR requests. > > > > This seems to be against the spirit of diameter being=20 > a peer-to-peer=20 > > protocol from a transport point of view. Although=20 > peers are simetric=20 > > from a transport point of view, servers cannot send=20 > requests (except=20 > > ASR as per the fsm). And more, there is a=20 > contradiction between RFC=20 > > 3588 and some 3GPP specs. > =09 > I guess we can also consider diameter as a two(2) part=20 > protocol where=20 > the peer fsm is the peer-to-peer part and the sessions=20 > fsm is the=20 > client/server application part. The current discussion=20 > is focused more=20 > on the session fsm part so we can separate the=20 > "peer-to-peer transport"=20 > aspect and not use its current behavior as a=20 > justification to change the=20 > session fsm side. > =09 > =09 >=20 > [MIG] I agree. >=20 >=20 >=20 > The current session fsm seems to function in a=20 > traditional client/server=20 > way where application specific conversations are always client=20 > initiated. I cannot speak for why 3GPP or other apps=20 > does not follow=20 > this and they may gave good technical reasons for doing=20 > so. In any case,=20 > we can probably sub-divide the discussion into two(2)=20 > issues (this=20 > includes discussions in other threads): > =09 > 1. where the first app specific exchange is initiated=20 > by the server - I=20 > still have doubts about this since this maybe solved by=20 > other means such=20 > as having the "application server" create diameter=20 > client sessions to=20 > initiate a conversation. > 2. where subsequent app specific exchanges are=20 > initiated by the server -=20 > this maybe acceptable in stateful sessions where=20 > applications may need=20 > similar msg exchange behavior like RAR. However, for=20 > stateless sessions,=20 > this not applicable and solutions becomes similar to (1). > =09 >=20 > [MIG] The sh case fits well in the stateful model. All=20 > subscription messages are related to the same user, so it=20 > seems the most logic way to have all them into the same=20 > diameter session. >=20 > If we try to create diameter client sessions, it implies to=20 > have the HSS acting first as diameter server and afterward as=20 > diameter client, creating a new session for a message=20 > exchange completely related to the previous one. You will=20 > have two sessions mixed all along the subscription duration=20 > (the subscription ends by sending another SNR that should be=20 > in the same session as the first SNR), being both sessions=20 > related to same subscription. Not a nice way to do things. >=20 > In practice, this subscription dialogues can last for days,=20 > even months. From an implementation point of view, you get=20 > almost obliged to use a stateless mode. And taking into=20 > consideration the other message exchanges that can happen at=20 > sh interface (UDR and PUR), they are profile downloads and=20 > updates, so it makes sense to do both in stateless mode. As a=20 > result, the whole sh becomes stateless, even if subscriptions=20 > should be stateful from a pure conceptual point of view. >=20 > I would like diameter to be flexible enough to fit for this=20 > kind of applications, and allow servers to send requests at=20 > least in stateful mode. It would be even greater to have a=20 > completely flexible protocol that allows transaction=20 > exchanges whenever applications need them. There are=20 > protocols that work in this way. I can see that sh is not the=20 > only case (checking ITU-T Liason at=20 > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) >=20 > Someone should really explain me why it is so great to have a=20 > session layer with the limitations of a client-server model,=20 > when having available a great tranport layer without them. >=20 > I would really like to see a list of advantages related to=20 > the client-server model. If folks provide good reasons, I=20 > will be more than happy to recognize that it is the model=20 > that better fits. In any case, I encourage folks to discuss=20 > models providing maximum flexibility. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 08:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtN4x-0004Hr-Vi; Wed, 30 May 2007 08:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoi0v-0000Jo-IZ for dime@ietf.org; Thu, 17 May 2007 11:35:37 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoi0t-0005Xs-SZ for dime@ietf.org; Thu, 17 May 2007 11:35:37 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 486E720A51; Thu, 17 May 2007 17:35:35 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-db-464c7647888c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3F687203EA; Thu, 17 May 2007 17:35:35 +0200 (CEST) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 17:35:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Integer32 encoding Date: Thu, 17 May 2007 17:35:33 +0200 Message-ID: <63A23507A6F0C344BE6D60303E9441D901B268C4@esealmw114.eemea.ericsson.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301D8146D@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Integer32 encoding Thread-Index: AceGXrMqJsEZvVOpTqG/XO94eH5GEQSMUlkwAAGbjaA= References: <63A23507A6F0C344BE6D60303E9441D90181A578@esealmw114.eemea.ericsson.se> <59D7431DE2527D4CB0F1EFEDA5683ED301D8146D@SEHAN021MB.tcad.telia.se> From: "Roland Gecse \(IJ/ETH\)" To: , X-OriginalArrivalTime: 17 May 2007 15:35:35.0055 (UTC) FILETIME=[02F7A1F0:01C79899] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 30 May 2007 08:15:02 -0400 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, first of all thanks for your mail. I had also the 1st idea to use two's complement representation of 32bits integer but this is _not_ explicitly stated in the RFC. There are a number of representations of signed numbers. OK, two's complement is the most common. But RFC3588 does not regulate this, so I could also use one's complement, sign-bit and magnitude or excess-(2^31-1) representation as common with some other protocols and still have a conforming implementation that most likely would not be able to interwork properly. I believe a clarification would be worth-while --- that's why the question. Roland. > -----Original Message----- > From: jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com]=20 > Sent: Thursday, May 17, 2007 16:36 > To: Roland Gecse (IJ/ETH); dime@ietf.org > Subject: RE: [Dime] Integer32 encoding >=20 > Hi Roland, >=20 > Section 4.2. in RFC3588 says that Integer32 is a 32 bit=20 > _signed_ value, in network byte order. So the highest bit in=20 > the value defines the sign just like in normal signed integer=20 > arithmetic. >=20 > E.g. 0x80000000 would be negative whereas 0x7fffffff would be=20 > positive. >=20 > Cheers, > Jouni >=20 > > -----Original Message----- > > From: Roland Gecse (IJ/ETH) [mailto:roland.gecse@ericsson.com] > > Sent: Tuesday, April 24, 2007 1:53 PM > > To: dime@ietf.org > > Subject: [Dime] Integer32 encoding > >=20 > > Dear DIME Members, > >=20 > > I would be glad if someone could answer my question:=20 > >=20 > > Where does the diameter base protocol specify how to encode=20 > a negative > > Integer32 AVP value? > >=20 > > Please CC replies directly to my e-mail address, as I am not=20 > > subscribed to this mailing list. > >=20 > > Regards, > > Roland. > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 08:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNIv-0004ht-0A; Wed, 30 May 2007 08:29:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNIt-0004hd-UC for dime@ietf.org; Wed, 30 May 2007 08:29:28 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtNIt-0003En-FY for dime@ietf.org; Wed, 30 May 2007 08:29:27 -0400 Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l4UCTR3S026827 for ; Wed, 30 May 2007 08:29:27 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 08:29:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Clarification on Auth Server state machine Date: Wed, 30 May 2007 08:29:27 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702E0FC@sonusmail04.sonusnet.com> In-Reply-To: <165947868C470B4889510CCB51416F6D023C5D4C@esebe107.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: AceirETEo2Lp2HQXRO6mFpfKeNsHmgAA6D7wAAE79eA= References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN><46546853.7000702@tari.toshiba.com><1180441076.6206.112.camel@localhost.localdomain><465C2801.5050201@tari.toshiba.com><1180523836.6206.227.camel@localhost.localdomain> <165947868C470B4889510CCB51416F6D023C5D4C@esebe107.NOE.Nokia.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 30 May 2007 12:29:27.0280 (UTC) FILETIME=[29D32700:01C7A2B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org First of all, why does Sh use authorization state machine as defined in = RFC3588? There should have been a state machine defined specifically for = Sh. They probably thought that the existing authentication state machine = is similar to what they need.=20 I think, people should understand that if they define a new Diameter = application, and if that Diameter application is not an = extension/similar to an existing application (whose state machine they = can borrow), they need to define a state machine/semantics for it. If = there is a need for change, it is the corresponding 3GPP document IMHO. Thanks, Tolga=20 > -----Original Message----- > From: mikko.aittola@nsn.com [mailto:mikko.aittola@nsn.com] > Sent: Wednesday, May 30, 2007 8:09 AM > To: miguel.nunez@mantica-solutions.com; vfajardo@tari.toshiba.com; > dime@ietf.org > Subject: RE: [Dime] Clarification on Auth Server state machine >=20 > Hi, >=20 > > [MIG] The sh case fits well in the stateful model. All > > subscription messages are related to the same user, so it > > seems the most logic way to have all them into the same > > diameter session. >=20 > > In practice, this subscription dialogues can last for days, > > even months. From an implementation point of view, you get > > almost obliged to use a stateless mode. And taking into > > consideration the other message exchanges that can happen at > > sh interface (UDR and PUR), they are profile downloads and > > updates, so it makes sense to do both in stateless mode. As a > > result, the whole sh becomes stateless, even if subscriptions > > should be stateful from a pure conceptual point of view. >=20 > FYI, Sh spec 3GPP TS 29.329 states: > "Whenever the definition and use of an AVP is not specified > in this document, what is stated in 3GPP TS 29.229 [6] shall > apply." >=20 > 3GPP TS 29.229 in turn states: > "The client (server) shall include in its requests > (responses) the Auth-Session-State AVP set to the value > NO_STATE_MAINTAINED (1), as described in IETF RFC 3588 [6]." >=20 > So if you feel you need to clarify the state-machines in > IETF RFC 3588 for the purposes of 3GPP Sh interface functionality, > it would seem that the relevant state-machines in 3588 for Sh are > 'CLIENT, STATELESS' and 'SERVER, STATELESS'. >=20 > On the other hand, do we need to define a state machine at > all for supposedly stateless operation? >=20 >=20 > Best Regards, > Mikko Aittola >=20 >=20 > > -----Original Message----- > > From: ext Nu=F1ez [mailto:miguel.nunez@mantica-solutions.com] > > Sent: 30 May, 2007 14:17 > > To: Victor Fajardo > > Cc: dime@ietf.org > > Subject: Re: [Dime] Clarification on Auth Server state machine > > > > Hi Victor, > > > > Ok. Let's try to move forward. > > > > Let me first explain the sh case. I don't want to turn this > > into a 3gpp issue, but just use this case as an example of an > > application that uses the services provided by diameter base. > > We can try to discuss about the flexibility of diameter based > > on this example. > > > > Sh interface allows an AS to subscribe to modifications of a > > user's profile at the HSS. The dialogue begins by sending > > SNR, so AS gets subscribed to any specific field > > modifications. Whenever that modification happens, HSS sends > > PNR to notify about it. In all this scenario, by the moment, > > we will consider HSS is a diameter server and AS is a diameter = client. > > > > Now please see my comments below, having in mind this use case. > > > > > > Best regards, > > Miguel Angel > > > > > > > > On mar, 2007-05-29 at 09:17 -0400, Victor Fajardo wrote: > > > > Hi Miguel, > > > > Comments inline: > > > > > > > > I have checked auth stateful server fsm at rfc 3588 > > and in fact it > > > does not allow to send service specific requests. > > > > > > Checking the auth stateless server fsm, it neither > > allows to send > > > service specific requests. This is a bit surprising > > because i.e. Sh > > > interface servers, that work in stateless mode, can > > send PNR requests. > > > > > > This seems to be against the spirit of diameter being > > a peer-to-peer > > > protocol from a transport point of view. Although > > peers are simetric > > > from a transport point of view, servers cannot send > > requests (except > > > ASR as per the fsm). And more, there is a > > contradiction between RFC > > > 3588 and some 3GPP specs. > > > > I guess we can also consider diameter as a two(2) part > > protocol where > > the peer fsm is the peer-to-peer part and the sessions > > fsm is the > > client/server application part. The current discussion > > is focused more > > on the session fsm part so we can separate the > > "peer-to-peer transport" > > aspect and not use its current behavior as a > > justification to change the > > session fsm side. > > > > > > > > [MIG] I agree. > > > > > > > > The current session fsm seems to function in a > > traditional client/server > > way where application specific conversations are always client > > initiated. I cannot speak for why 3GPP or other apps > > does not follow > > this and they may gave good technical reasons for doing > > so. In any case, > > we can probably sub-divide the discussion into two(2) > > issues (this > > includes discussions in other threads): > > > > 1. where the first app specific exchange is initiated > > by the server - I > > still have doubts about this since this maybe solved by > > other means such > > as having the "application server" create diameter > > client sessions to > > initiate a conversation. > > 2. where subsequent app specific exchanges are > > initiated by the server - > > this maybe acceptable in stateful sessions where > > applications may need > > similar msg exchange behavior like RAR. However, for > > stateless sessions, > > this not applicable and solutions becomes similar to (1). > > > > > > [MIG] The sh case fits well in the stateful model. All > > subscription messages are related to the same user, so it > > seems the most logic way to have all them into the same > > diameter session. > > > > If we try to create diameter client sessions, it implies to > > have the HSS acting first as diameter server and afterward as > > diameter client, creating a new session for a message > > exchange completely related to the previous one. You will > > have two sessions mixed all along the subscription duration > > (the subscription ends by sending another SNR that should be > > in the same session as the first SNR), being both sessions > > related to same subscription. Not a nice way to do things. > > > > In practice, this subscription dialogues can last for days, > > even months. From an implementation point of view, you get > > almost obliged to use a stateless mode. And taking into > > consideration the other message exchanges that can happen at > > sh interface (UDR and PUR), they are profile downloads and > > updates, so it makes sense to do both in stateless mode. As a > > result, the whole sh becomes stateless, even if subscriptions > > should be stateful from a pure conceptual point of view. > > > > I would like diameter to be flexible enough to fit for this > > kind of applications, and allow servers to send requests at > > least in stateful mode. It would be even greater to have a > > completely flexible protocol that allows transaction > > exchanges whenever applications need them. There are > > protocols that work in this way. I can see that sh is not the > > only case (checking ITU-T Liason at > > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) > > > > Someone should really explain me why it is so great to have a > > session layer with the limitations of a client-server model, > > when having available a great tranport layer without them. > > > > I would really like to see a list of advantages related to > > the client-server model. If folks provide good reasons, I > > will be more than happy to recognize that it is the model > > that better fits. In any case, I encourage folks to discuss > > models providing maximum flexibility. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 08:52:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNfX-0000AS-08; Wed, 30 May 2007 08:52:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNfV-0000AH-DY for dime@ietf.org; Wed, 30 May 2007 08:52:49 -0400 Received: from correo11.acens.net ([217.116.0.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtNfS-0008R4-L5 for dime@ietf.org; Wed, 30 May 2007 08:52:49 -0400 Received: (qmail 13295 invoked from network); 30 May 2007 12:52:45 -0000 Received: from unknown (HELO [192.168.1.21]) (miguel.nunez.mantica-solutions.com@[85.52.193.241]) (envelope-sender ) by correo11.acens.net (qmail-ldap-1.03) with SMTP for ; 30 May 2007 12:52:44 -0000 Subject: RE: [Dime] Clarification on Auth Server state machine From: "Miguel A." =?ISO-8859-1?Q?Nu=F1ez?= To: mikko.aittola@nsn.com In-Reply-To: <165947868C470B4889510CCB51416F6D023C5D4C@esebe107.NOE.Nokia.com> References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> <165947868C470B4889510CCB51416F6D023C5D4C@esebe107.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Mantica Solutions S.L. Date: Wed, 30 May 2007 14:52:47 +0200 Message-Id: <1180529567.6206.251.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mikko, See inline. best regards, Miguel Angel On mié, 2007-05-30 at 15:09 +0300, mikko.aittola@nsn.com wrote: > Hi, > > > [MIG] The sh case fits well in the stateful model. All > > subscription messages are related to the same user, so it > > seems the most logic way to have all them into the same > > diameter session. > > > In practice, this subscription dialogues can last for days, > > even months. From an implementation point of view, you get > > almost obliged to use a stateless mode. And taking into > > consideration the other message exchanges that can happen at > > sh interface (UDR and PUR), they are profile downloads and > > updates, so it makes sense to do both in stateless mode. As a > > result, the whole sh becomes stateless, even if subscriptions > > should be stateful from a pure conceptual point of view. > > FYI, Sh spec 3GPP TS 29.329 states: > "Whenever the definition and use of an AVP is not specified > in this document, what is stated in 3GPP TS 29.229 [6] shall > apply." > > 3GPP TS 29.229 in turn states: > "The client (server) shall include in its requests > (responses) the Auth-Session-State AVP set to the value > NO_STATE_MAINTAINED (1), as described in IETF RFC 3588 [6]." > > So if you feel you need to clarify the state-machines in > IETF RFC 3588 for the purposes of 3GPP Sh interface functionality, > it would seem that the relevant state-machines in 3588 for Sh are > 'CLIENT, STATELESS' and 'SERVER, STATELESS'. > [MIG] Yes, I know what the specs state. Please consider my example as one where stateful makes sense and where the stateful fsm does not fit completely (although it is not stateful, because of the reason I commented, and possibly more). > On the other hand, do we need to define a state machine at > all for supposedly stateless operation? > > > Best Regards, > Mikko Aittola > > > > -----Original Message----- > > From: ext Nuñez [mailto:miguel.nunez@mantica-solutions.com] > > Sent: 30 May, 2007 14:17 > > To: Victor Fajardo > > Cc: dime@ietf.org > > Subject: Re: [Dime] Clarification on Auth Server state machine > > > > Hi Victor, > > > > Ok. Let's try to move forward. > > > > Let me first explain the sh case. I don't want to turn this > > into a 3gpp issue, but just use this case as an example of an > > application that uses the services provided by diameter base. > > We can try to discuss about the flexibility of diameter based > > on this example. > > > > Sh interface allows an AS to subscribe to modifications of a > > user's profile at the HSS. The dialogue begins by sending > > SNR, so AS gets subscribed to any specific field > > modifications. Whenever that modification happens, HSS sends > > PNR to notify about it. In all this scenario, by the moment, > > we will consider HSS is a diameter server and AS is a diameter client. > > > > Now please see my comments below, having in mind this use case. > > > > > > Best regards, > > Miguel Angel > > > > > > > > On mar, 2007-05-29 at 09:17 -0400, Victor Fajardo wrote: > > > > Hi Miguel, > > > > Comments inline: > > > > > > > > I have checked auth stateful server fsm at rfc 3588 > > and in fact it > > > does not allow to send service specific requests. > > > > > > Checking the auth stateless server fsm, it neither > > allows to send > > > service specific requests. This is a bit surprising > > because i.e. Sh > > > interface servers, that work in stateless mode, can > > send PNR requests. > > > > > > This seems to be against the spirit of diameter being > > a peer-to-peer > > > protocol from a transport point of view. Although > > peers are simetric > > > from a transport point of view, servers cannot send > > requests (except > > > ASR as per the fsm). And more, there is a > > contradiction between RFC > > > 3588 and some 3GPP specs. > > > > I guess we can also consider diameter as a two(2) part > > protocol where > > the peer fsm is the peer-to-peer part and the sessions > > fsm is the > > client/server application part. The current discussion > > is focused more > > on the session fsm part so we can separate the > > "peer-to-peer transport" > > aspect and not use its current behavior as a > > justification to change the > > session fsm side. > > > > > > > > [MIG] I agree. > > > > > > > > The current session fsm seems to function in a > > traditional client/server > > way where application specific conversations are always client > > initiated. I cannot speak for why 3GPP or other apps > > does not follow > > this and they may gave good technical reasons for doing > > so. In any case, > > we can probably sub-divide the discussion into two(2) > > issues (this > > includes discussions in other threads): > > > > 1. where the first app specific exchange is initiated > > by the server - I > > still have doubts about this since this maybe solved by > > other means such > > as having the "application server" create diameter > > client sessions to > > initiate a conversation. > > 2. where subsequent app specific exchanges are > > initiated by the server - > > this maybe acceptable in stateful sessions where > > applications may need > > similar msg exchange behavior like RAR. However, for > > stateless sessions, > > this not applicable and solutions becomes similar to (1). > > > > > > [MIG] The sh case fits well in the stateful model. All > > subscription messages are related to the same user, so it > > seems the most logic way to have all them into the same > > diameter session. > > > > If we try to create diameter client sessions, it implies to > > have the HSS acting first as diameter server and afterward as > > diameter client, creating a new session for a message > > exchange completely related to the previous one. You will > > have two sessions mixed all along the subscription duration > > (the subscription ends by sending another SNR that should be > > in the same session as the first SNR), being both sessions > > related to same subscription. Not a nice way to do things. > > > > In practice, this subscription dialogues can last for days, > > even months. From an implementation point of view, you get > > almost obliged to use a stateless mode. And taking into > > consideration the other message exchanges that can happen at > > sh interface (UDR and PUR), they are profile downloads and > > updates, so it makes sense to do both in stateless mode. As a > > result, the whole sh becomes stateless, even if subscriptions > > should be stateful from a pure conceptual point of view. > > > > I would like diameter to be flexible enough to fit for this > > kind of applications, and allow servers to send requests at > > least in stateful mode. It would be even greater to have a > > completely flexible protocol that allows transaction > > exchanges whenever applications need them. There are > > protocols that work in this way. I can see that sh is not the > > only case (checking ITU-T Liason at > > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) > > > > Someone should really explain me why it is so great to have a > > session layer with the limitations of a client-server model, > > when having available a great tranport layer without them. > > > > I would really like to see a list of advantages related to > > the client-server model. If folks provide good reasons, I > > will be more than happy to recognize that it is the model > > that better fits. In any case, I encourage folks to discuss > > models providing maximum flexibility. > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 09:00:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNnK-0003fM-RC; Wed, 30 May 2007 09:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNnI-0003fH-Uk for dime@ietf.org; Wed, 30 May 2007 09:00:52 -0400 Received: from smtp101.rog.mail.re2.yahoo.com ([206.190.36.79]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtNnH-00022Q-Nr for dime@ietf.org; Wed, 30 May 2007 09:00:52 -0400 Received: (qmail 46332 invoked from network); 30 May 2007 13:00:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vczR3I8o925a/xu++xvSsk1NauoYa4A6voyqdRhBr8jRBghAfAGeN3DZYNN7OI7phRavRL3CtxsKCV6RlIdxMiipElkSvSrMh7QgOVGI2yB1Z4o1mIhM8375IVMQUkQ/cUR9dOV8u4vq1o3lI123V+o7C5Ye1785DNf3MxvRktU= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 30 May 2007 13:00:51 -0000 X-YMail-OSG: oaidhoEVM1n8mdJ4Y3xaAKJmqVEmnys4D0cn9osQaj1g6CvkFZYZVnUGKmH1RginzA-- Message-ID: <465D7583.7090401@rogers.com> Date: Wed, 30 May 2007 09:00:51 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN><46546853.7000702@tari.toshiba.com><1180441076.6206.112.camel@localhost.localdomain><465C2801.5050201@tari.toshiba.com><1180523836.6206.227.camel@localhost.localdomain> <165947868C470B4889510CCB51416F6D023C5D4C@esebe107.NOE.Nokia.com> <033458F56EC2A64E8D2D7B759FA3E7E702E0FC@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E702E0FC@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Having gone through the experience at the ITU-T, I would say that people did not understand the rules for creating an application and followed the base spec because they thought they had to do so. If there is a clear statement in the "How to create a Diameter application" document to the effect of what you just said, things will be clearer. Asveren, Tolga wrote: > First of all, why does Sh use authorization state machine as defined in RFC3588? There should have been a state machine defined specifically for Sh. They probably thought that the existing authentication state machine is similar to what they need. > > I think, people should understand that if they define a new Diameter application, and if that Diameter application is not an extension/similar to an existing application (whose state machine they can borrow), they need to define a state machine/semantics for it. If there is a need for change, it is the corresponding 3GPP document IMHO. > > Thanks, > Tolga ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 09:03:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNpm-0005Nn-MK; Wed, 30 May 2007 09:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNpm-0005Ni-C2 for dime@ietf.org; Wed, 30 May 2007 09:03:26 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtNpk-0002eJ-Aq for dime@ietf.org; Wed, 30 May 2007 09:03:26 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l4UD3MVQ007892; Wed, 30 May 2007 15:03:22 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l4UD3Mp0005380; Wed, 30 May 2007 15:03:22 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:03:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] Clarification on Auth Server state machine Date: Wed, 30 May 2007 15:03:20 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701BB3C34@MCHP7R6A.ww002.siemens.net> In-Reply-To: <465D7583.7090401@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: AceiupjGK2MxwKgkTVOX4NV16arl2QAACqYg From: "Tschofenig, Hannes" To: "ext Tom Taylor" , "Asveren, Tolga" X-OriginalArrivalTime: 30 May 2007 13:03:21.0952 (UTC) FILETIME=[E6957600:01C7A2BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tom,=20 Do you think that http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00. txt Is going into the right direction?=20 What needs to be improved?=20 Ciao Hannes > Having gone through the experience at the ITU-T, I would say=20 > that people=20 > did not understand the rules for creating an application and followed=20 > the base spec because they thought they had to do so. If there is a=20 > clear statement in the "How to create a Diameter application"=20 > document=20 > to the effect of what you just said, things will be clearer. >=20 > Asveren, Tolga wrote: > > First of all, why does Sh use authorization state machine=20 > as defined in RFC3588? There should have been a state machine=20 > defined specifically for Sh. They probably thought that the=20 > existing authentication state machine is similar to what they need.=20 > >=20 > > I think, people should understand that if they define a new=20 > Diameter application, and if that Diameter application is not=20 > an extension/similar to an existing application (whose state=20 > machine they can borrow), they need to define a state=20 > machine/semantics for it. If there is a need for change, it=20 > is the corresponding 3GPP document IMHO. > >=20 > > Thanks, > > Tolga=20 > ... >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 09:06:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNsd-0007D6-7o; Wed, 30 May 2007 09:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtNsc-0007D1-PD for dime@ietf.org; Wed, 30 May 2007 09:06:22 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtNsb-0003UQ-6j for dime@ietf.org; Wed, 30 May 2007 09:06:22 -0400 Received: from omini96.omnitel.it (omini96.omnitel.it [10.21.18.148]) by fmis837.omnitel.it (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UD6KYY002957 for ; Wed, 30 May 2007 15:06:20 +0200 (MEST) Received: from OIVMEXO02.omnitel.it ([10.32.40.39]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 May 2007 15:06:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Clarification on Auth Server state machine Date: Wed, 30 May 2007 15:05:52 +0200 Message-ID: <1B49CAB6E1212B40BDB75660BDF2B4A590E20D@OIVMEXO02.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: Aceiupj3MEk2/MAMSV+3MOJnDfJapwAABgrQ From: "STURA, Marco, VF-IT" To: "Tom Taylor" , "Asveren, Tolga" X-OriginalArrivalTime: 30 May 2007 13:06:18.0510 (UTC) FILETIME=[4FD212E0:01C7A2BB] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Just to add on top of Tolga statements there is an example of this kind = even in the IETF. RFC 4006 defines its own FSM, so it appeared to be = reasonably clear already at the time when this RFC was developed. Br, Marco =20 -----Original Message----- From: Tom Taylor [mailto:tom.taylor@rogers.com]=20 Sent: mercoled=EC 30 maggio 2007 15.01 To: Asveren, Tolga Cc: dime@ietf.org Subject: Re: [Dime] Clarification on Auth Server state machine Having gone through the experience at the ITU-T, I would say that people = did not understand the rules for creating an application and followed = the base spec because they thought they had to do so. If there is a = clear statement in the "How to create a Diameter application" document = to the effect of what you just said, things will be clearer. Asveren, Tolga wrote: > First of all, why does Sh use authorization state machine as defined = in RFC3588? There should have been a state machine defined specifically = for Sh. They probably thought that the existing authentication state = machine is similar to what they need.=20 >=20 > I think, people should understand that if they define a new Diameter = application, and if that Diameter application is not an = extension/similar to an existing application (whose state machine they = can borrow), they need to define a state machine/semantics for it. If = there is a need for change, it is the corresponding 3GPP document IMHO. >=20 > Thanks, > Tolga ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 09:28:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtOEM-0000u8-Tn; Wed, 30 May 2007 09:28:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtOEM-0000u2-Aq for dime@ietf.org; Wed, 30 May 2007 09:28:50 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HtOEK-0005Iz-RX for dime@ietf.org; Wed, 30 May 2007 09:28:50 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l4UDJX1n095896; Wed, 30 May 2007 09:19:33 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <465D79E5.3020100@tari.toshiba.com> Date: Wed, 30 May 2007 09:19:33 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: =?UTF-8?B?IlwiTWlndWVsIEEuXCIgTnXDsWV6Ig==?= Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> In-Reply-To: <1180523836.6206.227.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Miguel, Comments inline: >> 1. where the first app specific exchange is initiated by the server - I >> still have doubts about this since this maybe solved by other means such >> as having the "application server" create diameter client sessions to >> initiate a conversation. >> 2. where subsequent app specific exchanges are initiated by the server - >> this maybe acceptable in stateful sessions where applications may need >> similar msg exchange behavior like RAR. However, for stateless sessions, >> this not applicable and solutions becomes similar to (1). >> > [MIG] The sh case fits well in the stateful model. All subscription > messages are related to the same user, so it seems the most logic way > to have all them into the same diameter session. > > If we try to create diameter client sessions, it implies to have the > HSS acting first as diameter server and afterward as diameter client, > creating a new session for a message exchange completely related to > the previous one. You will have two sessions mixed all along the > subscription duration (the subscription ends by sending another SNR > that should be in the same session as the first SNR), being both > sessions related to same subscription. Not a nice way to do things. > > In practice, this subscription dialogues can last for days, even > months. From an implementation point of view, you get almost obliged > to use a stateless mode. And taking into consideration the other > message exchanges that can happen at sh interface (UDR and PUR), they > are profile downloads and updates, so it makes sense to do both in > stateless mode. As a result, the whole sh becomes stateless, even if > subscriptions should be stateful from a pure conceptual point of view. > > I would like diameter to be flexible enough to fit for this kind of > applications, and allow servers to send requests at least in stateful > mode. It would be even greater to have a completely flexible protocol > that allows transaction exchanges whenever applications need them. > There are protocols that work in this way. I can see that sh is not > the only case (checking ITU-T Liason at > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) For me, server sent request make sense only in item (2) of what I have described above. This in the case where you already have an established stateful sessions and the server sent request are for subsequent message exchanges only. This is probably the only change I'm comfortable with. For item(1), it would seem un-natural in a client/server session model for the server to send the initial request. In this behavior, the client session is expected to be created on receipt of this initial request from the server - which for the most part the client is now behaving like a server so why not just use it correctly :). > > Someone should really explain me why it is so great to have a session > layer with the limitations of a client-server model, when having > available a great tranport layer without them. > > I would really like to see a list of advantages related to the > client-server model. If folks provide good reasons, I will be more > than happy to recognize that it is the model that better fits. In any > case, I encourage folks to discuss models providing maximum flexibility. Basic engineering principles teaches us the obvious merits of client-server model so it maybe futile to re-iterate that here :). Though those principles just may not apply to what 3GPP is doing for certain apps. For this discussion, there's two things that I'm not comfortable (and maybe my assumptions are wrong): 1. Folks wants to try to change the diameter base protocol to compensate for design behaviors that should be fixed/done in the applications themselves 2. Folks wants to using the existing authz fsm for purposes it was probably not intended to and hence all this issue. I'm not familiar enough with Sh to authoritatively say otherwise but it may have been better that these 3gpp apps (ITU-T as well) define their own application fsm instead as Tolga suggested. These SDOs are already defining new diameter application so there's nothing hindering this approach. If folks are concerned about re-usablility, most of the messages and AVPs defined in the base for session maintenance can be reused in any new application that is defined provided they follow the diameter extension rules. best regards, victor > > >> I hope more folks can add their input to this so we can move forward >> more quickly on this issue. >> >> best regards, >> victor >> >> >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 10:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPMu-0006m0-5I; Wed, 30 May 2007 10:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPMs-0006lp-7u for dime@ietf.org; Wed, 30 May 2007 10:41:42 -0400 Received: from correo12.acens.net ([217.116.0.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtPMq-000393-1g for dime@ietf.org; Wed, 30 May 2007 10:41:42 -0400 Received: (qmail 14912 invoked from network); 30 May 2007 14:41:38 -0000 Received: from unknown (HELO [192.168.1.21]) (miguel.nunez.mantica-solutions.com@[85.52.193.241]) (envelope-sender ) by correo12.acens.net (qmail-ldap-1.03) with SMTP for ; 30 May 2007 14:41:38 -0000 Subject: Re: [Dime] Clarification on Auth Server state machine From: "Miguel A." =?ISO-8859-1?Q?Nu=F1ez?= To: Victor Fajardo In-Reply-To: <465D79E5.3020100@tari.toshiba.com> References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> <465D79E5.3020100@tari.toshiba.com> Organization: Mantica Solutions S.L. Date: Wed, 30 May 2007 16:41:40 +0200 Message-Id: <1180536101.6206.281.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0493396298==" Errors-To: dime-bounces@ietf.org --===============0493396298== Content-Type: multipart/alternative; boundary="=-tBStOcDSlhCtJYecu/Fu" --=-tBStOcDSlhCtJYecu/Fu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi Victor, I try to summarize all we have learnt from this interesting discussion: 1. DIME is not willing to modify their authorization state machines. They are intended for applications that work using the client-server model. 2. 3GPP, or others, should define their own session state machines, following a symmetrical model instead of the client-server one, that would fit better to the kind of applications they are designing, or have designed. 3. 3GPP has not done this redesing of the session fsms. Although there is a draft that recommends how to create applications (http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.txt), 3gpp specs were done before it existed, so they did not understand how to create them. Meanwhile, looking from the point of view of someone who wants to implement 3gpp applications, we keep 'suffering' some contradictions between the 3gpp specs and rfc 3588. Maybe we could find an intermediate approach. DIME could design new state machines, that fit the 3gpp and itu neeeds, instead of modifying the authz ones. A great number of applications would make use of this ones, we can consider them of general interest. So, the base protocol would include authz fsms, accounting fsms and 'symmetrical' fsms. The session layer is something very related to the base protocol, so related to DIME group. Does it look reasonable? Best regards, Miguel Angel On mié, 2007-05-30 at 09:19 -0400, Victor Fajardo wrote: > Hi Miguel, > > Comments inline: > > >> 1. where the first app specific exchange is initiated by the server - I > >> still have doubts about this since this maybe solved by other means such > >> as having the "application server" create diameter client sessions to > >> initiate a conversation. > >> 2. where subsequent app specific exchanges are initiated by the server - > >> this maybe acceptable in stateful sessions where applications may need > >> similar msg exchange behavior like RAR. However, for stateless sessions, > >> this not applicable and solutions becomes similar to (1). > >> > > [MIG] The sh case fits well in the stateful model. All subscription > > messages are related to the same user, so it seems the most logic way > > to have all them into the same diameter session. > > > > If we try to create diameter client sessions, it implies to have the > > HSS acting first as diameter server and afterward as diameter client, > > creating a new session for a message exchange completely related to > > the previous one. You will have two sessions mixed all along the > > subscription duration (the subscription ends by sending another SNR > > that should be in the same session as the first SNR), being both > > sessions related to same subscription. Not a nice way to do things. > > > > In practice, this subscription dialogues can last for days, even > > months. From an implementation point of view, you get almost obliged > > to use a stateless mode. And taking into consideration the other > > message exchanges that can happen at sh interface (UDR and PUR), they > > are profile downloads and updates, so it makes sense to do both in > > stateless mode. As a result, the whole sh becomes stateless, even if > > subscriptions should be stateful from a pure conceptual point of view. > > > > I would like diameter to be flexible enough to fit for this kind of > > applications, and allow servers to send requests at least in stateful > > mode. It would be even greater to have a completely flexible protocol > > that allows transaction exchanges whenever applications need them. > > There are protocols that work in this way. I can see that sh is not > > the only case (checking ITU-T Liason at > > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) > > > For me, server sent request make sense only in item (2) of what I have > described above. This in the case where you already have an established > stateful sessions and the server sent request are for subsequent > message exchanges only. This is probably the only change I'm comfortable > with. For item(1), it would seem un-natural in a client/server session > model for the server to send the initial request. In this behavior, the > client session is expected to be created on receipt of this initial > request from the server - which for the most part the client is now > behaving like a server so why not just use it correctly :). > > > > > > Someone should really explain me why it is so great to have a session > > layer with the limitations of a client-server model, when having > > available a great tranport layer without them. > > > > I would really like to see a list of advantages related to the > > client-server model. If folks provide good reasons, I will be more > > than happy to recognize that it is the model that better fits. In any > > case, I encourage folks to discuss models providing maximum flexibility. > > Basic engineering principles teaches us the obvious merits of > client-server model so it maybe futile to re-iterate that here :). > Though those principles just may not apply to what 3GPP is doing for > certain apps. For this discussion, there's two things that I'm not > comfortable (and maybe my assumptions are wrong): > > 1. Folks wants to try to change the diameter base protocol to compensate > for design behaviors that should be fixed/done in the applications > themselves > 2. Folks wants to using the existing authz fsm for purposes it was > probably not intended to and hence all this issue. > > I'm not familiar enough with Sh to authoritatively say otherwise but it > may have been better that these 3gpp apps (ITU-T as well) define their > own application fsm instead as Tolga suggested. These SDOs are already > defining new diameter application so there's nothing hindering this > approach. If folks are concerned about re-usablility, most of the > messages and AVPs defined in the base for session maintenance can be > reused in any new application that is defined provided they follow the > diameter extension rules. > > > best regards, > victor > > > > > > >> I hope more folks can add their input to this so we can move forward > >> more quickly on this issue. > >> > >> best regards, > >> victor > >> > >> > >> > > --=-tBStOcDSlhCtJYecu/Fu Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Victor,

I try to summarize all we have learnt from this interesting discussion:

1. DIME is not willing to modify their authorization state machines. They are intended for applications that work using the client-server model.

2. 3GPP, or others, should define their own session state machines, following a symmetrical model instead of the client-server one, that would fit better to the kind of applications they are designing, or have designed.

3. 3GPP has not done this redesing of the session fsms. Although there is a draft that recommends how to create applications (http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.txt), 3gpp specs were done before it existed, so they did not understand how to create them.


Meanwhile, looking from the point of view of someone who wants to implement 3gpp applications, we keep 'suffering' some contradictions between the 3gpp specs and rfc 3588.

Maybe we could find an intermediate approach. DIME could design new state machines, that fit the 3gpp and itu neeeds, instead of modifying the authz ones. A great number of applications would make use of this ones, we can consider them of general interest. So, the base protocol would include authz fsms, accounting fsms and 'symmetrical' fsms. The session layer is something very related to the base protocol, so related to DIME group. Does it look reasonable?


Best regards,
Miguel Angel




On mié, 2007-05-30 at 09:19 -0400, Victor Fajardo wrote: 
Hi Miguel,

Comments inline:

>> 1. where the first app specific exchange is initiated by the server - I 
>> still have doubts about this since this maybe solved by other means such 
>> as having the "application server" create diameter client sessions to 
>> initiate a conversation.
>> 2. where subsequent app specific exchanges are initiated by the server - 
>> this maybe acceptable in stateful sessions where applications may need 
>> similar msg exchange behavior like RAR. However, for stateless sessions, 
>> this not applicable and solutions becomes similar to (1).
>>     
> [MIG] The sh case fits well in the stateful model. All subscription 
> messages are related to the same user, so it seems the most logic way 
> to have all them into the same diameter session.
>
> If we try to create diameter client sessions, it implies to have the 
> HSS acting first as diameter server and afterward as diameter client, 
> creating a new session for a message exchange completely related to 
> the previous one. You will have two sessions mixed all along the 
> subscription duration (the subscription ends by sending another SNR 
> that should be in the same session as the first SNR), being both 
> sessions related to same subscription. Not a nice way to do things.
>
> In practice, this subscription dialogues can last for days, even 
> months. From an implementation point of view, you get almost obliged 
> to use a stateless mode. And taking into consideration the other 
> message exchanges that can happen at sh interface (UDR and PUR), they 
> are profile downloads and updates, so it makes sense to do both in 
> stateless mode. As a result, the whole sh becomes stateless, even if 
> subscriptions should be stateful from a pure conceptual point of view.
>
> I would like diameter to be flexible enough to fit for this kind of 
> applications, and allow servers to send requests at least in stateful 
> mode. It would be even greater to have a completely flexible protocol 
> that allows transaction exchanges whenever applications need them. 
> There are protocols that work in this way. I can see that sh is not 
> the only case (checking ITU-T Liason at 
> http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap)


For me, server sent request make sense only in item (2) of what I have 
described above. This in the case where you already have an established 
stateful sessions and the server sent request are  for subsequent 
message exchanges only. This is probably the only change I'm comfortable 
with. For item(1), it would seem un-natural in a client/server session 
model for the server to send the initial request. In this behavior, the 
client session is expected to be created on receipt of this initial 
request from the server - which for the most part the client is now 
behaving like a server so why not just use it correctly :).


>
> Someone should really explain me why it is so great to have a session 
> layer with the limitations of a client-server model, when having 
> available a great tranport layer without them.
>
> I would really like to see a list of advantages related to the 
> client-server model. If folks provide good reasons, I will be more 
> than happy to recognize that it is the model that better fits. In any 
> case, I encourage folks to discuss models providing maximum flexibility.

Basic engineering principles teaches us the obvious merits of 
client-server model so it maybe futile to re-iterate that here :). 
Though those principles just may not apply to what 3GPP is doing for 
certain apps. For this discussion, there's two things that I'm not 
comfortable (and maybe my assumptions are wrong):

1. Folks wants to try to change the diameter base protocol to compensate 
for design behaviors that should be fixed/done in the applications 
themselves
2. Folks wants to using the existing authz fsm for purposes it was 
probably not intended to and hence all this issue.

I'm not familiar enough with Sh to authoritatively say otherwise but it 
may have been better that these 3gpp apps (ITU-T as well) define their 
own application fsm instead as Tolga suggested. These SDOs are already 
defining new diameter application so there's nothing hindering this 
approach. If folks are concerned about re-usablility, most of the 
messages and AVPs defined in the base for session maintenance can be 
reused in any new application that is defined provided they follow the 
diameter extension rules.


best regards,
victor

>
>
>> I hope more folks can add their input to this so we can move forward 
>> more quickly on this issue.
>>
>> best regards,
>> victor
>>
>>
>>
--=-tBStOcDSlhCtJYecu/Fu-- --===============0493396298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0493396298==-- From dime-bounces@ietf.org Wed May 30 11:07:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPlc-0003TY-Kd; Wed, 30 May 2007 11:07:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPlb-0003Q0-KL for dime@ietf.org; Wed, 30 May 2007 11:07:15 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HtPla-0004im-4R for dime@ietf.org; Wed, 30 May 2007 11:07:15 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l4UF6wnR096235; Wed, 30 May 2007 11:06:58 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <465D9312.8030407@tari.toshiba.com> Date: Wed, 30 May 2007 11:06:58 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: =?UTF-8?B?IlwiTWlndWVsIEEuXCIgTnXDsWV6Ig==?= Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> <465D79E5.3020100@tari.toshiba.com> <1180536101.6206.281.camel@localhost.localdomain> In-Reply-To: <1180536101.6206.281.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l4UF6wnR096235 X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Miguel, > > Maybe we could find an intermediate approach. DIME could design new=20 > state machines, that fit the 3gpp and itu neeeds, instead of modifying=20 > the authz ones. A great number of applications would make use of this=20 > ones, we can consider them of general interest. So, the base protocol=20 > would include authz fsms, accounting fsms and 'symmetrical' fsms. The=20 > session layer is something very related to the base protocol, so=20 > related to DIME group. Does it look reasonable? We can get more opinion on what others think about this proposal. My=20 fear is that others who may want some other type of fsm would want to=20 follow the same route; i.e., force 3588bis to fill their needs. In that=20 scenario, bis would be bloated and the process may never end. My=20 personal preference is that authz and accounting fsms should have been=20 in a separate document to begin with but going that direction now for=20 these existing fsm's maybe too drastic for other folks and documents who=20 got use to having it in 3588. So, at least for me, any new symmetrical=20 fsm maybe better defined either in the application specific document or=20 other related document if the content is generic enough to be reusable;=20 which SDO will write such document may depend on whose going to use the=20 fsm more and how generic its going to be. best regards, victor > > > Best regards, > Miguel Angel > > > > > On mi=C3=A9, 2007-05-30 at 09:19 -0400, Victor Fajardo wrote: >> Hi Miguel, >> >> Comments inline: >> >> >> 1. where the first app specific exchange is initiated by the server= - I=20 >> >> still have doubts about this since this maybe solved by other means= such=20 >> >> as having the "application server" create diameter client sessions = to=20 >> >> initiate a conversation. >> >> 2. where subsequent app specific exchanges are initiated by the ser= ver -=20 >> >> this maybe acceptable in stateful sessions where applications may n= eed=20 >> >> similar msg exchange behavior like RAR. However, for stateless sess= ions,=20 >> >> this not applicable and solutions becomes similar to (1). >> >> =20 >> > [MIG] The sh case fits well in the stateful model. All subscription=20 >> > messages are related to the same user, so it seems the most logic wa= y=20 >> > to have all them into the same diameter session. >> > >> > If we try to create diameter client sessions, it implies to have the= =20 >> > HSS acting first as diameter server and afterward as diameter client= ,=20 >> > creating a new session for a message exchange completely related to=20 >> > the previous one. You will have two sessions mixed all along the=20 >> > subscription duration (the subscription ends by sending another SNR=20 >> > that should be in the same session as the first SNR), being both=20 >> > sessions related to same subscription. Not a nice way to do things. >> > >> > In practice, this subscription dialogues can last for days, even=20 >> > months. From an implementation point of view, you get almost obliged= =20 >> > to use a stateless mode. And taking into consideration the other=20 >> > message exchanges that can happen at sh interface (UDR and PUR), the= y=20 >> > are profile downloads and updates, so it makes sense to do both in=20 >> > stateless mode. As a result, the whole sh becomes stateless, even if= =20 >> > subscriptions should be stateful from a pure conceptual point of vie= w. >> > >> > I would like diameter to be flexible enough to fit for this kind of=20 >> > applications, and allow servers to send requests at least in statefu= l=20 >> > mode. It would be even greater to have a completely flexible protoco= l=20 >> > that allows transaction exchanges whenever applications need them.=20 >> > There are protocols that work in this way. I can see that sh is not=20 >> > the only case (checking ITU-T Liason at=20 >> > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) >> >> >> For me, server sent request make sense only in item (2) of what I have= =20 >> described above. This in the case where you already have an establishe= d=20 >> stateful sessions and the server sent request are for subsequent=20 >> message exchanges only. This is probably the only change I'm comfortab= le=20 >> with. For item(1), it would seem un-natural in a client/server session= =20 >> model for the server to send the initial request. In this behavior, th= e=20 >> client session is expected to be created on receipt of this initial=20 >> request from the server - which for the most part the client is now=20 >> behaving like a server so why not just use it correctly :). >> >> >> > >> > Someone should really explain me why it is so great to have a sessio= n=20 >> > layer with the limitations of a client-server model, when having=20 >> > available a great tranport layer without them. >> > >> > I would really like to see a list of advantages related to the=20 >> > client-server model. If folks provide good reasons, I will be more=20 >> > than happy to recognize that it is the model that better fits. In an= y=20 >> > case, I encourage folks to discuss models providing maximum flexibil= ity. >> >> Basic engineering principles teaches us the obvious merits of=20 >> client-server model so it maybe futile to re-iterate that here :).=20 >> Though those principles just may not apply to what 3GPP is doing for=20 >> certain apps. For this discussion, there's two things that I'm not=20 >> comfortable (and maybe my assumptions are wrong): >> >> 1. Folks wants to try to change the diameter base protocol to compensa= te=20 >> for design behaviors that should be fixed/done in the applications=20 >> themselves >> 2. Folks wants to using the existing authz fsm for purposes it was=20 >> probably not intended to and hence all this issue. >> >> I'm not familiar enough with Sh to authoritatively say otherwise but i= t=20 >> may have been better that these 3gpp apps (ITU-T as well) define their= =20 >> own application fsm instead as Tolga suggested. These SDOs are already= =20 >> defining new diameter application so there's nothing hindering this=20 >> approach. If folks are concerned about re-usablility, most of the=20 >> messages and AVPs defined in the base for session maintenance can be=20 >> reused in any new application that is defined provided they follow the= =20 >> diameter extension rules. >> >> >> best regards, >> victor >> >> > >> > >> >> I hope more folks can add their input to this so we can move forwar= d=20 >> >> more quickly on this issue. >> >> >> >> best regards, >> >> victor >> >> >> >> >> >> =20 >> >> >> =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 15:11:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTZk-0006na-Sp; Wed, 30 May 2007 15:11:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTZj-0006lw-Sa for dime@ietf.org; Wed, 30 May 2007 15:11:15 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtTZi-0004Cn-BM for dime@ietf.org; Wed, 30 May 2007 15:11:15 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4UJB8WM017347; Wed, 30 May 2007 14:11:13 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 14:11:07 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Dime] Clarification on Auth Server state machine Date: Wed, 30 May 2007 14:11:06 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D52087A@ILEXC2U01.ndc.lucent.com> In-Reply-To: <465D9312.8030407@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: AceizETBRVa1votvSg6slyvVc2CLLAAHkJoQ References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> <465D79E5.3020100@tari.toshiba.com><1180536101.6206.281.camel@localhost.localdomain> <465D9312.8030407@tari.toshiba.com> From: "Sun, Dong \(Dong\)" To: "Victor Fajardo" , =?iso-8859-1?Q?=22=5C=22Miguel_A=2E=5C=22_Nu=F1ez=22?= X-OriginalArrivalTime: 30 May 2007 19:11:07.0307 (UTC) FILETIME=[468F6FB0:01C7A2EE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Two cents: - First, I think it is sensible to make the Diameter more flexible and = allow the Diameter server to initiate a Diameter session in support of = peer-to-peer applications, as examples, besides the Sh interface, as = addressed in = http://tools.ietf.org/id/draft-sun-dime-diameter-resource-control-require= ments-01.txt, the QoS application may require the peer-to-peer fsm in = support of Push model. - I have no strong view to mandate the Diameter base protocol to define = the server initiated session fsm. However, at least, the base protocol = should not prohibit this kind of possibility. Otherwise, I don't know = how a Diameter application can define a fsm contradicted to base = protocol. - I am not sure if the current 3588 is a pure base protocol and can be = used as generic profile for all applications since it does define some = fsm for certain applications such as Auth and Acct. It is a bit confused = if both 3599 and applications define different fsms using the same = command codes. From this perspective, I do not prefer to extend RAR to = support server initiated session, the new command code is more = reasonable for this kind of FSM, such as PIR defined in aforementioned = I-D for QoS application, or PNR for Sh. Now two options: - Create new state mechanism and generic command codes in base protocol = to support server initiated session - Create new state mechanism and specific command codes in the = applications if needed. Certainly, some clarification is needed in the = base protocol to allow this kind of flexibility, which I have not yet = seen. It seems to me the second option is more realistic considering the fact = (e.g. 3GPP, ITU and TISPAN have defined (are developing) their own = applications). The first option is more elegant from the pure functional = perspective. Cheers, Dong=20 -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Wednesday, May 30, 2007 11:07 AM To: "\"Miguel A.\" Nu=F1ez" Cc: dime@ietf.org Subject: Re: [Dime] Clarification on Auth Server state machine Hi Miguel, > > Maybe we could find an intermediate approach. DIME could design new=20 > state machines, that fit the 3gpp and itu neeeds, instead of modifying = > the authz ones. A great number of applications would make use of this=20 > ones, we can consider them of general interest. So, the base protocol=20 > would include authz fsms, accounting fsms and 'symmetrical' fsms. The=20 > session layer is something very related to the base protocol, so=20 > related to DIME group. Does it look reasonable? We can get more opinion on what others think about this proposal. My = fear is that others who may want some other type of fsm would want to = follow the same route; i.e., force 3588bis to fill their needs. In that = scenario, bis would be bloated and the process may never end. My = personal preference is that authz and accounting fsms should have been = in a separate document to begin with but going that direction now for = these existing fsm's maybe too drastic for other folks and documents who = got use to having it in 3588. So, at least for me, any new symmetrical = fsm maybe better defined either in the application specific document or = other related document if the content is generic enough to be reusable; = which SDO will write such document may depend on whose going to use the = fsm more and how generic its going to be. best regards, victor > > > Best regards, > Miguel Angel > > > > > On mi=E9, 2007-05-30 at 09:19 -0400, Victor Fajardo wrote: >> Hi Miguel, >> >> Comments inline: >> >> >> 1. where the first app specific exchange is initiated by the=20 >> >> server - I still have doubts about this since this maybe solved by = >> >> other means such as having the "application server" create=20 >> >> diameter client sessions to initiate a conversation. >> >> 2. where subsequent app specific exchanges are initiated by the=20 >> >> server - this maybe acceptable in stateful sessions where=20 >> >> applications may need similar msg exchange behavior like RAR.=20 >> >> However, for stateless sessions, this not applicable and solutions = becomes similar to (1). >> >> =20 >> > [MIG] The sh case fits well in the stateful model. All subscription = >> > messages are related to the same user, so it seems the most logic=20 >> > way to have all them into the same diameter session. >> > >> > If we try to create diameter client sessions, it implies to have=20 >> > the HSS acting first as diameter server and afterward as diameter=20 >> > client, creating a new session for a message exchange completely=20 >> > related to the previous one. You will have two sessions mixed all=20 >> > along the subscription duration (the subscription ends by sending=20 >> > another SNR that should be in the same session as the first SNR),=20 >> > being both sessions related to same subscription. Not a nice way to = do things. >> > >> > In practice, this subscription dialogues can last for days, even=20 >> > months. From an implementation point of view, you get almost=20 >> > obliged to use a stateless mode. And taking into consideration the=20 >> > other message exchanges that can happen at sh interface (UDR and=20 >> > PUR), they are profile downloads and updates, so it makes sense to=20 >> > do both in stateless mode. As a result, the whole sh becomes=20 >> > stateless, even if subscriptions should be stateful from a pure = conceptual point of view. >> > >> > I would like diameter to be flexible enough to fit for this kind of = >> > applications, and allow servers to send requests at least in=20 >> > stateful mode. It would be even greater to have a completely=20 >> > flexible protocol that allows transaction exchanges whenever = applications need them. >> > There are protocols that work in this way. I can see that sh is not = >> > the only case (checking ITU-T Liason at >> > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap)=20 >> > >> >> >> For me, server sent request make sense only in item (2) of what I=20 >> have described above. This in the case where you already have an=20 >> established stateful sessions and the server sent request are for=20 >> subsequent message exchanges only. This is probably the only change=20 >> I'm comfortable with. For item(1), it would seem un-natural in a=20 >> client/server session model for the server to send the initial=20 >> request. In this behavior, the client session is expected to be=20 >> created on receipt of this initial request from the server - which=20 >> for the most part the client is now behaving like a server so why not = just use it correctly :). >> >> >> > >> > Someone should really explain me why it is so great to have a=20 >> > session layer with the limitations of a client-server model, when=20 >> > having available a great tranport layer without them. >> > >> > I would really like to see a list of advantages related to the=20 >> > client-server model. If folks provide good reasons, I will be more=20 >> > than happy to recognize that it is the model that better fits. In=20 >> > any case, I encourage folks to discuss models providing maximum = flexibility. >> >> Basic engineering principles teaches us the obvious merits of=20 >> client-server model so it maybe futile to re-iterate that here :). >> Though those principles just may not apply to what 3GPP is doing for=20 >> certain apps. For this discussion, there's two things that I'm not=20 >> comfortable (and maybe my assumptions are wrong): >> >> 1. Folks wants to try to change the diameter base protocol to=20 >> compensate for design behaviors that should be fixed/done in the=20 >> applications themselves 2. Folks wants to using the existing authz=20 >> fsm for purposes it was probably not intended to and hence all this=20 >> issue. >> >> I'm not familiar enough with Sh to authoritatively say otherwise but=20 >> it may have been better that these 3gpp apps (ITU-T as well) define=20 >> their own application fsm instead as Tolga suggested. These SDOs are=20 >> already defining new diameter application so there's nothing=20 >> hindering this approach. If folks are concerned about re-usablility,=20 >> most of the messages and AVPs defined in the base for session=20 >> maintenance can be reused in any new application that is defined=20 >> provided they follow the diameter extension rules. >> >> >> best regards, >> victor >> >> > >> > >> >> I hope more folks can add their input to this so we can move=20 >> >> forward more quickly on this issue. >> >> >> >> best regards, >> >> victor >> >> >> >> >> >> =20 >> >> >> =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 15:51:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUCC-0002fl-2K; Wed, 30 May 2007 15:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUCB-0002fU-M6 for dime@ietf.org; Wed, 30 May 2007 15:50:59 -0400 Received: from smtp107.rog.mail.re2.yahoo.com ([68.142.225.205]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtUC8-00060g-N2 for dime@ietf.org; Wed, 30 May 2007 15:50:59 -0400 Received: (qmail 88680 invoked from network); 30 May 2007 19:50:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nnIr4AmfCBl5FvZ20jaxJWJ5FqOmRSwqYaeg4KlbX3IJJy5wyQjXK0gEw1GYfzBd288apHpzy94nDDH5/h6wfD61ZA1lqxCpIbW9MA9ROvXZP2YTvcwKhA6emH7I/vLrNv0P/V4o83bCiVrS/zEwqzcU3y5AkyUC1BLu6NWBv7k= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp107.rog.mail.re2.yahoo.com with SMTP; 30 May 2007 19:50:56 -0000 X-YMail-OSG: v5MPF6QVM1nBJD3Scn9E9Ys3LkPgkC5OLtOufRGDKCmbdKJURpe_MahYlkfrgGLpnQ-- Message-ID: <465DD5A2.7000309@rogers.com> Date: Wed, 30 May 2007 15:50:58 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Sun, Dong \(Dong\)" Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> <465D79E5.3020100@tari.toshiba.com><1180536101.6206.281.camel@localhost.localdomain> <465D9312.8030407@tari.toshiba.com> <09C9068466B79E4C938DC7737562404D52087A@ILEXC2U01.ndc.lucent.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D52087A@ILEXC2U01.ndc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: dime@ietf.org, =?ISO-8859-1?Q?=22=5C=22M?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I would be in favour of taking the specific authz application and FSM out of Base into a separate document and making Base a more general document. If labour is needed for that, I could help. If that doesn't appeal because the IESG wants to keep control of the protocol (a historical position), then I would favour putting peer-to-peer at the application level into a separate document rather than the base draft, and modifying base to allow such operation. Sun, Dong (Dong) wrote: > Two cents: > - First, I think it is sensible to make the Diameter more flexible and allow the Diameter server to initiate a Diameter session in support of peer-to-peer applications, as examples, besides the Sh interface, as addressed in http://tools.ietf.org/id/draft-sun-dime-diameter-resource-control-requirements-01.txt, the QoS application may require the peer-to-peer fsm in support of Push model. > > - I have no strong view to mandate the Diameter base protocol to define the server initiated session fsm. However, at least, the base protocol should not prohibit this kind of possibility. Otherwise, I don't know how a Diameter application can define a fsm contradicted to base protocol. > > - I am not sure if the current 3588 is a pure base protocol and can be used as generic profile for all applications since it does define some fsm for certain applications such as Auth and Acct. It is a bit confused if both 3599 and applications define different fsms using the same command codes. From this perspective, I do not prefer to extend RAR to support server initiated session, the new command code is more reasonable for this kind of FSM, such as PIR defined in aforementioned I-D for QoS application, or PNR for Sh. > > Now two options: > - Create new state mechanism and generic command codes in base protocol to support server initiated session > - Create new state mechanism and specific command codes in the applications if needed. Certainly, some clarification is needed in the base protocol to allow this kind of flexibility, which I have not yet seen. > > It seems to me the second option is more realistic considering the fact (e.g. 3GPP, ITU and TISPAN have defined (are developing) their own applications). The first option is more elegant from the pure functional perspective. > > Cheers, > Dong > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, May 30, 2007 11:07 AM > To: "\"Miguel A.\" Nuñez" > Cc: dime@ietf.org > Subject: Re: [Dime] Clarification on Auth Server state machine > > Hi Miguel, > >> Maybe we could find an intermediate approach. DIME could design new >> state machines, that fit the 3gpp and itu neeeds, instead of modifying >> the authz ones. A great number of applications would make use of this >> ones, we can consider them of general interest. So, the base protocol >> would include authz fsms, accounting fsms and 'symmetrical' fsms. The >> session layer is something very related to the base protocol, so >> related to DIME group. Does it look reasonable? > > We can get more opinion on what others think about this proposal. My fear is that others who may want some other type of fsm would want to follow the same route; i.e., force 3588bis to fill their needs. In that scenario, bis would be bloated and the process may never end. My personal preference is that authz and accounting fsms should have been in a separate document to begin with but going that direction now for these existing fsm's maybe too drastic for other folks and documents who got use to having it in 3588. So, at least for me, any new symmetrical fsm maybe better defined either in the application specific document or other related document if the content is generic enough to be reusable; which SDO will write such document may depend on whose going to use the fsm more and how generic its going to be. > > best regards, > victor > >> >> Best regards, >> Miguel Angel >> >> >> >> >> On mié, 2007-05-30 at 09:19 -0400, Victor Fajardo wrote: >>> Hi Miguel, >>> >>> Comments inline: >>> >>>>> 1. where the first app specific exchange is initiated by the >>>>> server - I still have doubts about this since this maybe solved by >>>>> other means such as having the "application server" create >>>>> diameter client sessions to initiate a conversation. >>>>> 2. where subsequent app specific exchanges are initiated by the >>>>> server - this maybe acceptable in stateful sessions where >>>>> applications may need similar msg exchange behavior like RAR. >>>>> However, for stateless sessions, this not applicable and solutions becomes similar to (1). >>>>> >>>> [MIG] The sh case fits well in the stateful model. All subscription >>>> messages are related to the same user, so it seems the most logic >>>> way to have all them into the same diameter session. >>>> >>>> If we try to create diameter client sessions, it implies to have >>>> the HSS acting first as diameter server and afterward as diameter >>>> client, creating a new session for a message exchange completely >>>> related to the previous one. You will have two sessions mixed all >>>> along the subscription duration (the subscription ends by sending >>>> another SNR that should be in the same session as the first SNR), >>>> being both sessions related to same subscription. Not a nice way to do things. >>>> >>>> In practice, this subscription dialogues can last for days, even >>>> months. From an implementation point of view, you get almost >>>> obliged to use a stateless mode. And taking into consideration the >>>> other message exchanges that can happen at sh interface (UDR and >>>> PUR), they are profile downloads and updates, so it makes sense to >>>> do both in stateless mode. As a result, the whole sh becomes >>>> stateless, even if subscriptions should be stateful from a pure conceptual point of view. >>>> >>>> I would like diameter to be flexible enough to fit for this kind of >>>> applications, and allow servers to send requests at least in >>>> stateful mode. It would be even greater to have a completely >>>> flexible protocol that allows transaction exchanges whenever applications need them. >>>> There are protocols that work in this way. I can see that sh is not >>>> the only case (checking ITU-T Liason at >>>> http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) >>>> >>> >>> For me, server sent request make sense only in item (2) of what I >>> have described above. This in the case where you already have an >>> established stateful sessions and the server sent request are for >>> subsequent message exchanges only. This is probably the only change >>> I'm comfortable with. For item(1), it would seem un-natural in a >>> client/server session model for the server to send the initial >>> request. In this behavior, the client session is expected to be >>> created on receipt of this initial request from the server - which >>> for the most part the client is now behaving like a server so why not just use it correctly :). >>> >>> >>>> Someone should really explain me why it is so great to have a >>>> session layer with the limitations of a client-server model, when >>>> having available a great tranport layer without them. >>>> >>>> I would really like to see a list of advantages related to the >>>> client-server model. If folks provide good reasons, I will be more >>>> than happy to recognize that it is the model that better fits. In >>>> any case, I encourage folks to discuss models providing maximum flexibility. >>> Basic engineering principles teaches us the obvious merits of >>> client-server model so it maybe futile to re-iterate that here :). >>> Though those principles just may not apply to what 3GPP is doing for >>> certain apps. For this discussion, there's two things that I'm not >>> comfortable (and maybe my assumptions are wrong): >>> >>> 1. Folks wants to try to change the diameter base protocol to >>> compensate for design behaviors that should be fixed/done in the >>> applications themselves 2. Folks wants to using the existing authz >>> fsm for purposes it was probably not intended to and hence all this >>> issue. >>> >>> I'm not familiar enough with Sh to authoritatively say otherwise but >>> it may have been better that these 3gpp apps (ITU-T as well) define >>> their own application fsm instead as Tolga suggested. These SDOs are >>> already defining new diameter application so there's nothing >>> hindering this approach. If folks are concerned about re-usablility, >>> most of the messages and AVPs defined in the base for session >>> maintenance can be reused in any new application that is defined >>> provided they follow the diameter extension rules. >>> >>> >>> best regards, >>> victor >>> >>>> >>>>> I hope more folks can add their input to this so we can move >>>>> forward more quickly on this issue. >>>>> >>>>> best regards, >>>>> victor >>>>> >>>>> >>>>> >>> >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 16:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUey-0006og-S5; Wed, 30 May 2007 16:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUey-0006oQ-05 for dime@ietf.org; Wed, 30 May 2007 16:20:44 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtUex-00006V-Ft for dime@ietf.org; Wed, 30 May 2007 16:20:43 -0400 Received: from sonusmail01.sonusnet.com (sonusmail01.sonusnet.com [10.128.32.75]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l4UKKehe004582 for ; Wed, 30 May 2007 16:20:40 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 May 2007 16:20:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Clarification on Auth Server state machine Date: Wed, 30 May 2007 16:20:40 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702E10C@sonusmail04.sonusnet.com> In-Reply-To: <465DD5A2.7000309@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification on Auth Server state machine Thread-Index: Acei89o6FIHc7LO8T1+mnrG+Uqks0wAA6dpw References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> <465D79E5.3020100@tari.toshiba.com><1180536101.6206.281.camel@localhost.localdomain> <465D9312.8030407@tari.toshiba.com><09C9068466B79E4C938DC7737562404D52087A@ILEXC2U01.ndc.lucent.com> <465DD5A2.7000309@rogers.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 30 May 2007 20:20:40.0600 (UTC) FILETIME=[FE096980:01C7A2F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org inline... > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: Wednesday, May 30, 2007 3:51 PM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; = =3D?ISO-8859-1?Q?=3D22=3D5C=3D22M?=3D@sonussf2.sonusnet.com > Subject: Re: [Dime] Clarification on Auth Server state machine >=20 > I would be in favour of taking the specific authz application and FSM > out of Base into a separate document and making Base a more general > document. If labour is needed for that, I could help. [TOLGA]IMHO, that is technically the best option. >=20 > If that doesn't appeal because the IESG wants to keep control of the > protocol (a historical position), then I would favour putting > peer-to-peer at the application level into a separate document rather > than the base draft, and modifying base to allow such operation. [TOLGA]I agree. Let's keep the base as clean as possible. >=20 > Sun, Dong (Dong) wrote: > > Two cents: > > - First, I think it is sensible to make the Diameter more flexible = and > allow the Diameter server to initiate a Diameter session in support of > peer-to-peer applications, as examples, besides the Sh interface, as > addressed in = http://tools.ietf.org/id/draft-sun-dime-diameter-resource- > control-requirements-01.txt, the QoS application may require the = peer-to- > peer fsm in support of Push model. > > > > - I have no strong view to mandate the Diameter base protocol to = define > the server initiated session fsm. However, at least, the base protocol > should not prohibit this kind of possibility. Otherwise, I don't know = how > a Diameter application can define a fsm contradicted to base protocol. > > > > - I am not sure if the current 3588 is a pure base protocol and can = be > used as generic profile for all applications since it does define some = fsm > for certain applications such as Auth and Acct. It is a bit confused = if > both 3599 and applications define different fsms using the same = command > codes. From this perspective, I do not prefer to extend RAR to support > server initiated session, the new command code is more reasonable for = this > kind of FSM, such as PIR defined in aforementioned I-D for QoS > application, or PNR for Sh. > > > > Now two options: > > - Create new state mechanism and generic command codes in base = protocol > to support server initiated session > > - Create new state mechanism and specific command codes in the > applications if needed. Certainly, some clarification is needed in the > base protocol to allow this kind of flexibility, which I have not yet > seen. > > > > It seems to me the second option is more realistic considering the = fact > (e.g. 3GPP, ITU and TISPAN have defined (are developing) their own > applications). The first option is more elegant from the pure = functional > perspective. > > > > Cheers, > > Dong > > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Wednesday, May 30, 2007 11:07 AM > > To: "\"Miguel A.\" Nu=F1ez" > > Cc: dime@ietf.org > > Subject: Re: [Dime] Clarification on Auth Server state machine > > > > Hi Miguel, > > > >> Maybe we could find an intermediate approach. DIME could design new > >> state machines, that fit the 3gpp and itu neeeds, instead of = modifying > >> the authz ones. A great number of applications would make use of = this > >> ones, we can consider them of general interest. So, the base = protocol > >> would include authz fsms, accounting fsms and 'symmetrical' fsms. = The > >> session layer is something very related to the base protocol, so > >> related to DIME group. Does it look reasonable? > > > > We can get more opinion on what others think about this proposal. My > fear is that others who may want some other type of fsm would want to > follow the same route; i.e., force 3588bis to fill their needs. In = that > scenario, bis would be bloated and the process may never end. My = personal > preference is that authz and accounting fsms should have been in a > separate document to begin with but going that direction now for these > existing fsm's maybe too drastic for other folks and documents who got = use > to having it in 3588. So, at least for me, any new symmetrical fsm = maybe > better defined either in the application specific document or other > related document if the content is generic enough to be reusable; = which > SDO will write such document may depend on whose going to use the fsm = more > and how generic its going to be. > > > > best regards, > > victor > > > >> > >> Best regards, > >> Miguel Angel > >> > >> > >> > >> > >> On mi=E9, 2007-05-30 at 09:19 -0400, Victor Fajardo wrote: > >>> Hi Miguel, > >>> > >>> Comments inline: > >>> > >>>>> 1. where the first app specific exchange is initiated by the > >>>>> server - I still have doubts about this since this maybe solved = by > >>>>> other means such as having the "application server" create > >>>>> diameter client sessions to initiate a conversation. > >>>>> 2. where subsequent app specific exchanges are initiated by the > >>>>> server - this maybe acceptable in stateful sessions where > >>>>> applications may need similar msg exchange behavior like RAR. > >>>>> However, for stateless sessions, this not applicable and = solutions > becomes similar to (1). > >>>>> > >>>> [MIG] The sh case fits well in the stateful model. All = subscription > >>>> messages are related to the same user, so it seems the most logic > >>>> way to have all them into the same diameter session. > >>>> > >>>> If we try to create diameter client sessions, it implies to have > >>>> the HSS acting first as diameter server and afterward as diameter > >>>> client, creating a new session for a message exchange completely > >>>> related to the previous one. You will have two sessions mixed all > >>>> along the subscription duration (the subscription ends by sending > >>>> another SNR that should be in the same session as the first SNR), > >>>> being both sessions related to same subscription. Not a nice way = to > do things. > >>>> > >>>> In practice, this subscription dialogues can last for days, even > >>>> months. From an implementation point of view, you get almost > >>>> obliged to use a stateless mode. And taking into consideration = the > >>>> other message exchanges that can happen at sh interface (UDR and > >>>> PUR), they are profile downloads and updates, so it makes sense = to > >>>> do both in stateless mode. As a result, the whole sh becomes > >>>> stateless, even if subscriptions should be stateful from a pure > conceptual point of view. > >>>> > >>>> I would like diameter to be flexible enough to fit for this kind = of > >>>> applications, and allow servers to send requests at least in > >>>> stateful mode. It would be even greater to have a completely > >>>> flexible protocol that allows transaction exchanges whenever > applications need them. > >>>> There are protocols that work in this way. I can see that sh is = not > >>>> the only case (checking ITU-T Liason at > >>>> http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap) > >>>> = > >>> > >>> For me, server sent request make sense only in item (2) of what I > >>> have described above. This in the case where you already have an > >>> established stateful sessions and the server sent request are for > >>> subsequent message exchanges only. This is probably the only = change > >>> I'm comfortable with. For item(1), it would seem un-natural in a > >>> client/server session model for the server to send the initial > >>> request. In this behavior, the client session is expected to be > >>> created on receipt of this initial request from the server - which > >>> for the most part the client is now behaving like a server so why = not > just use it correctly :). > >>> > >>> > >>>> Someone should really explain me why it is so great to have a > >>>> session layer with the limitations of a client-server model, when > >>>> having available a great tranport layer without them. > >>>> > >>>> I would really like to see a list of advantages related to the > >>>> client-server model. If folks provide good reasons, I will be = more > >>>> than happy to recognize that it is the model that better fits. In > >>>> any case, I encourage folks to discuss models providing maximum > flexibility. > >>> Basic engineering principles teaches us the obvious merits of > >>> client-server model so it maybe futile to re-iterate that here :). > >>> Though those principles just may not apply to what 3GPP is doing = for > >>> certain apps. For this discussion, there's two things that I'm not > >>> comfortable (and maybe my assumptions are wrong): > >>> > >>> 1. Folks wants to try to change the diameter base protocol to > >>> compensate for design behaviors that should be fixed/done in the > >>> applications themselves 2. Folks wants to using the existing authz > >>> fsm for purposes it was probably not intended to and hence all = this > >>> issue. > >>> > >>> I'm not familiar enough with Sh to authoritatively say otherwise = but > >>> it may have been better that these 3gpp apps (ITU-T as well) = define > >>> their own application fsm instead as Tolga suggested. These SDOs = are > >>> already defining new diameter application so there's nothing > >>> hindering this approach. If folks are concerned about = re-usablility, > >>> most of the messages and AVPs defined in the base for session > >>> maintenance can be reused in any new application that is defined > >>> provided they follow the diameter extension rules. > >>> > >>> > >>> best regards, > >>> victor > >>> > >>>> > >>>>> I hope more folks can add their input to this so we can move > >>>>> forward more quickly on this issue. > >>>>> > >>>>> best regards, > >>>>> victor > >>>>> > >>>>> > >>>>> > >>> > >>> > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 16:38:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUvy-0000CB-3X; Wed, 30 May 2007 16:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUvx-0000C6-Ah for dime@ietf.org; Wed, 30 May 2007 16:38:17 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtUvv-0006UU-TW for dime@ietf.org; Wed, 30 May 2007 16:38:17 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l4UKbUgI097687; Wed, 30 May 2007 16:37:30 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <465DE08A.1040403@tari.toshiba.com> Date: Wed, 30 May 2007 16:37:30 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Sun, Dong \(Dong\)" Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> <465D79E5.3020100@tari.toshiba.com><1180536101.6206.281.camel@localhost.localdomain> <465D9312.8030407@tari.toshiba.com> <09C9068466B79E4C938DC7737562404D52087A@ILEXC2U01.ndc.lucent.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D52087A@ILEXC2U01.ndc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Sun, Comments inline: > Two cents: > - First, I think it is sensible to make the Diameter more flexible and allow the Diameter server to initiate a Diameter session in support of peer-to-peer applications, as examples, besides the Sh interface, as addressed in http://tools.ietf.org/id/draft-sun-dime-diameter-resource-control-requirements-01.txt, the QoS application may require the peer-to-peer fsm in support of Push model. > > - I have no strong view to mandate the Diameter base protocol to define the server initiated session fsm. However, at least, the base protocol should not prohibit this kind of possibility. Otherwise, I don't know how a Diameter application can define a fsm contradicted to base protocol. > In my understanding, and folks can correct me if this is not accurate, an application is certainly free to define its own fsm and I don't think the current base protocol spec bans such approach. Consider the example given by Marco on rfc4006. > - I am not sure if the current 3588 is a pure base protocol and can be used as generic profile for all applications since it does define some fsm for certain applications such as Auth and Acct. It is a bit confused if both 3599 and applications define different fsms using the same command codes. From this perspective, I do not prefer to extend RAR to support server initiated session, the new command code is more reasonable for this kind of FSM, such as PIR defined in aforementioned I-D for QoS application, or PNR for Sh. > This maybe the best approach for your application. For others who may wish to re-use existing commands (for their own fsm or for whatever reasons) its probably best if you check out the extensibility guidelines in http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.txt. > Now two options: > - Create new state mechanism and generic command codes in base protocol to support server initiated session > - Create new state mechanism and specific command codes in the applications if needed. Certainly, some clarification is needed in the base protocol to allow this kind of flexibility, which I have not yet seen. > I would prefer the second approach though I'm not sure what type of clarification is required since the base protocol currently does not restrict an application in defining its own fsm. If folks have a differing view on when and how to use the session fsm defined in the base then maybe that can go to the app design guide docs instead. As for the first option, it maybe is less elegant as I mentioned before since it forces the base protocol to solve a problem of the application (probably making the base protocol even more confusing). regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 16:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtV5X-0005aC-SY; Wed, 30 May 2007 16:48:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtV5W-0005Xs-Vh for dime@ietf.org; Wed, 30 May 2007 16:48:11 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HtV5V-0003XO-Lk for dime@ietf.org; Wed, 30 May 2007 16:48:10 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l4UKglFk097720; Wed, 30 May 2007 16:42:47 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <465DE1C7.7060203@tari.toshiba.com> Date: Wed, 30 May 2007 16:42:47 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Tom Taylor Subject: Re: [Dime] Clarification on Auth Server state machine References: <66E8AEE9980BB44CA5FCAD39EBA56AC601628CB3@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <46546853.7000702@tari.toshiba.com> <1180441076.6206.112.camel@localhost.localdomain> <465C2801.5050201@tari.toshiba.com> <1180523836.6206.227.camel@localhost.localdomain> <465D79E5.3020100@tari.toshiba.com><1180536101.6206.281.camel@localhost.localdomain> <465D9312.8030407@tari.toshiba.com> <09C9068466B79E4C938DC7737562404D52087A@ILEXC2U01.ndc.lucent.com> <465DD5A2.7000309@rogers.com> In-Reply-To: <465DD5A2.7000309@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tom, > I would be in favour of taking the specific authz application and FSM > out of Base into a separate document and making Base a more general > document. If labour is needed for that, I could help. > > If that doesn't appeal because the IESG wants to keep control of the > protocol (a historical position), then I would favour putting > peer-to-peer at the application level into a separate document rather > than the base draft, and modifying base to allow such operation. Agree with the latter option as well. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed May 30 18:50:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWzX-0005H9-F5; Wed, 30 May 2007 18:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWzU-0005GT-Ns; Wed, 30 May 2007 18:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtWzU-00041K-82; Wed, 30 May 2007 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 507A826ECB; Wed, 30 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HtWzS-0002T4-3f; Wed, 30 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 30 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --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 : The Diameter API Author(s) : D. Frascone, P. Calhoun Filename : draft-ietf-dime-diameter-api-02.txt Pages : 47 Date : 2007-5-30 The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-diameter-api-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-diameter-api-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-30160335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-api-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-api-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-30160335.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu May 31 04:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htg1B-0001od-U5; Thu, 31 May 2007 04:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htg1A-0001oI-OM for dime@ietf.org; Thu, 31 May 2007 04:28:24 -0400 Received: from mail-v023.telia.se ([81.236.34.23] helo=teliasonera.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htg17-0007gG-Om for dime@ietf.org; Thu, 31 May 2007 04:28:24 -0400 Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by mail2.han.telia.se (BorderWare Infinity Mail Firewall) with ESMTP id FB9D180B0C06EE17 for ; Thu, 31 May 2007 10:28:20 +0200 (CEST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 10:27:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 May 2007 10:27:51 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F267B9@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New revision of draft-ietf-dime-mip6-integrated-04.txt Thread-Index: AcejXZQdxs6NkyNCQNKq7cEh7/W4Ag== From: To: X-OriginalArrivalTime: 31 May 2007 08:27:51.0187 (UTC) FILETIME=[93E4A630:01C7A35D] Received-SPF: none X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Dime] New revision of draft-ietf-dime-mip6-integrated-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, We have submitted a new revision of draft-ietf-dime-mip6-integrated. The draft has gone through some serious editing changes since -03. Before the I-D shows up in IETF draft directories the documents is available at URL: http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/draft-ietf -dime-mip6-integrated-04.txt Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 31 18:50:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HttTj-0008TB-8i; Thu, 31 May 2007 18:50:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HttTV-00084L-Q0; Thu, 31 May 2007 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HttTU-0007Vx-SS; Thu, 31 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8D46B17611; Thu, 31 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HttT0-0003Fo-8M; Thu, 31 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 31 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-integrated-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-04.txt Pages : 19 Date : 2007-5-31 A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-integrated-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-integrated-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-31162329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-31162329.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu May 31 21:17:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtvlT-0007OH-O2; Thu, 31 May 2007 21:17:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtvlS-0007OC-FW for dime@ietf.org; Thu, 31 May 2007 21:17:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtvlP-0004Kz-Vh for dime@ietf.org; Thu, 31 May 2007 21:17:14 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 31 May 2007 18:17:12 -0700 X-IronPort-AV: i="4.16,371,1175497200"; d="url'?txt'208?scan'208,208"; a="376783711:sNHT203255340" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l511HBg7001740 for ; Thu, 31 May 2007 18:17:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l511H124005132 for ; Fri, 1 Jun 2007 01:17:11 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 18:17:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7A3EA.79A9C63E" Date: Thu, 31 May 2007 18:16:25 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504147213@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FYI: I-D ACTION:draft-zorn-dime-diameter-cc-appl-mib-02.txt Thread-Index: Acej1oYNuPpJzudfTrKJ9FgnGvJabAAE+a5g From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 01 Jun 2007 01:17:08.0971 (UTC) FILETIME=[93252BB0:01C7A3EA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4268; t=1180660631; x=1181524631; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20FYI=3A=20I-D=20ACTION=3Adraft-zorn-dime-diameter-cc-appl-mib- 02.txt=20 |Sender:=20; bh=U89D2qGLDkBcxn135JwJSRVJ+jguiUVmGC4rkUIQYDQ=; b=vJC2SgZXHd3iPF4vGHMnRgcp647lOiWkocntfcI0V0JdFtD4308GxMvAGo1awdo9US7Etjsk UyiLMXqkcdmCIM/d5TfuShsDP0LZqelMIhKwKt3MJFUeg8g+miyUB4LY; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Dime] FYI: I-D ACTION:draft-zorn-dime-diameter-cc-appl-mib-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A3EA.79A9C63E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Internet-Drafts@ietf.org allegedly scribbled on Thursday, May 31, 2007 3:50 PM: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 >=20 >=20 > Title : Diameter Credit Control Application MIB > Author(s) : S. Comerica, G. Zorn > Filename : draft-zorn-dime-diameter-cc-appl-mib-02.txt > Pages : 21 > Date : 2007-5-31 >=20 > Along with providing support for certain basic authentication, > authorization and accounting functions, the Diameter base protocol > is intended to provide a framework for AAA applications. >=20 > This document defines the Management Information Base (MIB) module > which describes the minimum set of objects needed to manage an > implementation of the Diameter Credit Control application. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zorn-dime-diameter-cc-appl-mib -02.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-zorn-dime-diameter-cc-appl-mib-02.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zorn-dime-diameter-cc-appl-mib-02.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------_=_NextPart_001_01C7A3EA.79A9C63E Content-Type: application/octet-stream; name="ATT2117639.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT2117639.TXT Content-Disposition: attachment; filename="ATT2117639.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy01LTMxMTU1MjI4LkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpvcm4tZGltZS1kaWFtZXRl ci1jYy1hcHBsLW1pYi0wMi50eHQNCg== ------_=_NextPart_001_01C7A3EA.79A9C63E Content-Type: application/octet-stream; name="draft-zorn-dime-diameter-cc-appl-mib-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-zorn-dime-diameter-cc-appl-mib-02.URL Content-Disposition: attachment; filename="draft-zorn-dime-diameter-cc-appl-mib-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC16b3JuLWRpbWUtZGlhbWV0ZXItY2MtYXBwbC1taWItMDIudHh0DQo= ------_=_NextPart_001_01C7A3EA.79A9C63E Content-Type: text/plain; name="ATT2117640.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2117640.txt Content-Disposition: attachment; filename="ATT2117640.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C7A3EA.79A9C63E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C7A3EA.79A9C63E--