From dime-bounces@ietf.org Thu Feb 01 01:40:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCVcK-0002ST-VH; Thu, 01 Feb 2007 01:40:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCVcJ-0002SM-HN for dime@ietf.org; Thu, 01 Feb 2007 01:40:19 -0500 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCVcG-0002P2-T9 for dime@ietf.org; Thu, 01 Feb 2007 01:40:19 -0500 Received: by wx-out-0506.google.com with SMTP id h31so446637wxd for ; Wed, 31 Jan 2007 22:40:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IbNllD4J5QmrAqTmT8SLfO4BelBkGTK+GLS5fYhIG2W7i7PbAMfcZGeB5spfod4uYOrUA3913VGzUzdOd7Yc1YMwEs1wrz8n/W2VhUYWSmV5xhlD0GV5SWyLqLK2JCt/0nfMw2WxqxwGw4TeMdf+xIxZi2M/zPYN+a42DT7Hsr0= Received: by 10.90.63.16 with SMTP id l16mr2610540aga.1170312016615; Wed, 31 Jan 2007 22:40:16 -0800 (PST) Received: by 10.90.88.1 with HTTP; Wed, 31 Jan 2007 22:40:16 -0800 (PST) Message-ID: Date: Thu, 1 Feb 2007 08:40:16 +0200 From: "Gil Shafran" To: "Internet-Drafts@ietf.org" Subject: Re: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-01.txt In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.6 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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="===============0427537949==" Errors-To: dime-bounces@ietf.org --===============0427537949== Content-Type: multipart/alternative; boundary="----=_Part_185_9639345.1170312016577" ------=_Part_185_9639345.1170312016577 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, There seem to be a problem with the peer state machine. State Wait-Conn-Ack/Elect is not reachable to the connection initiator (it is not a 'next state' of any initiator state), yet initiator events are expected in this state (I-Rcv-Conn-Ack and I-Rcv-Conn-Nack). Any idea? Regards, Gil Shafran On 1/31/07, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Diameter Maintenance and Extensions > Working Group of the IETF. > > Title : Diameter Base Protocol > Author(s) : V. Fajardo, J. Loughney > Filename : draft-ietf-dime-rfc3588bis-01.txt > Pages : 167 > Date : 2007-1-31 > > The Diameter base protocol is intended to provide an Authentication, > Authorization and Accounting (AAA) framework for applications such as > network access or IP mobility. Diameter is also intended to work in > both local Authentication, Authorization & Accounting and roaming > situations. This document specifies the message format, transport, > error reporting, accounting and security services to be used by all > Diameter applications. The Diameter base application needs to be > supported by all Diameter implementations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-dime-rfc3588bis-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-dime-rfc3588bis-01.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. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > ------=_Part_185_9639345.1170312016577 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,
 
There seem to be a problem with the peer state machine. State Wait-Conn-Ack/Elect is not reachable to the connection initiator (it is not a 'next state' of any initiator state), yet initiator events are expected in this state (I-Rcv-Conn-Ack and I-Rcv-Conn-Nack).
Any idea?
 
Regards,
Gil Shafran

 
On 1/31/07, Internet-Drafts@ietf.org <Internet-Drafts@ietf.org > wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

       Title           : Diameter Base Protocol
       Author(s)       : V. Fajardo, J. Loughney
       Filename        : draft-ietf-dime-rfc3588bis-01.txt
       Pages           : 167
       Date            : 2007-1-31

The Diameter base protocol is intended to provide an Authentication,
  Authorization and Accounting (AAA) framework for applications such as
  network access or IP mobility.  Diameter is also intended to work in
  both local Authentication, Authorization & Accounting and roaming
  situations.  This document specifies the message format, transport,
  error reporting, accounting and security services to be used by all
  Diameter applications.  The Diameter base application needs to be
  supported by all Diameter implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-01.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-dime-rfc3588bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
       mailserv@ietf.org.
In the body type:
       "FILE /internet-drafts/draft- ietf-dime-rfc3588bis-01.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.


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


------=_Part_185_9639345.1170312016577-- --===============0427537949== 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 --===============0427537949==-- From dime-bounces@ietf.org Thu Feb 01 07:05:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCagy-0007o8-4h; Thu, 01 Feb 2007 07:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCagw-0007nF-Q4 for dime@ietf.org; Thu, 01 Feb 2007 07:05:26 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCags-0001QU-CG for dime@ietf.org; Thu, 01 Feb 2007 07:05:26 -0500 Received: (qmail invoked by alias); 01 Feb 2007 12:05:09 -0000 Received: from unknown (EHLO [10.0.0.184]) [216.48.57.109] by mail.gmx.net (mp034) with SMTP; 01 Feb 2007 13:05:09 +0100 X-Authenticated: #29516787 Message-ID: <45C1D774.8080704@gmx.net> Date: Thu, 01 Feb 2007 07:05:08 -0500 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) 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: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Fritsche Wolfgang Subject: [Dime] Review of Diameter Mobile IPv6: NAS <-> HAAA Support 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, Wolfgang Fritsche has made a review of the Diameter Mobile IPv6: NAS <-> HAAA Support document. You find it in the attachment. Thank you, Wolfgang. Ciao Hannes ---------------------------------- Dear Hannes, here are my review comments: From the failover point of view the HA reliability DT of the mip6 WG currently follows an approach, which only involves the HAs themselves and (for the hard switch mode) the MN. As there is no AAA functionality involved in that, consequently no interfaces are required. Within ENABLE we see this somehow different. We definitively think the MSP AAA functionality has to be involved in the HA reliability approach, at least to be updated with the recently chosen HA. This is work we foresee to perform in 2007, so at the current time we've not progressed far enough to talk about required AAA interfaces, however, most likely it won't influence the NAS - AAAH interface, but more the HA - AAAH (and also the HA - AAAF, that is MSP AAA) interface. From a load sharing point of view, my main comments would be related to figure 8 and chapter 7. Currently this shows in message 2 how the NAS could provide to the AAAH (MSA AAA) in the DER message a proposal for a local HA assignment (address of FQDN of local HA), which then could selected by the AAAH. In ENABLE we see this somewhat different. The DER message sent to the AAAH (MSA AAA) won't contain any MIPv6 specific information when sent from the NAS to the AAAF (MSP AAA). Then the MSP AAA will include some MIPv6 features when forwarding the DER to the MSA AAA, indicating e.g. that the MSP is supporting local HA assignment, or that it supports MIPv6 extensions to the DHCPv6 on the NAS. The MSA AAA will then reply with a DEA, which could contain a MIPv6 authorization on its way to the MSP AAA, authorizing local HA assignment. If authorized, the MSP AAA will trigger HA selection (which is performed on the basis of HA load sharing), and provides back the selected HA within the DEA message to the NAS. Consequently the main differences between the ID and the ENABLE work are: - In ENABLE it is the MSP AAA and not the NAS which negotiates MIPv6 features with the MSA AAA - In ENABLE it is also the MSP AAA which finally selects the most suitable local HA based on load sharing, and not the NAS - ENABLE performs HA selection based on load sharing only after authorization for local HA assignment by the MSA Additionally I found some typos: - In chapter 7.1 you mixed up under [d] "MIP6-Home-Link-Prefix" with "MIP6-Home-Agent-Address" - In chapter 7.1 you mixed up under [d] "MIP6-Home-Address" with "MIP6-Home-Agent-FQDN" - In chapter 7.2 you mixed up under [d] "MIP6-Home-Link-Prefix" with "MIP6-Home-Agent-Address" - In chapter 7.2 you mixed up under [d] "MIP6-Home-Address" with "MIP6-Home-Agent-FQDN" - In chapter 7.2 under [d] it should be "AAA Command" instead of "AAR Command" Cheers, Wolfgang > Hi Wolfgang, > > could you do a review of our Diameter MIPv6 integrated scenario > document with a focus on load balancing and failover aspects. > > Here is the latest document: > > http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/draft-ietf-dime-mip6-integrated-02.txt > > Ciao > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 01 07:19:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCaue-00086q-Ui; Thu, 01 Feb 2007 07:19:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCaue-00086b-4H for dime@ietf.org; Thu, 01 Feb 2007 07:19:36 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCauc-0006AG-Lj for dime@ietf.org; Thu, 01 Feb 2007 07:19:36 -0500 Received: (qmail invoked by alias); 01 Feb 2007 12:19:33 -0000 Received: from unknown (EHLO [10.0.0.184]) [216.48.57.109] by mail.gmx.net (mp036) with SMTP; 01 Feb 2007 13:19:33 +0100 X-Authenticated: #29516787 Message-ID: <45C1DAD3.9040300@gmx.net> Date: Thu, 01 Feb 2007 07:19:31 -0500 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Dime] IPR Disclosure for draft-nakhjiri-dime-mip6-nsi-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 FYI -------- Original Message -------- Subject: Posting of IPR Disclosure Date: Wed, 31 Jan 2007 10:13:15 -0500 From: IETF Secretariat To: mnakhjiri@huawei.com, wanchangsheng@huawei.com CC: brc@zurich.ibm.com Dear Madjid Nakhjiri, Changsheng Wan: An IPR disclosure that pertains to your Internet-Draft entitled "A Network Service Identifier for separation of Mobile IPv6 service authorization from Mobile node authentication" (draft-nakhjiri-dime-mip6-nsi) was submitted to the IETF Secretariat on 2007-01-31 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Huawei Technologies Co., Ltd.'s statement about IPR claimed in draft-nakhjiri-dime-mip6-nsi-00.txt." The IETF Secretariat ----- End forwarded message ----- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 01 10:19:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdiW-0004Kq-Vb; Thu, 01 Feb 2007 10:19:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdiV-0004JF-D9 for dime@ietf.org; Thu, 01 Feb 2007 10:19:15 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdiS-0004pZ-QR for dime@ietf.org; Thu, 01 Feb 2007 10:19:15 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l11FJBKb029041 for ; Thu, 1 Feb 2007 16:19:11 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l11FJBfe016506 for ; Thu, 1 Feb 2007 16:19:11 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 16:19:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Feb 2007 16:19:11 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E7017466F0@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda Items for IETF 68 Thread-Index: AcdGFFLfILoCBA0OQv2etW28gmCxAw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 01 Feb 2007 15:19:11.0225 (UTC) FILETIME=[532F5690:01C74614] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Dime] Agenda Items for IETF 68 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,=20 =20 here is a first proposal for the DIME Meeting Agenda.=20 Please let me know if you would like to present something.=20 For the proposal please confirm whether you are willing to present the listed topics.=20 =20 Ciao Hannes & John =20 =20 ----------------- =20 =20 DIME Agenda =20 The discussions will focus on the charter items.=20 The goal is close open issues in order to progress the WG items.=20 =20 WG Update & Interop Report -------------------------- Chairs =20 Diameter Base Protocol ---------------------- Victor Fajardo http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-00.txt =20 =20 =20 Diameter Mobility ----------------- =20 - Diameter Mobile IPv6: HA-to-AAAH support=20 Julien Bournelle http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt =20 - Diameter Mobile IPv6: NAS <-> HAAA Support Jouni Korhonen =20 http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-02.t xt =20 Diameter QoS ------------ Glen Zorn or Pete McCann or Tina Tsou or Avri Doria http://www.ietf.org/internet-drafts/draft-zorn-dime-diameter-qos-00.txt =20 Diameter Application Design Guidelines=20 -------------------------------------- TBD TBD =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 01 10:29:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdsh-00059w-Jm; Thu, 01 Feb 2007 10:29:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdsf-00058W-K1; Thu, 01 Feb 2007 10:29:45 -0500 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 1HCdsa-0006v5-Qz; Thu, 01 Feb 2007 10:29:45 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l11FSDGJ017350; Thu, 1 Feb 2007 10:28:14 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45C206F9.4080005@tari.toshiba.com> Date: Thu, 01 Feb 2007 10:27:53 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Gil Shafran Subject: Re: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: dime@ietf.org, "Internet-Drafts@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 Gil, > There seem to be a problem with the peer state machine. State > Wait-Conn-Ack/Elect is not reachable to the connection initiator (it > is not a 'next state' of any initiator state), yet initiator events > are expected in this state (I-Rcv-Conn-Ack and I-Rcv-Conn-Nack). > Any idea? I think because during election, a peer is both an initiator and a responder so you have I-Rcv-Conn-Ack and I-Rcv-Conn-Nack while on Wait-Conn-Ack/Elect state. regards, victor > > Regards, > Gil Shafran > > > On 1/31/07, *Internet-Drafts@ietf.org > * > wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Diameter Maintenance and > Extensions Working Group of the IETF. > > Title : Diameter Base Protocol > Author(s) : V. Fajardo, J. Loughney > Filename : draft-ietf-dime-rfc3588bis-01.txt > Pages : 167 > Date : 2007-1-31 > > The Diameter base protocol is intended to provide an Authentication, > Authorization and Accounting (AAA) framework for applications > such as > network access or IP mobility. Diameter is also intended to > work in > both local Authentication, Authorization & Accounting and roaming > situations. This document specifies the message format, transport, > error reporting, accounting and security services to be used by all > Diameter applications. The Diameter base application needs to be > supported by all Diameter implementations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org > with the word unsubscribe > in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-dime-rfc3588bis-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org . > In the body type: > "FILE /internet-drafts/draft- ietf-dime-rfc3588bis-01.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. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 01 10:31:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCduj-0000WG-Kx; Thu, 01 Feb 2007 10:31:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdui-0000W4-9D for dime@ietf.org; Thu, 01 Feb 2007 10:31:52 -0500 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 1HCduh-0007MN-0A for dime@ietf.org; Thu, 01 Feb 2007 10:31:52 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l11FUT0T017367; Thu, 1 Feb 2007 10:30:30 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45C20781.8010400@tari.toshiba.com> Date: Thu, 01 Feb 2007 10:30:09 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [Dime] Agenda Items for IETF 68 References: <8F6CBC7005099442AECDB784C9E9D7E7017466F0@MCHP7R6A.ww002.siemens.net> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E7017466F0@MCHP7R6A.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, Minor correction: > Diameter Base Protocol > ---------------------- > Victor Fajardo > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-00.txt The latest doc is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-01.txt regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 01 15:50:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCiso-0002fj-Id; Thu, 01 Feb 2007 15:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCisi-0002ZZ-Nv; Thu, 01 Feb 2007 15:50:08 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCisc-0006qc-AJ; Thu, 01 Feb 2007 15:50:08 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4431D3296C; Thu, 1 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCisc-00084t-5D; Thu, 01 Feb 2007 15:50:02 -0500 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, 01 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-01.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) : P. Calhoun, et al. Filename : draft-ietf-dime-diameter-api-01.txt Pages : 45 Date : 2007-2-1 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-01.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-01.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-01.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-2-1111328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-api-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-api-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-1111328.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 Feb 01 16:21:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjN2-0004Br-0Z; Thu, 01 Feb 2007 16:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjN0-0004BJ-Bw for dime@ietf.org; Thu, 01 Feb 2007 16:21:26 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCjMr-0007CN-IP for dime@ietf.org; Thu, 01 Feb 2007 16:21:26 -0500 Received: (qmail invoked by alias); 01 Feb 2007 20:54:35 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 01 Feb 2007 21:54:35 +0100 X-Authenticated: #29516787 Message-ID: <45C25389.8040007@gmx.net> Date: Thu, 01 Feb 2007 15:54:33 -0500 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dime@ietf.org Subject: [Fwd: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-01.txt] 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: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org -------- Original Message -------- Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-01.txt Date: Thu, 01 Feb 2007 15:50:02 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: dime@ietf.org 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) : P. Calhoun, et al. Filename : draft-ietf-dime-diameter-api-01.txt Pages : 45 Date : 2007-2-1 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-01.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-01.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-01.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. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 01 19:43:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmWA-0004Tp-Hv; Thu, 01 Feb 2007 19:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmW8-0004Tg-S0 for dime@ietf.org; Thu, 01 Feb 2007 19:43:04 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCmW7-0003dS-J5 for dime@ietf.org; Thu, 01 Feb 2007 19:43:04 -0500 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 <0JCT00B4V8NOR8@usaga01-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:43:00 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCT00M7D8NN5C@usaga01-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:43:00 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCT00K2Q95ZKG@usaml03-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:54:04 -0800 (PST) Date: Thu, 01 Feb 2007 16:42:58 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Supplicant X.509 AVP? In-reply-to: To: "'Morrow, Glenn'" , "'Glen Zorn (gwz)'" Message-id: <005001c74663$16b4c200$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: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEawAAbK7EAABfHRIABkcaIg X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 If you don't want to do EAP-TLS because of the roundtrips involved in EAP-TLS and just want to use Diameter to check a cert, then it is a cert status checking signaling through Diameter. If you understand your scenario, you want to authenticate an ID that an end user application client is using for that application by using a private key and send a cert along to prove it. The application server cannot check the cert, so it resorts to the Diameter infrastructure to hit the CA or Cert status checking server. Isn't this your scenario? Madjid -----Original Message----- From: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com] Sent: Tuesday, January 30, 2007 4:49 PM To: Glen Zorn (gwz); Madjid Nakhjiri Cc: dime@ietf.org; Hannes Tschofenig Subject: RE: [Dime] Supplicant X.509 AVP? Yes there are other protocols that pass certs and these would likely be used as the backend for the Diameter Server. I.e. the Diameter Server is the application to these existing protocols. We just don't want to have to do two dips and that is why we want to transport the cert with Diameter - get it all done with one transaction from the Diameter client/Application Server perspective - not two. > > Seems like a Diameter based cert status checking mechanism.. Hmm -- that's not what I'm getting at all, but if you're right it seems like there are already at least a couple of other standard protocols that do this... ... This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 01 19:45:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmYj-000844-9G; Thu, 01 Feb 2007 19:45:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmYi-00083V-NP for dime@ietf.org; Thu, 01 Feb 2007 19:45:44 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCmYh-0003zL-Dk for dime@ietf.org; Thu, 01 Feb 2007 19:45:44 -0500 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 <0JCT00BF88S7R8@usaga01-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:45:43 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCT001SM8S67G@usaga01-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:45:42 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCT00K629AJKG@usaml03-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:56:47 -0800 (PST) Date: Thu, 01 Feb 2007 16:45:42 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Supplicant X.509 AVP? In-reply-to: To: "'Morrow, Glenn'" , "'Glen Zorn (gwz)'" Message-id: <005101c74663$77d2f890$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: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEawAAbK7EAABfHRIAAAQgtAAGRSjfA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 is understandable to not want to touch the app. However, it seems that the authentication and application authorization (using the cert) needs to happen before the application starts, so how do you want to handle the AAA exchange, something must trigger the exchange and that something has to come from the application itself. Madjid -----Original Message----- From: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com] Sent: Tuesday, January 30, 2007 4:55 PM To: Morrow, Glenn; Glen Zorn (gwz); Madjid Nakhjiri Cc: dime@ietf.org; Hannes Tschofenig Subject: RE: [Dime] Supplicant X.509 AVP? We also don't want to have to have to transport the cert at all at the application level - just start signing and digesting from the get go - granted challenge/nonce etc.. needed later as well. -----Original Message----- From: Morrow, Glenn Sent: Tuesday, January 30, 2007 5:49 PM To: 'Glen Zorn (gwz)'; Madjid Nakhjiri Cc: dime@ietf.org; Hannes Tschofenig Subject: RE: [Dime] Supplicant X.509 AVP? Yes there are other protocols that pass certs and these would likely be used as the backend for the Diameter Server. I.e. the Diameter Server is the application to these existing protocols. We just don't want to have to do two dips and that is why we want to transport the cert with Diameter - get it all done with one transaction from the Diameter client/Application Server perspective - not two. > > Seems like a Diameter based cert status checking mechanism.. Hmm -- that's not what I'm getting at all, but if you're right it seems like there are already at least a couple of other standard protocols that do this... ... This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 01 19:48:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmb0-00015x-2l; Thu, 01 Feb 2007 19:48:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCmay-00015f-8I for dime@ietf.org; Thu, 01 Feb 2007 19:48:04 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCmaw-0004fM-VT for dime@ietf.org; Thu, 01 Feb 2007 19:48:04 -0500 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 <0JCT00BM08W2R8@usaga01-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:48:02 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCT00MNV8W25C@usaga01-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:48:02 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCT00K7Z9EEKG@usaml03-in.huawei.com> for dime@ietf.org; Thu, 01 Feb 2007 16:59:06 -0800 (PST) Date: Thu, 01 Feb 2007 16:48:02 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Supplicant X.509 AVP? In-reply-to: To: "'Morrow, Glenn'" , "'Glen Zorn (gwz)'" Message-id: <005201c74663$cb3233c0$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: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEawAAbK7EAABfHRIABkrndQ X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 One more question. Is your certificate profile application-specific? Or the user uses one cert for any type of application? -----Original Message----- From: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com] Sent: Tuesday, January 30, 2007 4:49 PM To: Glen Zorn (gwz); Madjid Nakhjiri Cc: dime@ietf.org; Hannes Tschofenig Subject: RE: [Dime] Supplicant X.509 AVP? Yes there are other protocols that pass certs and these would likely be used as the backend for the Diameter Server. I.e. the Diameter Server is the application to these existing protocols. We just don't want to have to do two dips and that is why we want to transport the cert with Diameter - get it all done with one transaction from the Diameter client/Application Server perspective - not two. > > Seems like a Diameter based cert status checking mechanism.. Hmm -- that's not what I'm getting at all, but if you're right it seems like there are already at least a couple of other standard protocols that do this... ... This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 02 10:04:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzxW-0005tw-2T; Fri, 02 Feb 2007 10:04:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzxU-0005td-H3 for dime@ietf.org; Fri, 02 Feb 2007 10:04:12 -0500 Received: from uswgne22.uswest.com ([204.26.87.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzxS-0003Wh-Tt for dime@ietf.org; Fri, 02 Feb 2007 10:04:12 -0500 Received: from egate-ne8.uswc.uswest.com (egate-ne8.uswc.uswest.com [151.117.69.22]) by uswgne22.uswest.com (8/8) with ESMTP id l12F3sTq008753; Fri, 2 Feb 2007 09:03:54 -0600 (CST) Received: from itomae2ksm02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-ne8.uswc.uswest.com (8/8.13.7) with ESMTP id l12F3r3O027898; Fri, 2 Feb 2007 09:03:53 -0600 (CST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 09:03:54 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Supplicant X.509 AVP? Date: Fri, 2 Feb 2007 09:03:52 -0600 Message-ID: In-Reply-To: <005201c74663$cb3233c0$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? thread-index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEawAAbK7EAABfHRIABkrndQAB0YTrA= From: "Morrow, Glenn" Importance: normal Priority: normal To: "Madjid Nakhjiri" , "Glen Zorn \(gwz\)" X-OriginalArrivalTime: 02 Feb 2007 15:03:54.0007 (UTC) FILETIME=[5AE4BA70:01C746DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Good points Madjid: 1) If you don't want to do EAP-TLS because of the roundtrips involved in EAP-TLS and just want to use Diameter to check a cert, then it is a cert status checking signaling through Diameter. If you understand your scenario, you want to authenticate an ID that an end user application client is using for that application by using a private key and send a cert along to prove it. The application server cannot check the cert, so it resorts to the Diameter infrastructure to hit the CA or Cert status checking server. Isn't this your scenario? GM>=20 I would like to simply define an AVP to transfer a certificate chain that could be for many scenarios and applications: a) Use of Diameter as an AAA protocol between a local TLS or EAP-TLS server and a home network to do the certificate verification. In these scenarios the certificate would be passed via TLS or EAP and the application clients certificate would be passed over Diameter to the application server in the network. b) Use of Diameter as an AAA protocol to applications that use the asymetric keys of the certificates to hash/sign/digest the application signaling directly e.g. on the applications' registration or setup flows. Symmetric keying material can be created during this exchange for subsequent transactions. In these scenarios none of the certificates would pass over the application signaling but the certificate is passed over Diameter to the application server in the network so it can perform the crytographic operations using the public key contained in the certificate. /GM> 2) It is understandable to not want to touch the app. However, it seems that the authentication and application authorization (using the cert) needs to happen before the application starts, so how do you want to handle the AAA exchange, something must trigger the exchange and that something has to come from the application itself. GM>=20 The application must certainly start the process (in the case of a) or be the process itself (in the case of b). /GM> 3) One more question. Is your certificate profile application-specific? Or the user uses one cert for any type of application? GM> Certficate profiles should actually be deployment specific. I would prefer to the leave cert profiles to each application and even each deployment of application as needed. The ID I'm looking for here is simply an AVP definition to pass a certificate over Diameter. If diameter is used as the AAA protocol for an application then that application and even deployment of that application must document the cert profiles as well as other fields as AVPs that may or may not be contained solely within the certificate profile. The cert AVP ID should contain such suggestions for use probably in the security section. Thanks, Glenn GM> This communication is the property of Qwest and may contain confidential = or privileged information. Unauthorized use of this communication is = strictly=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 02 10:43:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0ZP-0003Zk-Uj; Fri, 02 Feb 2007 10:43:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0ZO-0003ZO-HO for dime@ietf.org; Fri, 02 Feb 2007 10:43:22 -0500 Received: from uswgco34.uswest.com ([199.168.32.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0ZK-0001yT-9x for dime@ietf.org; Fri, 02 Feb 2007 10:43:22 -0500 Received: from egate-co5.uswc.uswest.com (egate-co5.uswc.uswest.com [151.119.87.232]) by uswgco34.uswest.com (8/8) with ESMTP id l12FgqjB021594; Fri, 2 Feb 2007 08:42:52 -0700 (MST) Received: from itomae2ksm02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-co5.uswc.uswest.com (8/8.13.7) with ESMTP id l12FgpNM003438; Fri, 2 Feb 2007 08:42:52 -0700 (MST) Received: from itomae2km03.AD.QINTRA.COM ([10.6.9.152]) by itomae2ksm02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 09:42:52 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 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] Supplicant X.509 AVP? Date: Fri, 2 Feb 2007 09:42:50 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Supplicant X.509 AVP? thread-index: Acc9i2IhUMpmDMG3TcmfC5AoU7EeSgAqjwFgAXSUe1AABgIAUAAfgEawAAbK7EAABfHRIABkrndQAB0YTrAAAg+o4A== Importance: normal From: "Morrow, Glenn" Priority: normal To: "Morrow, Glenn" , "Madjid Nakhjiri" , "Glen Zorn \(gwz\)" X-OriginalArrivalTime: 02 Feb 2007 15:42:52.0005 (UTC) FILETIME=[CC72E950:01C746E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Maybe we should just name the AVP to be "client_application_credentials" and include a subtype string to identify the type of credential and then another type for the material itself. This would be generic enough to handle not only certs but all sorts of other keys as well? -----Original Message----- From: Morrow, Glenn [mailto:Glenn.Morrow@qwest.com]=20 Sent: Friday, February 02, 2007 8:04 AM To: Madjid Nakhjiri; Glen Zorn (gwz) Cc: dime@ietf.org Subject: RE: [Dime] Supplicant X.509 AVP? Good points Madjid: 1) If you don't want to do EAP-TLS because of the roundtrips involved in EAP-TLS and just want to use Diameter to check a cert, then it is a cert status checking signaling through Diameter. If you understand your scenario, you want to authenticate an ID that an end user application client is using for that application by using a private key and send a cert along to prove it. The application server cannot check the cert, so it resorts to the Diameter infrastructure to hit the CA or Cert status checking server. Isn't this your scenario? GM>=20 I would like to simply define an AVP to transfer a certificate chain that could be for many scenarios and applications: a) Use of Diameter as an AAA protocol between a local TLS or EAP-TLS server and a home network to do the certificate verification. In these scenarios the certificate would be passed via TLS or EAP and the application clients certificate would be passed over Diameter to the application server in the network. b) Use of Diameter as an AAA protocol to applications that use the asymetric keys of the certificates to hash/sign/digest the application signaling directly e.g. on the applications' registration or setup flows. Symmetric keying material can be created during this exchange for subsequent transactions. In these scenarios none of the certificates would pass over the application signaling but the certificate is passed over Diameter to the application server in the network so it can perform the crytographic operations using the public key contained in the certificate. /GM> 2) It is understandable to not want to touch the app. However, it seems that the authentication and application authorization (using the cert) needs to happen before the application starts, so how do you want to handle the AAA exchange, something must trigger the exchange and that something has to come from the application itself. GM>=20 The application must certainly start the process (in the case of a) or be the process itself (in the case of b). /GM> 3) One more question. Is your certificate profile application-specific? Or the user uses one cert for any type of application? GM> Certficate profiles should actually be deployment specific. I would prefer to the leave cert profiles to each application and even each deployment of application as needed. The ID I'm looking for here is simply an AVP definition to pass a certificate over Diameter. If diameter is used as the AAA protocol for an application then that application and even deployment of that application must document the cert profiles as well as other fields as AVPs that may or may not be contained solely within the certificate profile. The cert AVP ID should contain such suggestions for use probably in the security section. Thanks, Glenn GM> This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly=20 prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy=20 all copies of the communication and any attachments. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 02 11:48:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1aj-0003ah-0C; Fri, 02 Feb 2007 11:48:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1ah-0003aX-4s for dime@ietf.org; Fri, 02 Feb 2007 11:48:47 -0500 Received: from scalix.digitalroute.se ([213.142.6.19] helo=scalix.digitalroute.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD1ae-0006GR-Nl for dime@ietf.org; Fri, 02 Feb 2007 11:48:47 -0500 Received: from scalix.digitalroute.com (localhost [127.0.0.1]) by scalix.digitalroute.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id l12GmEe1024526 for ; Fri, 2 Feb 2007 17:48:14 +0100 Message-ID: <1553712624.1170434894650.JavaMail.root@scalix.digitalroute.com> Date: Fri, 2 Feb 2007 17:48:14 +0100 (CET) From: Mattias Lundstrom To: dime@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Scalix-Id: mattiasl@digitalroute.com X-Mailer: Scalix 10.0.5.1 X-MSMail-Priority: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Dime] Re: I-D ACTION:draft-ietf-dime-rfc3588bis-01.txt (Gil Shafran) 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 incorrect. You reach Wait-Conn-Ack/Elect from Wait-Conn-Ack.=20 So you have a pending connection request. Both I-Rcv-Conn-Ack and I-Rcv-Conn-Nack are very possible. // Regards, =A0 Mattias Lundstrom ----- Original Message ----- Date: Thu, 1 Feb 2007 08:40:16 +0200 From: "Gil Shafran" Subject: Re: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-01.txt To: "Internet-Drafts@ietf.org" Cc: dime@ietf.org Message-ID: =A0=A0=A0=A0 Content-Type: text/plain; charset=3D"iso-8859-1" Hi all, There seem to be a problem with the peer state machine. State Wait-Conn-Ack/Elect is not reachable to the connection initiator (it is not a 'next state' of any initiator state), yet initiator events are expected i= n this state (I-Rcv-Conn-Ack and I-Rcv-Conn-Nack). Any idea? Regards, Gil Shafran _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Feb 04 10:26:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDjG0-0002sf-QB; Sun, 04 Feb 2007 10:26:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDjFz-0002sV-C2; Sun, 04 Feb 2007 10:26:19 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HDjFx-0002i1-G8; Sun, 04 Feb 2007 10:26:19 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm10a45c670e2; Sun, 04 Feb 2007 23:36:23 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd45c11b7d; Thr, 01 Feb 2007 05:36:19 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1f45c134de; Thr, 01 Feb 2007 05:36:18 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 01 Feb 2007 05:36:18 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMPi-0003jM-7w; Wed, 31 Jan 2007 15:50:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMPZ-0003cY-S4; Wed, 31 Jan 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCMPY-0004vc-I0; Wed, 31 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 76AF72AC9D; Wed, 31 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCMP4-0004xY-7n; Wed, 31 Jan 2007 15:50:02 -0500 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, 31 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-01.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, J. Loughney Filename : draft-ietf-dime-rfc3588bis-01.txt Pages : 167 Date : 2007-1-31 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-rfc3588bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-rfc3588bis-01.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-1-31115054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-31115054.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Mon Feb 05 12:01:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7DD-0008Oe-BA; Mon, 05 Feb 2007 12:01:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7DB-0008NV-Fu for dime@ietf.org; Mon, 05 Feb 2007 12:01:01 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7DA-0001W5-2Z for dime@ietf.org; Mon, 05 Feb 2007 12:01:01 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id D32873F271 for ; Mon, 5 Feb 2007 12:00:53 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l15H0qc8012806 for ; Mon, 5 Feb 2007 12:00:52 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] The Auditing Problem : Ownership of resources Date: Mon, 5 Feb 2007 11:56:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <33656995C5C5094A983DE84DA649A924EB19D0@lulex02.ad.operax.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ulf, With that type of model, how are they going to deal with rogue endpoints, for example if a SIP UA advertises certain voice codec in SDP but actually pumps much larger amounts of traffic? This would impact traffic for other endpoints as well. I think one would need a per flow reservation mechanism, where the standard 5-tuple and corresponding QoS characteristics are fed to the entity which actually receives the IP packets. My understanding of RACS Functional Architecture specified in ETSI ES 282 003 was also in that direction. With that mode of operation, IP packet processor (RCEF in ETSI terminology) would have knowledge about all existing bandwith QoS reservations. Thanks, Tolga > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Thursday, January 25, 2007 3:41 AM > To: dime@ietf.org > Subject: RE: [Dime] The Auditing Problem : Ownership of resources > > > Hi Tolga, > > I absolutely agree to that your scenario as of below is valid and I also > agree that the physical device can be expected to correctly > approve/disapprove new reservation requests after a failover of a > Diameter server controlling the device. > > The model defined by ETSI TISPAN differs from the above scenario in the > sence that the Diameter server bing the so called A-RACF is a booking > system for resources. It keeps knowledge of aggregate resources in the > underlying transport network (e.g. bandwidth allocated to the DiffServ > EF PHB on network interfaces) and may install policies for traffic > conditioning in transport devices dedicated to that task (e.g. a BRAS). > This means that reservations of resources are not knowned by network > devices (i.e. except policies for traffic conditioning) and consequently > the Diameter server cannot rely on states kept in network devices to > correctly answer reservation reqiuests (before and after a failover). > > Best regards, > Ulf > > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: den 24 januari 2007 23:07 > To: dime@ietf.org > Subject: [Dime] The Auditing Problem : Ownership of resources > > Hi Ulf, > > I wanted to dig in a bit more into the ownership of resources concept, > which came up during the last couple of e-mails we exchanged for > auditing problem. > This again is probably a relatively side-issue but still it could be > good to clarify it. > > I see the following elements in this problem: > a) User to physical address mapping > I guess, in the context of this problem we assume this is already done > and this mapping data can be accessed by other entities. > > b) Delivery of user resource reservation request This will happen with a > Diameter request from Diameter client to Diameter server. > > c) Policy enforcement > Diameter server enforces policy based on user identity and the policy > applicable for the user. > > d) Reserving/Providing the physical resource The Diameter server queries > the physical mapping for the user and requests reservation of the > resources from the physical device providing the resource (e.g. a > router). Depending on the answer received from the device providing the > resource, Diameter server generates the answer to the Diameter client. > > In this model, physical device would always have the information of all > reservations for which it is providing the resources. Even after a > Diameter server restart/backup takeover, physical device can > approve/disapprove new reservation requests based on that information, > i.e. the check to make sure that resources are not overbooked can be > done on the physical resource provider (Diameter server still would > perform policy enforcement) > > It could be the case that c) and d) is performed in the same entity. In > such a case failure of that entity would cause the resources to be > unavailable and after a restart all of the resources would be available. > > I am not claiming this is the only way of reserving the resources, nor > the best way. I just wanted to clarify the model I had in mind regarding > ownership/reservation of resources. > > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 05 12:32:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7hm-0001FH-3m; Mon, 05 Feb 2007 12:32:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7hk-0001F5-Ss for dime@ietf.org; Mon, 05 Feb 2007 12:32:36 -0500 Received: from floor.dave.sonera.fi ([131.177.130.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7hg-00071Z-9F for dime@ietf.org; Mon, 05 Feb 2007 12:32:36 -0500 Received: from floor.dave.sonera.fi (localhost [127.0.0.1]) by floor.dave.sonera.fi (Sendmail) with ESMTP id l15HWUpc020661 for ; Mon, 5 Feb 2007 19:32:31 +0200 (EET) Received: from [131.177.105.35] (ws35.secureuser.sonera.fi [131.177.105.35]) by floor.dave.sonera.fi (Sendmail) with ESMTP id l15HWN99020658; Mon, 5 Feb 2007 19:32:24 +0200 (EET) Message-ID: <45C76A25.1080105@teliasonera.com> Date: Mon, 05 Feb 2007 19:32:21 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Fritsche Wolfgang Subject: Re: [Dime] Review of Diameter Mobile IPv6: NAS <-> HAAA Support References: <45C1D774.8080704@gmx.net> In-Reply-To: <45C1D774.8080704@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Wolfgang, et al, Thanks for your detailed comments. See my comments inline. Hannes Tschofenig kirjoitti: > Hi all, > > Wolfgang Fritsche has made a review of the Diameter Mobile IPv6: NAS <-> > HAAA Support document. You find it in the attachment. Thank you, Wolfgang. > > Ciao > Hannes > > ---------------------------------- > > > Dear Hannes, > > here are my review comments: > > From the failover point of view the HA reliability DT of the mip6 WG > currently follows an approach, which only involves the HAs themselves > and (for the hard switch mode) the MN. As there is no AAA functionality > involved in that, consequently no interfaces are required. Within ENABLE > we see this somehow different. We definitively think the MSP AAA > functionality has to be involved in the HA reliability approach, at > least to be updated with the recently chosen HA. This is work we foresee A good point. However, I'm not sure whether this I-D is supposed to try solve HA assignment any further than the initial assignment during the bootstrap. > to perform in 2007, so at the current time we've not progressed far > enough to talk about required AAA interfaces, however, most likely it > won't influence the NAS - AAAH interface, but more the HA - AAAH (and > also the HA - AAAF, that is MSP AAA) interface. Ok. > From a load sharing point of view, my main comments would be related to > figure 8 and chapter 7. Currently this shows in message 2 how the NAS > could provide to the AAAH (MSA AAA) in the DER message a proposal for a > local HA assignment (address of FQDN of local HA), which then could > selected by the AAAH. In ENABLE we see this somewhat different. The DER MSA does not need to respect the HA hint from NAS/ASP. MSA is free to override it. > message sent to the AAAH (MSA AAA) won't contain any MIPv6 specific > information when sent from the NAS to the AAAF (MSP AAA). Then the MSP Hmm.. as this I-D does not have a new application these AVPs in DER/AAR serve also as an implicit advertisement of MIP support. > AAA will include some MIPv6 features when forwarding the DER to the MSA > AAA, indicating e.g. that the MSP is supporting local HA assignment, or > that it supports MIPv6 extensions to the DHCPv6 on the NAS. The MSA AAA > will then reply with a DEA, which could contain a MIPv6 authorization on > its way to the MSP AAA, authorizing local HA assignment. If authorized, > the MSP AAA will trigger HA selection (which is performed on the basis > of HA load sharing), and provides back the selected HA within the DEA > message to the NAS. Consequently the main differences between the ID and > the ENABLE work are: > - In ENABLE it is the MSP AAA and not the NAS which negotiates MIPv6 > features with the MSA AAA Ok. The MSA/MSP is still always able to override whatevet the nAS/ASP proposes. > - In ENABLE it is also the MSP AAA which finally selects the most > suitable local HA based on load sharing, and not the NAS I just wonder how this is supposed to work when the MN is roaming in a visited operator ASP? > - ENABLE performs HA selection based on load sharing only after > authorization for local HA assignment by the MSA > > Additionally I found some typos: > - In chapter 7.1 you mixed up under [d] "MIP6-Home-Link-Prefix" with > "MIP6-Home-Agent-Address" > - In chapter 7.1 you mixed up under [d] "MIP6-Home-Address" with > "MIP6-Home-Agent-FQDN" > - In chapter 7.2 you mixed up under [d] "MIP6-Home-Link-Prefix" with > "MIP6-Home-Agent-Address" > - In chapter 7.2 you mixed up under [d] "MIP6-Home-Address" with > "MIP6-Home-Agent-FQDN" > - In chapter 7.2 under [d] it should be "AAA Command" instead of "AAR > Command" Ok.. wonders of slobby copy-pasting ;) Cheers, Jouni > > Cheers, > > Wolfgang > > > > Hi Wolfgang, > > > > could you do a review of our Diameter MIPv6 integrated scenario > > document with a focus on load balancing and failover aspects. > > > > Here is the latest document: > > > > http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/draft-ietf-dime-mip6-integrated-02.txt > > > > Ciao > > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 07 02:30:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEhGH-0004hX-RS; Wed, 07 Feb 2007 02:30:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEhGG-0004g9-KB for dime@ietf.org; Wed, 07 Feb 2007 02:30:36 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEhGE-0002gY-SS for dime@ietf.org; Wed, 07 Feb 2007 02:30:36 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l177UMSn055254 for ; Wed, 7 Feb 2007 08:30:22 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] The Auditing Problem : Ownership of resources Date: Wed, 7 Feb 2007 08:30:22 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924F340C1@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The Auditing Problem : Ownership of resources Thread-Index: AcdJR1l8Kj3a0l++S/ehETrServQOQBPYEkg From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 07 Feb 2007 08:30:22 +0100 (CET) X-Spam-Status: No, score=-52.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/2529/Tue Feb 6 20:25:02 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga,=20 Yes, endpoints that cannot be trusted certainly need to be controlled in some way (e.g. through traffic conditioning). Basically the A-RACF has potentially two sources of information for retreving reservation states being lost; a) network devices performing per-flow traffic conditioning and b) the application functions that originally requested the resource reservations (e.g. SIP proxies). As I see it, which one of a) and b) that is best suited to deliver the desired information depends on the actual scenario in question. Reasons for why a) is less suitable than b) include that;=20 1) the endpoints are trusted and there are therefore no traffic conditioning implemented in the network,=20 2) traffic conditioning is performed on a per-aggregate basis (e.g. for performance and/or scalability reasons),=20 3) the failover between A-RACF entities is accompanied by a network failover resulting in states being lost also in the network devices performing traffic conditioning (i.e. the A-RACF may even need to rebuild states in the network), and 4) network devices are not aware of all the properties of the reservation states in the A-RACF (e.g. admission priorities and/or virtual resource partitioning affecting the admission control process but not the traffic conditioning).=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 5 februari 2007 17:56 To: dime@ietf.org Subject: RE: [Dime] The Auditing Problem : Ownership of resources Hi Ulf, With that type of model, how are they going to deal with rogue endpoints, for example if a SIP UA advertises certain voice codec in SDP but actually pumps much larger amounts of traffic? This would impact traffic for other endpoints as well. I think one would need a per flow reservation mechanism, where the standard 5-tuple and corresponding QoS characteristics are fed to the entity which actually receives the IP packets. My understanding of RACS Functional Architecture specified in ETSI ES 282 003 was also in that direction. With that mode of operation, IP packet processor (RCEF in ETSI terminology) would have knowledge about all existing bandwith QoS reservations. Thanks, Tolga > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Thursday, January 25, 2007 3:41 AM > To: dime@ietf.org > Subject: RE: [Dime] The Auditing Problem : Ownership of resources > > > Hi Tolga, > > I absolutely agree to that your scenario as of below is valid and I=20 > also agree that the physical device can be expected to correctly=20 > approve/disapprove new reservation requests after a failover of a=20 > Diameter server controlling the device. > > The model defined by ETSI TISPAN differs from the above scenario in=20 > the sence that the Diameter server bing the so called A-RACF is a=20 > booking system for resources. It keeps knowledge of aggregate=20 > resources in the underlying transport network (e.g. bandwidth=20 > allocated to the DiffServ EF PHB on network interfaces) and may=20 > install policies for traffic conditioning in transport devices dedicated to that task (e.g. a BRAS). > This means that reservations of resources are not knowned by network=20 > devices (i.e. except policies for traffic conditioning) and=20 > consequently the Diameter server cannot rely on states kept in network > devices to correctly answer reservation reqiuests (before and after a failover). > > Best regards, > Ulf > > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: den 24 januari 2007 23:07 > To: dime@ietf.org > Subject: [Dime] The Auditing Problem : Ownership of resources > > Hi Ulf, > > I wanted to dig in a bit more into the ownership of resources concept, > which came up during the last couple of e-mails we exchanged for=20 > auditing problem. > This again is probably a relatively side-issue but still it could be=20 > good to clarify it. > > I see the following elements in this problem: > a) User to physical address mapping > I guess, in the context of this problem we assume this is already done > and this mapping data can be accessed by other entities. > > b) Delivery of user resource reservation request This will happen with > a Diameter request from Diameter client to Diameter server. > > c) Policy enforcement > Diameter server enforces policy based on user identity and the policy=20 > applicable for the user. > > d) Reserving/Providing the physical resource The Diameter server=20 > queries the physical mapping for the user and requests reservation of=20 > the resources from the physical device providing the resource (e.g. a=20 > router). Depending on the answer received from the device providing=20 > the resource, Diameter server generates the answer to the Diameter client. > > In this model, physical device would always have the information of=20 > all reservations for which it is providing the resources. Even after a > Diameter server restart/backup takeover, physical device can=20 > approve/disapprove new reservation requests based on that information, > i.e. the check to make sure that resources are not overbooked can be=20 > done on the physical resource provider (Diameter server still would=20 > perform policy enforcement) > > It could be the case that c) and d) is performed in the same entity.=20 > In such a case failure of that entity would cause the resources to be=20 > unavailable and after a restart all of the resources would be available. > > I am not claiming this is the only way of reserving the resources, nor > the best way. I just wanted to clarify the model I had in mind=20 > regarding ownership/reservation of resources. > > 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 _______________________________________________ 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 Feb 07 07:33:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElz8-0008H7-Nr; Wed, 07 Feb 2007 07:33:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElz7-0008GJ-Oh; Wed, 07 Feb 2007 07:33:13 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HElyg-0006Wc-1P; Wed, 07 Feb 2007 07:32:49 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l17CWila017847; Wed, 7 Feb 2007 13:32:45 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l17CWfas024621; Wed, 7 Feb 2007 13:32:44 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 13:32:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Feb 2007 13:32:42 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E7016EB21A@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic Thread-Index: AcdKqLeBiNz3ABbqRUKWd6B6gKxLggACiiBg From: "Tschofenig, Hannes" To: , , X-OriginalArrivalTime: 07 Feb 2007 12:32:43.0378 (UTC) FILETIME=[10715520:01C74AB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Dime] Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic 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 ----- Forwarded message from ietf-secretariat@ietf.org ----- To: ietf-announce@ietf.org Cc:=20 From: ietf-secretariat@ietf.org Date: Fri, 02 Feb 2007 00:00:01 -0500 Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF=20 Meeting in Prague, Czech Republic=20 Precedence: list Errors-To: ietf-announce-bounces@ietf.org There are two (2) Internet-Draft cutoff dates for the 68th=20 IETF Meeting in Prague, Czech Republic: February 26th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 February 26th at 9:00 AM ET. As always, all initial submissions with a=20 filename beginning with "draft-ietf" must be approved by the=20 appropriate WG Chair before they can be processed or announced. The=20 Secretariat would appreciate receiving WG Chair approval by Monday,=20 February 19th at 9:00 AM ET. March 5th: Cutoff Date for Revised (i.e., version -01 and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, March 5th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, March 19th at 9:00=20 AM ET, when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 68th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_68.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 07 15:32:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtSm-00043a-Ph; Wed, 07 Feb 2007 15:32:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtSl-00043V-G4 for dime@ietf.org; Wed, 07 Feb 2007 15:32:19 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HEtSg-0000wO-2y for dime@ietf.org; Wed, 07 Feb 2007 15:32:19 -0500 Received: (qmail invoked by alias); 07 Feb 2007 20:32:12 -0000 X-Provags-ID: V01U2FsdGVkX1+1o6xLmxC1f9+nPRyA+NlGxFLVEjt8afsz6r8Wim teCw== Message-ID: <45CA374B.6070301@gmx.net> Date: Wed, 07 Feb 2007 21:32:11 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: 4adaf050708fb13be3316a9eee889caa Cc: sudhir.mittal@relianceada.com Subject: [Dime] Liaison Request from ITU-T 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 --Resend since I am not sure whether my mail reached the mailing list. Hi all, the chairs have received a liaison document from the ITU-T with the title: "RFC 3588 - Requirement of Session State Machine for Diameter Server Initiated Session" Thanks to Tina and Sudhir. Here is the extracted text: " ITU-T study group 11 question 5 would like to acknowledge the versatility of the Diameter Protocol for its suitability over many interfaces in Next Generation Networks (NGN). The group has decided to use the protocol (as one of the alternatives) for the Rs and Rw interfaces in the Resource and Admission Control Function (RACF) part of the NGN. The latest drafts of the corresponding protocol specification documents for the Rs and Rw interfaces are Q.3301.1 and Q.rcp3.3 (T05-NGN.GSI-DOC-0127) respectively. The Rw interface exists between Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE) where PD-PE acts as the diameter server and the PE-PE acts as the diameter client. For the pull mode of operation, the PE-PE establishes a diameter session and the corresponding state machine is covered in section 8.1 of the RFC 3588. But for the push mode there is a requirement that the PD-PE, acting as a diameter server, initiates the session for which no state machine has been provided in the RFC. The RFC, however, in the last paragraph of its section 8.8 indicates indirectly that there is possibility of the session initiation by the server. ITU-T study group 11 question 5 would like to look for comments and enhancement of the diameter protocol to clearly specify the session state machine for the case of diameter server initiated session. " Please find the full document at the Wiki page: http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 07 16:55:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEulC-00066w-Sv; Wed, 07 Feb 2007 16:55:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEuDx-0002ql-Rv for dime@ietf.org; Wed, 07 Feb 2007 16:21:05 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEtzV-0006s2-P2 for dime@ietf.org; Wed, 07 Feb 2007 16:06:47 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 91A954B670 for ; Wed, 7 Feb 2007 16:06:04 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l17L5x33001242 for ; Wed, 7 Feb 2007 16:06:04 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Liaison Request from ITU-T Date: Wed, 7 Feb 2007 16:01:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <45CA374B.6070301@gmx.net> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 guess 8.8 is a generic section regarding the use of Session-Id AVP and the statement that sessions are usually initiated by clients (which implies that they may be initiated by servers) does not necessarily hold for all Diameter applications (that is the part about they may be initiated by servers). To me, it doesn't seem to be an oversight that there is no authorization state machine defined for server initiated sessions. What would be the semantics for that mode of operation? What would be the request sent from server to client and for what purpose? Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, February 07, 2007 3:32 PM > To: dime@ietf.org > Cc: sudhir.mittal@relianceada.com > Subject: [Dime] Liaison Request from ITU-T > > > --Resend since I am not sure whether my mail reached the mailing list. > > Hi all, > > the chairs have received a liaison document from the ITU-T with the > title: "RFC 3588 - Requirement of Session State Machine for Diameter > Server Initiated Session" > > Thanks to Tina and Sudhir. > > Here is the extracted text: > > " > ITU-T study group 11 question 5 would like to acknowledge the > versatility of the Diameter Protocol for its suitability over many > interfaces in Next Generation Networks (NGN). The group has decided to > use the protocol (as one of the alternatives) for the Rs and Rw > interfaces in the Resource and Admission Control Function (RACF) part of > the NGN. The latest drafts of the corresponding protocol specification > documents for the Rs and Rw interfaces are Q.3301.1 and Q.rcp3.3 > (T05-NGN.GSI-DOC-0127) respectively. > > The Rw interface exists between Policy Decision Physical Entity (PD-PE) > and the Policy Enforcement Physical Entity (PE-PE) where PD-PE acts as > the diameter server and the PE-PE acts as the diameter client. For the > pull mode of operation, the PE-PE establishes a diameter session and the > corresponding state machine is covered in section 8.1 of the RFC 3588. > But for the push mode there is a requirement that the PD-PE, acting as a > diameter server, initiates the session for which no state machine has > been provided in the RFC. The RFC, however, in the last paragraph of > its section 8.8 indicates indirectly that there is possibility of the > session initiation by the server. > > ITU-T study group 11 question 5 would like to look for comments and > enhancement of the diameter protocol to clearly specify the session > state machine for the case of diameter server initiated session. > " > > Please find the full document at the Wiki page: > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap > > Ciao > Hannes > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 07 18:46:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEwUn-00057O-5f; Wed, 07 Feb 2007 18:46:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEwUl-00057F-Pw for dime@ietf.org; Wed, 07 Feb 2007 18:46:35 -0500 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 1HEwUU-0000N2-My for dime@ietf.org; Wed, 07 Feb 2007 18:46:35 -0500 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 l17Njq3f046934; Wed, 7 Feb 2007 18:45:52 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45CA64B1.2020405@tari.toshiba.com> Date: Wed, 07 Feb 2007 18:45:53 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] Liaison Request from ITU-T References: <45CA374B.6070301@gmx.net> In-Reply-To: <45CA374B.6070301@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sudhir.mittal@relianceada.com, 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 Comments inline: > The Rw interface exists between Policy Decision Physical Entity > (PD-PE) and the Policy Enforcement Physical Entity (PE-PE) where PD-PE > acts as the diameter server and the PE-PE acts as the diameter > client. For the pull mode of operation, the PE-PE establishes a > diameter session and the corresponding state machine is covered in > section 8.1 of the RFC 3588. But for the push mode there is a > requirement that the PD-PE, acting as a diameter server, initiates the > session for which no state machine has been provided in the RFC. I'm not familiar with the Rw architecture but would'nt it be possible for the PD-PE to initiate a 'client session' towards the PE-PE ... regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 07 20:22:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HExzh-0000eI-Fz; Wed, 07 Feb 2007 20:22:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HExzg-0000e8-VB for dime@ietf.org; Wed, 07 Feb 2007 20:22:36 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HExzf-0005ef-H4 for dime@ietf.org; Wed, 07 Feb 2007 20:22:36 -0500 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 l181MKPX007828; Wed, 7 Feb 2007 19:22:30 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 19:21:57 -0600 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] Liaison Request from ITU-T Date: Wed, 7 Feb 2007 19:21:56 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02ABC3@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Liaison Request from ITU-T Thread-Index: AcdLAspMk3QjiTbfRXaMLWC5syAcpAAE3XpA References: <45CA374B.6070301@gmx.net> From: "Sun, Dong \(Dong\)" To: "Tolga Asveren" , X-OriginalArrivalTime: 08 Feb 2007 01:21:57.0356 (UTC) FILETIME=[865B7AC0:01C74B1F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, In the context of QoS/policy control application, there are two models identified: Push and Pull mode (you can find details from the I-D (http://www.ietf.org/internet-drafts/draft-sun-dime-diameter-resource-co ntrol-requirements-00.txt) and some slides were presented in IETF 67 concerning the use case).=20 The trend of policy control application in the industry is moving towards an universal architecture to support both pull and push modes. ITU-T has already defined it in its RACF Release 1. (ETSI TISPAN also added similar requirement in its ongoing RACS Release 2 work; 3GPP also intends to support both mobile networks and fixed networks within its PCC framework, which will require a Push mode in addition to the current Pull mode).=20 The main issue is that, according to 3GPP R7 Gx spec, in the Pull mode the policy enforcement point (i.e. PE-FE in ITU-T) serves as a Diameter client and the policy decision point (i.e. PD-FE in ITU-T) serve as a Diameter server.=20 Meanwhile, for the Push mode, the same PD-FE also needs to initiate Diameter session towards the PE-FE. Theoretically, the PD-FE may serve as a Diameter client in Push mode. However, it seems quite complicated to maintain two types of relationships between a pair of Diameter entities dynamically on a per call basis. On the other hand, if a fixed client-server relationship is employed between PE-FE and PD-FE, since the Diameter client may be already embedded in the router for other purpose (e.g. AAA), then no additional protocol stack and session state maintenance are required in the router exclusively in order to support the policy control.=20 Hope this help. (also correspond to Victor's question in a separate email). In addition, I'd like to know how difficult to make Diameter server initiate a new session. Or is it possible to define this kind of state machine in a separate application if base protocol does not cover it. Regards, Dong -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: Wednesday, February 07, 2007 4:01 PM To: dime@ietf.org Subject: RE: [Dime] Liaison Request from ITU-T I guess 8.8 is a generic section regarding the use of Session-Id AVP and the statement that sessions are usually initiated by clients (which implies that they may be initiated by servers) does not necessarily hold for all Diameter applications (that is the part about they may be initiated by servers). To me, it doesn't seem to be an oversight that there is no authorization state machine defined for server initiated sessions. What would be the semantics for that mode of operation? What would be the request sent from server to client and for what purpose? Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, February 07, 2007 3:32 PM > To: dime@ietf.org > Cc: sudhir.mittal@relianceada.com > Subject: [Dime] Liaison Request from ITU-T > > > --Resend since I am not sure whether my mail reached the mailing list. > > Hi all, > > the chairs have received a liaison document from the ITU-T with the > title: "RFC 3588 - Requirement of Session State Machine for Diameter=20 > Server Initiated Session" > > Thanks to Tina and Sudhir. > > Here is the extracted text: > > " > ITU-T study group 11 question 5 would like to acknowledge the=20 > versatility of the Diameter Protocol for its suitability over many=20 > interfaces in Next Generation Networks (NGN). The group has decided=20 > to use the protocol (as one of the alternatives) for the Rs and Rw=20 > interfaces in the Resource and Admission Control Function (RACF) part=20 > of the NGN. The latest drafts of the corresponding protocol=20 > specification documents for the Rs and Rw interfaces are Q.3301.1 and=20 > Q.rcp3.3 > (T05-NGN.GSI-DOC-0127) respectively. > > The Rw interface exists between Policy Decision Physical Entity=20 > (PD-PE) and the Policy Enforcement Physical Entity (PE-PE) where PD-PE > acts as the diameter server and the PE-PE acts as the diameter client. > For the pull mode of operation, the PE-PE establishes a diameter=20 > session and the corresponding state machine is covered in section 8.1 of the RFC 3588. > But for the push mode there is a requirement that the PD-PE, acting as > a diameter server, initiates the session for which no state machine=20 > has been provided in the RFC. The RFC, however, in the last paragraph > of its section 8.8 indicates indirectly that there is possibility of=20 > the session initiation by the server. > > ITU-T study group 11 question 5 would like to look for comments and=20 > enhancement of the diameter protocol to clearly specify the session=20 > state machine for the case of diameter server initiated session. > " > > Please find the full document at the Wiki page: > http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap > > 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 Thu Feb 08 08:31:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9NL-0001EV-Bn; Thu, 08 Feb 2007 08:31:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9NJ-0001EO-Tj for dime@ietf.org; Thu, 08 Feb 2007 08:31:45 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HF9NI-0003PG-IA for dime@ietf.org; Thu, 08 Feb 2007 08:31:45 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 2F6F8494A6 for ; Thu, 8 Feb 2007 08:31:38 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l18DVbsa003466 for ; Thu, 8 Feb 2007 08:31:37 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Liaison Request from ITU-T Date: Thu, 8 Feb 2007 08:26:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <09C9068466B79E4C938DC7737562404D02ABC3@ILEXC2U01.ndc.lucent.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Dong, [..snip..] > > In addition, I'd like to know how difficult to make Diameter server > initiate a new session. Or is it possible to define this kind of state > machine in a separate application if base protocol does not cover it. [TOLGA]That is exactly my point, if an application sees it necessary, they can define that type of behavior with the corresponding state machine. What I try to understand is, is there a need for a change in the base protocol for that? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 08 09:58:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAir-0005EH-L4; Thu, 08 Feb 2007 09:58:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAip-0005Di-Su for dime@ietf.org; Thu, 08 Feb 2007 09:58:03 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFAim-00069U-QV for dime@ietf.org; Thu, 08 Feb 2007 09:58:03 -0500 Received: (qmail invoked by alias); 08 Feb 2007 14:57:59 -0000 X-Provags-ID: V01U2FsdGVkX1++wiomAuK+Si6rEN04ibpT20ILJGI9eCfTa2v3pq jzEw== Message-ID: <45CB3A76.80708@gmx.net> Date: Thu, 08 Feb 2007 15:57:58 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: dime@ietf.org, ECRIT , ietf-keyprov@safehaus.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Subject: [Dime] Important: Remember to use latest boilerplate in drafts 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üngliche Nachricht----- Von: IETF Chair [mailto:chair@ietf.org] Gesendet: Donnerstag, 8. Februar 2007 11:15 An: IETF Announcement list Betreff: Important: Remember to use latest boilerplate in drafts Hi, With the submission deadlines before the Prague meeting coming up, please remember that all drafts need to use the latest boilerplate text (see below for details). February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) March 5, Monday - Internet Draft final submission cut-off by 09:00 ET (14:00 UTC/GMT) Thanks Brian Carpenter -------- Original Message -------- Subject: Internet-Draft Boilerplate Reminder Date: Mon, 15 Jan 2007 11:51:16 -0500 From: IETF Secretariat To: IETF Announcement list CC: iesg@ietf.org This message is to remind you that as of February 1, 2007 the IETF Secretariat will no longer accept Internet-Drafts with the old (i.e. pre RFC 4748) boilerplate. For your convenience, below is the text of the message that was sent to the IETF Announcement List by the IETF Chair on October 26, 2006 with Subject: Update to Internet Draft and RFC Boilerplate. The IETF Secretariat. -------------------------------------------------------------- A small update to BCP 78 was recently approved by the IESG as RFC 4748, to update the boilerplate (i.e., standard legal text) in RFCs and Internet-Drafts to recognize the IETF Trust as a rights holder, instead of ISOC. The actual boilerplate changes are given below this message. Starting as soon as reasonably possible, all authors of Internet-Drafts are requested to use the new boilerplate. The RFC Editor will in any case be inserting it in all RFCs issued from 2006-11-01. (The rights held by ISOC in older RFCs will be administratively transferred to the IETF Trust.) The public ID Nits checker already accepts I-Ds with old or new boilerplate. The Secretariat has started accepting I-Ds with old or new boilerplate. XML2RFC version 1.32 will generate the new boilerplate. Users of I-D templates are requested to update them appropriately. http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ietf/1id-guidelines.html are being updated. Starting December, the public ID Nits checker will issue warnings for old boilerplate. Starting February 2007, the Secretariat will refuse the old boilerplate in Internet-Drafts. We are sorry for the inconvenience, but this change cannot be avoided. IETF Chair IETF Secretariat TOOLS Team -------- Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) NOTE: by convention, the first line of the copyright statement is usually placed near the beginning of each document. This must also be updated. OLD "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. NEW "Copyright (C) The IETF Trust (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer (required in all IETF Documents) (Normally placed at the end of the IETF Document after the copyright notice.) OLD "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." NEW "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Exceptions In MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: OLD "Copyright (C) The Internet Society . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." NEW "Copyright (C) The IETF Trust . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." When the MIB or PIB module is the initial version of a module that is to be maintained by the IANA, the following abbreviated notice shall be included: OLD "Copyright (C) The Internet Society . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." NEW "Copyright (C) The IETF Trust . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Feb 10 15:52:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFzDE-0002Cs-R2; Sat, 10 Feb 2007 15:52:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFzDD-0002Cj-GJ for dime@ietf.org; Sat, 10 Feb 2007 15:52:47 -0500 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 1HFzDC-0003Hg-5r for dime@ietf.org; Sat, 10 Feb 2007 15:52:47 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l1AKpcoG060201; Sat, 10 Feb 2007 15:51:39 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45CE305B.5080003@tari.toshiba.com> Date: Sat, 10 Feb 2007 15:51:39 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Sudhir.Mittal@relianceada.com Subject: Re: [Dime] Liaison Request from ITU-T References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Sudhir, > > But in case of push mode, the session establishment is required from > the PD-PE (which is already acting as diameter server). This > particular scenario is not covered in 3GPP Gx architecture and is > introduced in ITU-T only. Hence there is this requirements. In this > case the PD-PE is not intended to be treated as diamter client because > that will make the PD-PE functionality very complex and subjective (to > the Push/Pull mode). Since Push/Pull modes could be decided > dynamically, it would be very difficult for the PD-PE to act as both > server and client depending on the scenario. I guess there some clarification that is needed. My understanding is that you don't necessarily need to restrict your PD-PE server to use only diameter server sessions. Note that I'm separating the notion of diameter 'server sessions' from the PD-PE server functions. The idea that these two things are always fused together is what maybe causing the confusion. If you separate them there is no reason why your PD-PE server functions cannot also initiate a diameter 'client session'. This is the idea that Tolga is mentioning, if the PD-PE server needs to initiate a request then it can use the appropriate statemachine, i.e. client state machine. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 12 08:44:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGbTd-0005oq-Mh; Mon, 12 Feb 2007 08:44:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGAko-0007Dn-I0 for dime@ietf.org; Sun, 11 Feb 2007 04:12:14 -0500 Received: from [202.138.127.180] (helo=RADAGMTA020.ril.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGAkl-0002nd-QQ for dime@ietf.org; Sun, 11 Feb 2007 04:12:14 -0500 Received: from infwhub010.ril.com (INFWHUB010 [10.8.51.50]) by RADAGMTA020.ril.com (8.13.6+Sun/8.12.10) with ESMTP id l1AE0HBq002994; Sat, 10 Feb 2007 19:30:37 +0530 (IST) In-Reply-To: <45CA64B1.2020405@tari.toshiba.com> To: Victor Fajardo Subject: Re: [Dime] Liaison Request from ITU-T MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Sudhir.Mittal@relianceada.com Date: Sat, 10 Feb 2007 19:30:18 +0530 X-MIMETrack: Serialize by Router on INFWHUB010/SVR/RIL(Release 6.5.3|September 14, 2004) at 02/10/2007 07:32:25 PM, Serialize complete at 02/10/2007 07:32:25 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-Mailman-Approved-At: Mon, 12 Feb 2007 08:44:16 -0500 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="===============1119413984==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1119413984== Content-Type: multipart/alternative; boundary="=_alternative 004D3E7D6525727E_=" This is a multipart message in MIME format. --=_alternative 004D3E7D6525727E_= Content-Type: text/plain; charset="US-ASCII" In the Rw architecture (for the Diameter Option), we are using PD-PE as a diameter server already for the Pull Mode case. This is in line with the 3GPP Gx architecture (release 7). But in this case the session is initiated by the PE-PE and there is no ambiguity as far as the diamter RFC is concerned. But in case of push mode, the session establishment is required from the PD-PE (which is already acting as diameter server). This particular scenario is not covered in 3GPP Gx architecture and is introduced in ITU-T only. Hence there is this requirements. In this case the PD-PE is not intended to be treated as diamter client because that will make the PD-PE functionality very complex and subjective (to the Push/Pull mode). Since Push/Pull modes could be decided dynamically, it would be very difficult for the PD-PE to act as both server and client depending on the scenario. Regards, Sudhir Mittal Victor Fajardo 02/08/2007 05:15 AM To: Hannes Tschofenig cc: dime@ietf.org, sudhir.mittal@relianceada.com Subject: Re: [Dime] Liaison Request from ITU-T Importance: Normal Sender's OU: Reliance Comments inline: > The Rw interface exists between Policy Decision Physical Entity > (PD-PE) and the Policy Enforcement Physical Entity (PE-PE) where PD-PE > acts as the diameter server and the PE-PE acts as the diameter > client. For the pull mode of operation, the PE-PE establishes a > diameter session and the corresponding state machine is covered in > section 8.1 of the RFC 3588. But for the push mode there is a > requirement that the PD-PE, acting as a diameter server, initiates the > session for which no state machine has been provided in the RFC. I'm not familiar with the Rw architecture but would'nt it be possible for the PD-PE to initiate a 'client session' towards the PE-PE ... regards, victor --=_alternative 004D3E7D6525727E_= Content-Type: text/html; charset="US-ASCII"
In the Rw architecture (for the Diameter Option), we are using PD-PE as a diameter server already for the Pull Mode case.  This is in line with the 3GPP Gx architecture (release 7).  But in this case the session is initiated by the PE-PE and there is no ambiguity as far as the diamter RFC is concerned.  

But in case of push mode, the session establishment is required from the PD-PE (which is already acting as diameter server).  This particular scenario is not covered in 3GPP Gx architecture and is introduced in ITU-T only.  Hence there is this requirements.  In this case the PD-PE is not intended to be treated as diamter client because that will make the PD-PE functionality very complex and subjective (to the Push/Pull mode).  Since Push/Pull modes could be decided dynamically, it would be very difficult for the PD-PE to act as both server and client depending on the scenario.  

Regards,
Sudhir Mittal




Victor Fajardo <vfajardo@tari.toshiba.com>

02/08/2007 05:15 AM

       
        To:        Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
        cc:        dime@ietf.org, sudhir.mittal@relianceada.com
        Subject:        Re: [Dime] Liaison Request from ITU-T
 Importance: Normal  Sender's OU: Reliance



Comments inline:
> The Rw interface exists between Policy Decision Physical Entity
> (PD-PE) and the Policy Enforcement Physical Entity (PE-PE) where PD-PE
> acts as the diameter server and the PE-PE acts as the diameter
> client.  For the pull mode of operation, the PE-PE establishes a
> diameter session and the corresponding state machine is covered in
> section 8.1 of the RFC 3588.  But for the push mode there is a
> requirement that the PD-PE, acting as a diameter server, initiates the
> session for which no state machine has been provided in the RFC.  

I'm not familiar with the Rw architecture but would'nt it be possible
for the PD-PE to initiate a 'client session' towards the PE-PE ...

regards,
victor
--=_alternative 004D3E7D6525727E_=-- --===============1119413984== 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 --===============1119413984==-- From dime-bounces@ietf.org Mon Feb 12 10:29:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGd7B-0006oz-5B; Mon, 12 Feb 2007 10:29:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGd7A-0006o0-DY for dime@ietf.org; Mon, 12 Feb 2007 10:29:12 -0500 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 1HGd72-0007FI-OJ for dime@ietf.org; Mon, 12 Feb 2007 10:29:12 -0500 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 l1CFSach066802; Mon, 12 Feb 2007 10:28:36 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45D087A4.1070202@tari.toshiba.com> Date: Mon, 12 Feb 2007 10:28:36 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Sudhir.Mittal@relianceada.com Subject: Re: [Dime] Liaison Request from ITU-T References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Sudhir, > > This leads to a very complex product which supports the diamter client > as well as diameter server state machines for different dynamically > determined scenarios. This kind of complex specification is not > acceptable to most of the members. Hence there was this need of > diameter server initiated session. If that happens then the PD-PE > needs to maintain the state machine only for the diamter server. I'm not sure if its really that complex or maybe I'm just missing something. In push mode you use a client sessions and in the pull mode you use a server sessions. In either case, you still maintaining only one type of sessions and your not really incurring any additional processing cost nor adding complex decision making on when to use which mode. My main concern here is the attempt to change a fundamental server session behavior in 3588 to accommodate a behavior that seems to be easily solved. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 12 12:01:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeYj-0006KM-LU; Mon, 12 Feb 2007 12:01:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeYi-0006KG-67 for dime@ietf.org; Mon, 12 Feb 2007 12:01:44 -0500 Received: from [202.138.127.180] (helo=RADAGMTA020.ril.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGeYZ-0002GE-Sw for dime@ietf.org; Mon, 12 Feb 2007 12:01:44 -0500 Received: from infwhub010.ril.com (INFWHUB010 [10.8.51.50]) by RADAGMTA020.ril.com (8.13.6+Sun/8.12.10) with ESMTP id l1CAk8H0023483; Mon, 12 Feb 2007 16:16:31 +0530 (IST) In-Reply-To: <45CE305B.5080003@tari.toshiba.com> To: Victor Fajardo Subject: Re: [Dime] Liaison Request from ITU-T MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Sudhir.Mittal@relianceada.com Date: Mon, 12 Feb 2007 16:16:28 +0530 X-MIMETrack: Serialize by Router on INFWHUB010/SVR/RIL(Release 6.5.3|September 14, 2004) at 02/12/2007 04:17:42 PM, Serialize complete at 02/12/2007 04:17:42 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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="===============1551799111==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1551799111== Content-Type: multipart/alternative; boundary="=_alternative 003B7F7965257280_=" This is a multipart message in MIME format. --=_alternative 003B7F7965257280_= Content-Type: text/plain; charset="US-ASCII" Hi Victor, The issue is not really with the PD-PE acting as a server or client. In fact we just need the information exchange between PD-PE and PE-PE using diameter protocol. The issue is that we need to support both Pull mode and Push mode of the session initiation and the subsequent message flows need to be inline with the diameter RFC. In our stage 3 work, for pull mode, PE-PE sends AAR towards PD-PE for session inititation. Subsequently, the PD-PE may inititate RAR towards PE-PE. Thus the state machine followed at the PD-PE is that of Diameter Server. For push mode, if we initiate a session from PD-PE (as suggested by you), then the PD-PE needs to inititate the AAR (or any other new message for server initiation) towards PE-PE. Thus the PD-PE acts as a diameter client. Due to this reason the PD-PE can not send the messages like RAR which are server initiated messages. As a result we would need a Diamter Client State machine at PD-PE also. This leads to a very complex product which supports the diamter client as well as diameter server state machines for different dynamically determined scenarios. This kind of complex specification is not acceptable to most of the members. Hence there was this need of diameter server initiated session. If that happens then the PD-PE needs to maintain the state machine only for the diamter server. Regards, Sudhir Mittal Victor Fajardo 02/11/2007 02:21 AM To: Sudhir.Mittal@relianceada.com cc: dime@ietf.org, Hannes Tschofenig , Tina TSOU Subject: Re: [Dime] Liaison Request from ITU-T Importance: Normal Sender's OU: Reliance Hi Sudhir, > > But in case of push mode, the session establishment is required from > the PD-PE (which is already acting as diameter server). This > particular scenario is not covered in 3GPP Gx architecture and is > introduced in ITU-T only. Hence there is this requirements. In this > case the PD-PE is not intended to be treated as diamter client because > that will make the PD-PE functionality very complex and subjective (to > the Push/Pull mode). Since Push/Pull modes could be decided > dynamically, it would be very difficult for the PD-PE to act as both > server and client depending on the scenario. I guess there some clarification that is needed. My understanding is that you don't necessarily need to restrict your PD-PE server to use only diameter server sessions. Note that I'm separating the notion of diameter 'server sessions' from the PD-PE server functions. The idea that these two things are always fused together is what maybe causing the confusion. If you separate them there is no reason why your PD-PE server functions cannot also initiate a diameter 'client session'. This is the idea that Tolga is mentioning, if the PD-PE server needs to initiate a request then it can use the appropriate statemachine, i.e. client state machine. best regards, victor --=_alternative 003B7F7965257280_= Content-Type: text/html; charset="US-ASCII"
Hi Victor,

The issue is not really with the PD-PE acting as a server or client. In fact we just need the information exchange between PD-PE and PE-PE using diameter protocol.  The issue is that we need to support both Pull mode and Push mode of the session initiation and the subsequent message flows need to be inline with the diameter RFC.  

In our stage 3 work, for pull mode, PE-PE sends AAR towards PD-PE for session inititation.  Subsequently, the PD-PE may inititate RAR towards PE-PE.  Thus the state machine followed at the PD-PE is that of Diameter Server.

For push mode, if we initiate a session from PD-PE (as suggested by you), then the PD-PE needs to inititate the AAR (or any other new message for server initiation) towards PE-PE.  Thus the PD-PE acts as a diameter client.  Due to this reason the PD-PE can not send the messages like RAR which are server initiated messages.  As a result we would need a Diamter Client State machine at PD-PE also.

This leads to a very complex product which supports the diamter client as well as diameter server state machines for different dynamically determined scenarios.  This kind of complex specification is not acceptable to most of the members.  Hence there was this need of diameter server initiated session.  If that happens then the PD-PE needs to maintain the state machine only for the diamter server.

Regards,
Sudhir Mittal



Victor Fajardo <vfajardo@tari.toshiba.com>

02/11/2007 02:21 AM

       
        To:        Sudhir.Mittal@relianceada.com
        cc:        dime@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Tina TSOU <tena@huawei.com>
        Subject:        Re: [Dime] Liaison Request from ITU-T
 Importance: Normal  Sender's OU: Reliance



Hi Sudhir,
>
> But in case of push mode, the session establishment is required from
> the PD-PE (which is already acting as diameter server).  This
> particular scenario is not covered in 3GPP Gx architecture and is
> introduced in ITU-T only.  Hence there is this requirements.  In this
> case the PD-PE is not intended to be treated as diamter client because
> that will make the PD-PE functionality very complex and subjective (to
> the Push/Pull mode).  Since Push/Pull modes could be decided
> dynamically, it would be very difficult for the PD-PE to act as both
> server and client depending on the scenario.  

I guess there some clarification that is needed. My understanding is
that you don't necessarily need to restrict your PD-PE server to use
only diameter server sessions. Note that I'm separating the notion of
diameter 'server sessions' from the PD-PE server functions. The idea
that these two things are always fused together is what maybe causing
the confusion. If you separate them there is no reason why your PD-PE
server functions cannot also initiate a diameter 'client session'. This
is the idea that Tolga is mentioning, if the PD-PE server needs to
initiate a request then it can use the appropriate statemachine, i.e.
client state machine.

best regards,
victor
--=_alternative 003B7F7965257280_=-- --===============1551799111== 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 --===============1551799111==-- From dime-bounces@ietf.org Mon Feb 12 18:13:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkLs-0003Jk-Ar; Mon, 12 Feb 2007 18:12:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkLq-0003HK-Um for dime@ietf.org; Mon, 12 Feb 2007 18:12:51 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HGkLl-0004El-Bz for dime@ietf.org; Mon, 12 Feb 2007 18:12:46 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 683F33D0A6; Mon, 12 Feb 2007 18:12:44 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l1CNChS4012773; Mon, 12 Feb 2007 18:12:44 -0500 (EST) From: "Tolga Asveren" To: , "Victor Fajardo" Subject: RE: [Dime] Liaison Request from ITU-T Date: Mon, 12 Feb 2007 18:08:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Sudhir, I don't see the big difference between two state machines and a single state machine with two parts each of them equal to one state machine of the first model. Maybe I misunderstand the whole issue but what Victor suggested seems very logical to me. AFAICS, with two state machines one would have (I just will give a simplified example from diameter client point of view): If incoming AAA or RAR run client authorization state machine If incoming AAR run server authorization state machine client authorization state machine { do whatever RFC3588 says in client authorization state machine } server authorization state machine { do whatever RFC3588 says in server authorization state machine } With a single state machine one would have: for every incoming message call the state machine state machine { if the message is AAA or RAR do whatever RFC3588 says in client section of authorization state machine if the message is AAR do whatever RFC3588 says in server section of authorization state machine } Thanks, Tolga -----Original Message----- From: Sudhir.Mittal@relianceada.com [mailto:Sudhir.Mittal@relianceada.com] Sent: Monday, February 12, 2007 5:46 AM To: Victor Fajardo Cc: dime@ietf.org Subject: Re: [Dime] Liaison Request from ITU-T Hi Victor, The issue is not really with the PD-PE acting as a server or client. In fact we just need the information exchange between PD-PE and PE-PE using diameter protocol. The issue is that we need to support both Pull mode and Push mode of the session initiation and the subsequent message flows need to be inline with the diameter RFC. In our stage 3 work, for pull mode, PE-PE sends AAR towards PD-PE for session inititation. Subsequently, the PD-PE may inititate RAR towards PE-PE. Thus the state machine followed at the PD-PE is that of Diameter Server. For push mode, if we initiate a session from PD-PE (as suggested by you), then the PD-PE needs to inititate the AAR (or any other new message for server initiation) towards PE-PE. Thus the PD-PE acts as a diameter client. Due to this reason the PD-PE can not send the messages like RAR which are server initiated messages. As a result we would need a Diamter Client State machine at PD-PE also. This leads to a very complex product which supports the diamter client as well as diameter server state machines for different dynamically determined scenarios. This kind of complex specification is not acceptable to most of the members. Hence there was this need of diameter server initiated session. If that happens then the PD-PE needs to maintain the state machine only for the diamter server. Regards, Sudhir Mittal Victor Fajardo 02/11/2007 02:21 AM To: Sudhir.Mittal@relianceada.com cc: dime@ietf.org, Hannes Tschofenig , Tina TSOU Subject: Re: [Dime] Liaison Request from ITU-T Importance: Normal Sender's OU: Reliance Hi Sudhir, > > But in case of push mode, the session establishment is required from > the PD-PE (which is already acting as diameter server). This > particular scenario is not covered in 3GPP Gx architecture and is > introduced in ITU-T only. Hence there is this requirements. In this > case the PD-PE is not intended to be treated as diamter client because > that will make the PD-PE functionality very complex and subjective (to > the Push/Pull mode). Since Push/Pull modes could be decided > dynamically, it would be very difficult for the PD-PE to act as both > server and client depending on the scenario. I guess there some clarification that is needed. My understanding is that you don't necessarily need to restrict your PD-PE server to use only diameter server sessions. Note that I'm separating the notion of diameter 'server sessions' from the PD-PE server functions. The idea that these two things are always fused together is what maybe causing the confusion. If you separate them there is no reason why your PD-PE server functions cannot also initiate a diameter 'client session'. This is the idea that Tolga is mentioning, if the PD-PE server needs to initiate a request then it can use the appropriate statemachine, i.e. client state machine. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 12 18:44:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkqx-0001t5-Jn; Mon, 12 Feb 2007 18:44:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkqu-0001rB-Hb for dime@ietf.org; Mon, 12 Feb 2007 18:44:57 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGkqt-00052Z-1C for dime@ietf.org; Mon, 12 Feb 2007 18:44:56 -0500 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 l1CNiqWV016569; Mon, 12 Feb 2007 17:44:52 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 17:44:52 -0600 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] Liaison Request from ITU-T Date: Mon, 12 Feb 2007 17:44:51 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02ABD5@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Liaison Request from ITU-T Thread-Index: AcdO+3cF3uOn0x4MQQGk/c+oUVAOOQAAJg+A References: From: "Sun, Dong \(Dong\)" To: "Tolga Asveren" , , "Victor Fajardo" X-OriginalArrivalTime: 12 Feb 2007 23:44:52.0253 (UTC) FILETIME=[CA640CD0:01C74EFF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I don't think you need two independent parts with a single state machine if the Diameter server is allowed to initiate a new session in order to support Push mode. In fact, all existing commands as defined in QoS application (they are used to support pull mode at the moment) can be reused for Push mode, the only addition is to define a pair of new commands to initiate new session. In other words, the current state machine in server side can be reused to support Push model with some enhancement (add a pair of new commands and allow the server to initiate new session in the state machine).=20 I am not sure if the complexity of maintaining two state machines within the same physical instance of PD-FE for Diameter client and server respectively equals to a single state mechanism of Diameter server.=20 In addition, since Diameter client may already exist in the network element for some applications e.g. AAA. it makes sense to reuse existing client for QoS enforcement in Push model from cost-effective, complexity and performance perspective.=20 Regards, Dong=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: Monday, February 12, 2007 6:08 PM To: Sudhir.Mittal@relianceada.com; Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Liaison Request from ITU-T Hi Sudhir, I don't see the big difference between two state machines and a single state machine with two parts each of them equal to one state machine of the first model. Maybe I misunderstand the whole issue but what Victor suggested seems very logical to me. AFAICS, with two state machines one would have (I just will give a simplified example from diameter client point of view): If incoming AAA or RAR run client authorization state machine If incoming AAR run server authorization state machine client authorization state machine { do whatever RFC3588 says in client authorization state machine } server authorization state machine { do whatever RFC3588 says in server authorization state machine } With a single state machine one would have: for every incoming message call the state machine state machine { if the message is AAA or RAR do whatever RFC3588 says in client section of authorization state machine if the message is AAR do whatever RFC3588 says in server section of authorization state machine } Thanks, Tolga -----Original Message----- From: Sudhir.Mittal@relianceada.com [mailto:Sudhir.Mittal@relianceada.com] Sent: Monday, February 12, 2007 5:46 AM To: Victor Fajardo Cc: dime@ietf.org Subject: Re: [Dime] Liaison Request from ITU-T Hi Victor, The issue is not really with the PD-PE acting as a server or client. In fact we just need the information exchange between PD-PE and PE-PE using diameter protocol. The issue is that we need to support both Pull mode and Push mode of the session initiation and the subsequent message flows need to be inline with the diameter RFC. In our stage 3 work, for pull mode, PE-PE sends AAR towards PD-PE for session inititation. Subsequently, the PD-PE may inititate RAR towards PE-PE. Thus the state machine followed at the PD-PE is that of Diameter Server. For push mode, if we initiate a session from PD-PE (as suggested by you), then the PD-PE needs to inititate the AAR (or any other new message for server initiation) towards PE-PE. Thus the PD-PE acts as a diameter client. Due to this reason the PD-PE can not send the messages like RAR which are server initiated messages. As a result we would need a Diamter Client State machine at PD-PE also. This leads to a very complex product which supports the diamter client as well as diameter server state machines for different dynamically determined scenarios. This kind of complex specification is not acceptable to most of the members. Hence there was this need of diameter server initiated session. If that happens then the PD-PE needs to maintain the state machine only for the diamter server. Regards, Sudhir Mittal Victor Fajardo 02/11/2007 02:21 AM To: Sudhir.Mittal@relianceada.com cc: dime@ietf.org, Hannes Tschofenig , Tina TSOU Subject: Re: [Dime] Liaison Request from ITU-T Importance: Normal Sender's OU: Reliance Hi Sudhir, > > But in case of push mode, the session establishment is required from=20 > the PD-PE (which is already acting as diameter server). This=20 > particular scenario is not covered in 3GPP Gx architecture and is=20 > introduced in ITU-T only. Hence there is this requirements. In this=20 > case the PD-PE is not intended to be treated as diamter client because > that will make the PD-PE functionality very complex and subjective (to > the Push/Pull mode). Since Push/Pull modes could be decided=20 > dynamically, it would be very difficult for the PD-PE to act as both=20 > server and client depending on the scenario. I guess there some clarification that is needed. My understanding is that you don't necessarily need to restrict your PD-PE server to use only diameter server sessions. Note that I'm separating the notion of diameter 'server sessions' from the PD-PE server functions. The idea that these two things are always fused together is what maybe causing the confusion. If you separate them there is no reason why your PD-PE server functions cannot also initiate a diameter 'client session'. This is the idea that Tolga is mentioning, if the PD-PE server needs to initiate a request then it can use the appropriate statemachine, i.e. client state machine. 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 From dime-bounces@ietf.org Mon Feb 12 18:50:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkwO-0005KI-Q7; Mon, 12 Feb 2007 18:50:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkwN-0005KC-Ln for dime@ietf.org; Mon, 12 Feb 2007 18:50:35 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGkwM-0005x5-4c for dime@ietf.org; Mon, 12 Feb 2007 18:50:35 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l1CNoXks006247; Mon, 12 Feb 2007 17:50:33 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 17:50:33 -0600 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] Liaison Request from ITU-T Date: Mon, 12 Feb 2007 17:50:32 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02ABD6@ILEXC2U01.ndc.lucent.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D02ABD5@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Liaison Request from ITU-T Thread-Index: AcdO+3cF3uOn0x4MQQGk/c+oUVAOOQAAJg+AAAEM2hA= References: <09C9068466B79E4C938DC7737562404D02ABD5@ILEXC2U01.ndc.lucent.com> From: "Sun, Dong \(Dong\)" To: "Tolga Asveren" , , "Victor Fajardo" X-OriginalArrivalTime: 12 Feb 2007 23:50:33.0137 (UTC) FILETIME=[9592D210:01C74F00] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Just for clarification. In the last sentence, the network element refers to policy enforcement point (PE-FE), rather than the policy decision point (PD-FE).=20 Thanks, -----Original Message----- From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com]=20 Sent: Monday, February 12, 2007 6:45 PM To: Tolga Asveren; Sudhir.Mittal@relianceada.com; Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Liaison Request from ITU-T I don't think you need two independent parts with a single state machine if the Diameter server is allowed to initiate a new session in order to support Push mode. In fact, all existing commands as defined in QoS application (they are used to support pull mode at the moment) can be reused for Push mode, the only addition is to define a pair of new commands to initiate new session. In other words, the current state machine in server side can be reused to support Push model with some enhancement (add a pair of new commands and allow the server to initiate new session in the state machine).=20 I am not sure if the complexity of maintaining two state machines within the same physical instance of PD-FE for Diameter client and server respectively equals to a single state mechanism of Diameter server.=20 In addition, since Diameter client may already exist in the network element for some applications e.g. AAA. it makes sense to reuse existing client for QoS enforcement in Push model from cost-effective, complexity and performance perspective.=20 Regards, Dong=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com] Sent: Monday, February 12, 2007 6:08 PM To: Sudhir.Mittal@relianceada.com; Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Liaison Request from ITU-T Hi Sudhir, I don't see the big difference between two state machines and a single state machine with two parts each of them equal to one state machine of the first model. Maybe I misunderstand the whole issue but what Victor suggested seems very logical to me. AFAICS, with two state machines one would have (I just will give a simplified example from diameter client point of view): If incoming AAA or RAR run client authorization state machine If incoming AAR run server authorization state machine client authorization state machine { do whatever RFC3588 says in client authorization state machine } server authorization state machine { do whatever RFC3588 says in server authorization state machine } With a single state machine one would have: for every incoming message call the state machine state machine { if the message is AAA or RAR do whatever RFC3588 says in client section of authorization state machine if the message is AAR do whatever RFC3588 says in server section of authorization state machine } Thanks, Tolga -----Original Message----- From: Sudhir.Mittal@relianceada.com [mailto:Sudhir.Mittal@relianceada.com] Sent: Monday, February 12, 2007 5:46 AM To: Victor Fajardo Cc: dime@ietf.org Subject: Re: [Dime] Liaison Request from ITU-T Hi Victor, The issue is not really with the PD-PE acting as a server or client. In fact we just need the information exchange between PD-PE and PE-PE using diameter protocol. The issue is that we need to support both Pull mode and Push mode of the session initiation and the subsequent message flows need to be inline with the diameter RFC. In our stage 3 work, for pull mode, PE-PE sends AAR towards PD-PE for session inititation. Subsequently, the PD-PE may inititate RAR towards PE-PE. Thus the state machine followed at the PD-PE is that of Diameter Server. For push mode, if we initiate a session from PD-PE (as suggested by you), then the PD-PE needs to inititate the AAR (or any other new message for server initiation) towards PE-PE. Thus the PD-PE acts as a diameter client. Due to this reason the PD-PE can not send the messages like RAR which are server initiated messages. As a result we would need a Diamter Client State machine at PD-PE also. This leads to a very complex product which supports the diamter client as well as diameter server state machines for different dynamically determined scenarios. This kind of complex specification is not acceptable to most of the members. Hence there was this need of diameter server initiated session. If that happens then the PD-PE needs to maintain the state machine only for the diamter server. Regards, Sudhir Mittal Victor Fajardo 02/11/2007 02:21 AM To: Sudhir.Mittal@relianceada.com cc: dime@ietf.org, Hannes Tschofenig , Tina TSOU Subject: Re: [Dime] Liaison Request from ITU-T Importance: Normal Sender's OU: Reliance Hi Sudhir, > > But in case of push mode, the session establishment is required from=20 > the PD-PE (which is already acting as diameter server). This=20 > particular scenario is not covered in 3GPP Gx architecture and is=20 > introduced in ITU-T only. Hence there is this requirements. In this=20 > case the PD-PE is not intended to be treated as diamter client because > that will make the PD-PE functionality very complex and subjective (to > the Push/Pull mode). Since Push/Pull modes could be decided=20 > dynamically, it would be very difficult for the PD-PE to act as both=20 > server and client depending on the scenario. I guess there some clarification that is needed. My understanding is that you don't necessarily need to restrict your PD-PE server to use only diameter server sessions. Note that I'm separating the notion of diameter 'server sessions' from the PD-PE server functions. The idea that these two things are always fused together is what maybe causing the confusion. If you separate them there is no reason why your PD-PE server functions cannot also initiate a diameter 'client session'. This is the idea that Tolga is mentioning, if the PD-PE server needs to initiate a request then it can use the appropriate statemachine, i.e. client state machine. 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 Mon Feb 12 22:08:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGo1w-0003nV-8A; Mon, 12 Feb 2007 22:08:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGo1v-0003nK-KD for dime@ietf.org; Mon, 12 Feb 2007 22:08:31 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HGo1u-0006hV-9o for dime@ietf.org; Mon, 12 Feb 2007 22:08:31 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l1D32Z6H069350; Mon, 12 Feb 2007 22:02:36 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45D12A4C.9040704@tari.toshiba.com> Date: Mon, 12 Feb 2007 22:02:36 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "Sun, Dong \(Dong\)" Subject: Re: [Dime] Liaison Request from ITU-T References: <09C9068466B79E4C938DC7737562404D02ABD5@ILEXC2U01.ndc.lucent.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D02ABD5@ILEXC2U01.ndc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Sudhir.Mittal@relianceada.com, 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, > I don't think you need two independent parts with a single state machine > if the Diameter server is allowed to initiate a new session in order to > support Push mode. In fact, all existing commands as defined in QoS > application (they are used to support pull mode at the moment) can be > reused for Push mode, the only addition is to define a pair of new > commands to initiate new session. In other words, the current state > machine in server side can be reused to support Push model with some > enhancement (add a pair of new commands and allow the server to initiate > new session in the state machine). > > I am not sure if the complexity of maintaining two state machines within > the same physical instance of PD-FE for Diameter client and server > respectively equals to a single state mechanism of Diameter server. > From a modular design point it maybe better to maintain separate state machines as opposed to a monolithic do it all server state machine ... > In addition, since Diameter client may already exist in the network > element for some applications e.g. AAA. it makes sense to reuse existing > client for QoS enforcement in Push model from cost-effective, complexity > and performance perspective. > Does this mean the conclusion is to fall in line with the way 3588 current defines server session fsm's ? regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 12 23:36:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGpPW-0005OY-Os; Mon, 12 Feb 2007 23:36:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGpPV-0005OS-JI for dime@ietf.org; Mon, 12 Feb 2007 23:36:57 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGpPU-0008MS-3a for dime@ietf.org; Mon, 12 Feb 2007 23:36:57 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDD00AZPWS9D5@szxga01-in.huawei.com> for dime@ietf.org; Tue, 13 Feb 2007 12:36:09 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDD00EYOWS8M8@szxga01-in.huawei.com> for dime@ietf.org; Tue, 13 Feb 2007 12:36:09 +0800 (CST) Received: from huawei1515 ([10.18.4.137]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDD00K5EWRHKY@szxml03-in.huawei.com> for dime@ietf.org; Tue, 13 Feb 2007 12:36:08 +0800 (CST) Date: Tue, 13 Feb 2007 10:05:41 +0530 From: Rajith R Subject: RE: [Dime] Liaison Request from ITU-T In-reply-to: <45D12A4C.9040704@tari.toshiba.com> To: 'Victor Fajardo' , "'Sun, Dong (Dong)'" Message-id: <003d01c74f28$78fc5f40$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: AcdPHJDHuHBsJ0a7RGqnCb9EENbq7gAC1Txg X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Sudhir.Mittal@relianceada.com, 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 Hi I also agree with Sun's suggestion to extend the server state machine with 2 more messages (one such example is the QIR in the latest QoS draft). If we decide to use Tolga/Victor's suggestion of having a server state machine at the PE-PE, I think it is not appropriate of a PE-PE to send RAR or ASR. However, in this case, wemay have to update the client state machine also (to handle the new request). Rajith >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Tuesday, February 13, 2007 8:33 AM >To: Sun, Dong (Dong) >Cc: Sudhir.Mittal@relianceada.com; dime@ietf.org >Subject: Re: [Dime] Liaison Request from ITU-T > >Hi, >> I don't think you need two independent parts with a single state >> machine if the Diameter server is allowed to initiate a new >session in >> order to support Push mode. In fact, all existing commands >as defined >> in QoS application (they are used to support pull mode at >the moment) >> can be reused for Push mode, the only addition is to define >a pair of >> new commands to initiate new session. In other words, the current >> state machine in server side can be reused to support Push >model with >> some enhancement (add a pair of new commands and allow the server to >> initiate new session in the state machine). >> >> I am not sure if the complexity of maintaining two state machines >> within the same physical instance of PD-FE for Diameter client and >> server respectively equals to a single state mechanism of >Diameter server. >> > > From a modular design point it maybe better to maintain >separate state machines as opposed to a monolithic do it all >server state machine ... > >> In addition, since Diameter client may already exist in the network >> element for some applications e.g. AAA. it makes sense to reuse >> existing client for QoS enforcement in Push model from >cost-effective, >> complexity and performance perspective. >> > >Does this mean the conclusion is to fall in line with the way >3588 current defines server session fsm's ? > >regards, >victor > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 13 07:05:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGwPH-0001aN-RN; Tue, 13 Feb 2007 07:05:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGwPG-0001aD-Id for dime@ietf.org; Tue, 13 Feb 2007 07:05:10 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGwPF-0006to-8w for dime@ietf.org; Tue, 13 Feb 2007 07:05:10 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1DC55D5029010 for ; Tue, 13 Feb 2007 07:05:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Feb 2007 14:05:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New dime WG co-chair Thread-Index: AcdKEjGB/WAKVDZyQYCfedMyjXhzrg== From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Dime] New dime WG co-chair 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, John Loughery changed some of his day-job assignments and as a result had to give up his position as dime WG co-chair. Thanks, John, for the dedicated work as co-chair until now. We expect you to continue to make contributions to dime in the future.=20 David Kessens and myself decided to nominate David Frascone as new co-chair of dime, replacing John. Congratulations, Dave, and thanks for accepting this position. This is a responsibility and a challenge as this WG has a tough agenda to execute. We wish success to you and the WG. David and Dan =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 13 10:21:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzSy-0002TJ-Ln; Tue, 13 Feb 2007 10:21:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzSx-0002TE-KW for dime@ietf.org; Tue, 13 Feb 2007 10:21:11 -0500 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 1HGzSw-0005yM-B9 for dime@ietf.org; Tue, 13 Feb 2007 10:21:11 -0500 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 l1DFK4fk071548; Tue, 13 Feb 2007 10:20:04 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45D1D724.7030200@tari.toshiba.com> Date: Tue, 13 Feb 2007 10:20:04 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] Liaison Request from ITU-T References: <003d01c74f28$78fc5f40$8904120a@china.huawei.com> In-Reply-To: <003d01c74f28$78fc5f40$8904120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Sudhir.Mittal@relianceada.com, 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 Rajith, > Hi > I also agree with Sun's suggestion to extend the server state > machine with 2 more messages (one such example is the QIR in the latest QoS > draft). > If we decide to use Tolga/Victor's suggestion of having a server > state machine at the PE-PE, I think it is not appropriate of a PE-PE to send > RAR or ASR. > I'm not sure about the functionality you had in mind but you don't have to send a re-auth if you don't need to. As far as ASR is concerned, its a sessions maintenance message so I don't think it affects your PE-PE functionality too much. Also, it really depends on your application policy on whether ASR is sent or you just expect and STR. In such a case your not restricted to using it. > However, in this case, wemay have to update the client state machine > also (to handle the new request). > If we consider Tolga's suggestion, its easy to achieve symmetric conversation between the two entities without changing 3588. One advantage is that the type of sessions you use in your push and pull modes are mirrored opposites and present in both PE-PE and PD-PE so reuse comes easily. Another advantage is your modes are segregated so it makes it easy to add/change/delete functionality to one mode without affecting the other. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 13 10:27:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzYz-0004TR-OU; Tue, 13 Feb 2007 10:27:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGzYz-0004TL-9M for dime@ietf.org; Tue, 13 Feb 2007 10:27:25 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGzYy-0000qT-0T for dime@ietf.org; Tue, 13 Feb 2007 10:27:25 -0500 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 l1DFRJgN005914; Tue, 13 Feb 2007 09:27:19 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 09:27:19 -0600 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] Liaison Request from ITU-T Date: Tue, 13 Feb 2007 09:27:18 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02ABD9@ILEXC2U01.ndc.lucent.com> In-Reply-To: <45D12A4C.9040704@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Liaison Request from ITU-T Thread-Index: AcdPG267aFdU6agtTAKA6jqMgXh7IwAZMklA References: <09C9068466B79E4C938DC7737562404D02ABD5@ILEXC2U01.ndc.lucent.com> <45D12A4C.9040704@tari.toshiba.com> From: "Sun, Dong \(Dong\)" To: "Victor Fajardo" X-OriginalArrivalTime: 13 Feb 2007 15:27:19.0063 (UTC) FILETIME=[72EA8270:01C74F83] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org =20 Hi Victor, For clarification: > In addition, since Diameter client may already exist in the network=20 > element for some applications e.g. AAA. it makes sense to reuse=20 > existing client for QoS enforcement in Push model from cost-effective, > complexity and performance perspective. > =20 Does this mean the conclusion is to fall in line with the way 3588 current defines server session fsm's ? -------- [Dong] what I mean is that the network element (e.g. router, BRAS, GGSN/PDSN etc) should serve as Diameter client for all applications since majority of applications such as AAA, QoS application for Pull model will use the NE as Diameter client. Therefore, it makes sense to use this Diameter client (in NE) for Push model QoS application as well, rather than adding a new Diameter Server in the NE only for Push model QoS application. =20 The current client and server fsm need to be enhanced (to allow the server to initiate a new session) for this purpose. ------------ regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 13 10:48:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGztm-0007z4-2s; Tue, 13 Feb 2007 10:48:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGztk-0007yo-0E for dime@ietf.org; Tue, 13 Feb 2007 10:48:52 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGzti-0006Uz-NH for dime@ietf.org; Tue, 13 Feb 2007 10:48:51 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 4538DB9471 for ; Tue, 13 Feb 2007 10:48:48 -0500 (EST) Received: from [172.25.33.127] (pc-lehmann-p.ulticom.com [172.25.33.127]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id l1DFmkfx023626; Tue, 13 Feb 2007 10:48:46 -0500 (EST) Message-ID: <45D1DDDD.5000903@ulticom.com> Date: Tue, 13 Feb 2007 10:48:45 -0500 From: David Lehmann User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dime@ietf.org Received-SPF: none X-Spam-Score: 1.5 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Jeff Morriss Subject: [Dime] [Fwd: [Fwd: setting SCTP PPID?]] 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="===============1792507182==" Errors-To: dime-bounces@ietf.org --===============1792507182== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Y'all,

Please consider the email below which I am forwarding for a colleague.  Apparently the posting that he sent to the DIME group did not go through.

-- 

David Lehmann
Ulticom, Inc.
http://www.ulticom.com


-------- Original Message --------
Subject: [Fwd: setting SCTP PPID?]
Date: Mon, 12 Feb 2007 15:45:41 +0800
From: Jeff Morriss <morriss@ulticom.com>
Organization: Ulticom, Inc.
To: David Lehmann <lehmann@ulticom.com> 

Did you ever ask the question?  If not, could you please forward this? 


-------- Original Message --------
Subject: setting SCTP PPID?
Date: Mon, 05 Feb 2007 17:00:54 +0800
From: Jeff Morriss <jeff.morriss@ulticom.com>
To: dime@ietf.org


Hi list,

A while back a colleague of mine sent me a PCAP file containing some
Diameter (over SCTP) packets and asked me why Wireshark (formerly
Ethereal) didn't dissect the packets as Diameter.  Of course the answer
was that association wasn't using Diameter's well known port so
Wireshark couldn't figure out that it was Diameter.

SCTP has a field (the Payload Protocol Identifier) wherein ULPs can be
registered to a specific value so everyone will know what the protocol
is regardless of the ports used.  Having it set makes life much easier
for tools like Wireshark.

Have you all ever considered registering a PPID for Diameter (with IANA,
of course)?

Regards,
-Jeff

ps. please Cc: me on any responses as I'm not on the list

pps. you can see the list of currently assigned PPIDs here:

http://www.iana.org/assignments/sctp-parameters







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

--===============1792507182==--



From dime-bounces@ietf.org Tue Feb 13 16:36:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HH5Jp-0000Po-S9; Tue, 13 Feb 2007 16:36:09 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HH4cC-0000wD-Go; Tue, 13 Feb 2007 15:51:04 -0500
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HH4cB-0003IN-PL; Tue, 13 Feb 2007 15:51:04 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B4E041767A;
	Tue, 13 Feb 2007 20:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HH4bD-0002yt-Fh; Tue, 13 Feb 2007 15:50:03 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Tue, 13 Feb 2007 15:50:03 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: dime@ietf.org
Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-integrated-03.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: NAS <-> HAAA Support
	Author(s)	: J. Korhonen, et al.
	Filename	: draft-ietf-dime-mip6-integrated-03.txt
	Pages		: 27
	Date		: 2007-2-13
	
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.  Ongoing 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) <-> 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-03.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-03.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-03.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-2-13145045.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dime-mip6-integrated-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dime-mip6-integrated-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-2-13145045.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 Tue Feb 13 23:48:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHC3u-00065Q-B2; Tue, 13 Feb 2007 23:48:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHC3t-00065K-J9
	for dime@ietf.org; Tue, 13 Feb 2007 23:48:09 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHC3s-0003RV-1V
	for dime@ietf.org; Tue, 13 Feb 2007 23:48:09 -0500
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 <0JDF00BAURZ5DP@szxga02-in.huawei.com> for
	dime@ietf.org; Wed, 14 Feb 2007 12:47:29 +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 <0JDF00FUORZ4EZ@szxga02-in.huawei.com> for
	dime@ietf.org; Wed, 14 Feb 2007 12:47:29 +0800 (CST)
Received: from huawei1515 ([10.18.4.137])
	by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0JDF00HECRZ0H8@szxml03-in.huawei.com> for
	dime@ietf.org; Wed, 14 Feb 2007 12:47:28 +0800 (CST)
Date: Wed, 14 Feb 2007 10:17:24 +0530
From: Rajith R 
Subject: RE: [Dime] Liaison Request from ITU-T
In-reply-to: <45D1D724.7030200@tari.toshiba.com>
To: 'Victor Fajardo' 
Message-id: <004e01c74ff3$38d88670$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: AcdPgn1OhNUctuG8Suy+CtrXu3F4bwAb6tGg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: Sudhir.Mittal@relianceada.com, 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

Hi Victor
	Whether push/pull mode, the PD-PE always takes policy decisions and
PE-PE is always the enforcement point (as directed by the policy information
received from PD-PE). The State machines should also be inline with this
behaviour. I dont think the client Auth. FSM is suited to an entity who
takes policy decisions and applies at a PE-PE. For eg: PD-PE may have to
send a RAR. The cline FSM does not provide for this, I think.

Regards

Rajith

>-----Original Message-----
>From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] 
>Sent: Tuesday, February 13, 2007 8:50 PM
>To: rajithr@huawei.com
>Cc: 'Sun, Dong (Dong)'; Sudhir.Mittal@relianceada.com; dime@ietf.org
>Subject: Re: [Dime] Liaison Request from ITU-T
>
>Hi Rajith,
>> Hi
>> 	I also agree with Sun's suggestion to extend the server 
>state machine 
>> with 2 more messages (one such example is the QIR in the latest QoS 
>> draft).
>> 	If we decide to use Tolga/Victor's suggestion of having 
>a server 
>> state machine at the PE-PE, I think it is not appropriate of a PE-PE 
>> to send RAR or ASR.
>>   
>
>I'm not sure about the functionality you had in mind but you 
>don't have to send a re-auth if you don't need to. As far as 
>ASR is concerned, its a sessions maintenance message so I 
>don't think it affects your PE-PE functionality too much. 
>Also, it really depends on your application policy on whether 
>ASR is sent or you just expect and STR. In such a case your 
>not restricted to using it.
>
>> 	However, in this case, wemay have to update the client 
>state machine 
>> also (to handle the new request).
>>   
>If we consider Tolga's suggestion, its easy to achieve 
>symmetric conversation between the two entities without 
>changing 3588. One advantage is that the type of sessions you 
>use in your push and pull modes are mirrored opposites and 
>present in both PE-PE and PD-PE so reuse comes easily. Another 
>advantage is your modes are segregated so it makes it easy to 
>add/change/delete functionality to one mode without affecting 
>the other.
>
>regards,
>victor
>



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



From dime-bounces@ietf.org Wed Feb 14 09:58:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHLa3-0007Pg-K3; Wed, 14 Feb 2007 09:57:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLa1-0007Pa-VI
	for dime@ietf.org; Wed, 14 Feb 2007 09:57:57 -0500
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 1HHLa0-0006pC-MJ
	for dime@ietf.org; Wed, 14 Feb 2007 09:57:57 -0500
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
	l1EEv2bR076826; Wed, 14 Feb 2007 09:57:02 -0500 (EST)
	(envelope-from vfajardo@tari.toshiba.com)
Message-ID: <45D3233E.2000400@tari.toshiba.com>
Date: Wed, 14 Feb 2007 09:57:02 -0500
From: Victor Fajardo 
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: rajithr@huawei.com
Subject: Re: [Dime] Liaison Request from ITU-T
References: <004e01c74ff3$38d88670$8904120a@china.huawei.com>
In-Reply-To: <004e01c74ff3$38d88670$8904120a@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.4 (--)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: Sudhir.Mittal@relianceada.com, 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 Rajith,
> Hi Victor
> 	Whether push/pull mode, the PD-PE always takes policy decisions and
> PE-PE is always the enforcement point (as directed by the policy information
> received from PD-PE). The State machines should also be inline with this
> behaviour. I dont think the client Auth. FSM is suited to an entity who
> takes policy decisions and applies at a PE-PE. For eg: PD-PE may have to
> send a RAR. The cline FSM does not provide for this, I think.
>   

One should considered that the diameter client and server fsm is used by 
many other applications the way are are designed. Again, I think it 
would be in-appropriate to change that existing expected behavior just 
to accommodate a PD-PE requirement which seems easy to solve with the 
existing fsm design. My two cents on this issue.

regards,
victor


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



From dime-bounces@ietf.org Thu Feb 15 08:28:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHgf6-0003cl-1r; Thu, 15 Feb 2007 08:28:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHgf5-0003bp-6a
	for dime@ietf.org; Thu, 15 Feb 2007 08:28:35 -0500
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 1HHgez-0005rJ-SN
	for dime@ietf.org; Thu, 15 Feb 2007 08:28:35 -0500
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
	l1FDS12I081691; Thu, 15 Feb 2007 08:28:02 -0500 (EST)
	(envelope-from vfajardo@tari.toshiba.com)
Message-ID: <45D45FE2.40902@tari.toshiba.com>
Date: Thu, 15 Feb 2007 08:28:02 -0500
From: Victor Fajardo 
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Sudhir.Mittal@relianceada.com
Subject: Re: [Dime] Liaison Request from ITU-T
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.4 (--)
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

Comments inline:
>  
> 1. For push mode, PD-PE acts as diameter client PE-PE as diameter 
> server.  PD-PE sends message to the PE-PE for the session inititation.
>
> 2. In this case, since PD-PE is a diamter client, it will not send RAR 
> and ASR messages.  The functionality of RAR and ASR messages needs to 
> be fulfilled by some new messages.

In this case, the PD-PE can use STR in place of ASR. If you have been 
using RAR in the pull mode then you probably already have an existing 
message used for authorization. If you do you can re-use that.

hope this helps,
victor

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



From dime-bounces@ietf.org Thu Feb 15 16:16:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHnxx-0006HA-TY; Thu, 15 Feb 2007 16:16:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHnxx-0006H5-3E
	for dime@ietf.org; Thu, 15 Feb 2007 16:16:33 -0500
Received: from [202.138.127.180] (helo=RADAGMTA020.ril.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHnxs-00039Z-Dn
	for dime@ietf.org; Thu, 15 Feb 2007 16:16:33 -0500
Received: from infwhub010.ril.com (INFWHUB010 [10.8.51.50])
	by RADAGMTA020.ril.com (8.13.6+Sun/8.12.10) with ESMTP id
	l1F6li3A006402; Thu, 15 Feb 2007 12:17:51 +0530 (IST)
In-Reply-To: <45D3233E.2000400@tari.toshiba.com>
To: Victor Fajardo 
Subject: Re: [Dime] Liaison Request from ITU-T
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: 
From: Sudhir.Mittal@relianceada.com
Date: Thu, 15 Feb 2007 12:17:55 +0530
X-MIMETrack: Serialize by Router on INFWHUB010/SVR/RIL(Release 6.5.3|September
	14, 2004) at 02/15/2007 12:18:58 PM,
	Serialize complete at 02/15/2007 12:18:58 PM
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
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="===============1567832247=="
Errors-To: dime-bounces@ietf.org

This is a multipart message in MIME format.
--===============1567832247==
Content-Type: multipart/alternative;
	boundary="=_alternative 0025A86865257283_="

This is a multipart message in MIME format.
--=_alternative 0025A86865257283_=
Content-Type: text/plain; charset="US-ASCII"

Hi Victor,

When you say that the PD-PE requirement is easy to solve within the 
existing FSM design, are you recommending the following?

{
1. For push mode, PD-PE acts as diameter client PE-PE as diameter server. 
PD-PE sends message to the PE-PE for the session inititation.

2. In this case, since PD-PE is a diamter client, it will not send RAR and 
ASR messages.  The functionality of RAR and ASR messages needs to be 
fulfilled by some new messages.

3. For pull mode PE-PE acts as diameter client and PD-PE as diamter 
server.  PE-PE sends message to the PD-PE for the session inititation.

4. In this case PD-PE will be able to send RAR and ASR messages for the 
corresponding functionalities.

5. Thus PD-PE acts either a diameter client or server depending upon the 
scenario.
}

Please tell if you have any other solution in mind.

Regards,
Sudhir Mittal






Victor Fajardo 
02/14/2007 08:27 PM
 
        To:     rajithr@huawei.com
        cc:     "'Sun, Dong (Dong)'" , 
Sudhir.Mittal@relianceada.com, dime@ietf.org
        Subject:        Re: [Dime] Liaison Request from ITU-T
 Importance: Normal  Sender's OU: Reliance 


Hi Rajith,
> Hi Victor
>                Whether push/pull mode, the PD-PE always takes policy 
decisions and
> PE-PE is always the enforcement point (as directed by the policy 
information
> received from PD-PE). The State machines should also be inline with this
> behaviour. I dont think the client Auth. FSM is suited to an entity who
> takes policy decisions and applies at a PE-PE. For eg: PD-PE may have to
> send a RAR. The cline FSM does not provide for this, I think.
> 

One should considered that the diameter client and server fsm is used by 
many other applications the way are are designed. Again, I think it 
would be in-appropriate to change that existing expected behavior just 
to accommodate a PD-PE requirement which seems easy to solve with the 
existing fsm design. My two cents on this issue.

regards,
victor



--=_alternative 0025A86865257283_=
Content-Type: text/html; charset="US-ASCII"



Hi Victor,



When you say that the PD-PE requirement
is easy to solve within the existing FSM design, are you recommending the
following?



{

1. For push mode, PD-PE acts as diameter
client PE-PE as diameter server.  PD-PE sends message to the PE-PE
for the session inititation.



2. In this case, since PD-PE is a diamter
client, it will not send RAR and ASR messages.  The functionality
of RAR and ASR messages needs to be fulfilled by some new messages.



3. For pull mode PE-PE acts as diameter
client and PD-PE as diamter server.  PE-PE sends message to the PD-PE
for the session inititation.



4. In this case PD-PE will be able to
send RAR and ASR messages for the corresponding functionalities.



5. Thus PD-PE acts either a diameter
client or server depending upon the scenario.

}



Please tell if you have any other solution
in mind.



Regards,

Sudhir Mittal















Victor Fajardo <vfajardo@tari.toshiba.com>

02/14/2007 08:27 PM

        

        To:
       rajithr@huawei.com

        cc:
       "'Sun, Dong (Dong)'" <dongsun@alcatel-lucent.com>,
Sudhir.Mittal@relianceada.com, dime@ietf.org

        Subject:
       Re: [Dime] Liaison Request from ITU-T

 Importance: Normal
 Sender's OU: Reliance







Hi Rajith,

> Hi Victor

>                  Whether
push/pull mode, the PD-PE always takes policy decisions and

> PE-PE is always the enforcement point (as directed by the policy information

> received from PD-PE). The State machines should also be inline with
this

> behaviour. I dont think the client Auth. FSM is suited to an entity
who

> takes policy decisions and applies at a PE-PE. For eg: PD-PE may have
to

> send a RAR. The cline FSM does not provide for this, I think.

>   



One should considered that the diameter client and server fsm is used by


many other applications the way are are designed. Again, I think it 

would be in-appropriate to change that existing expected behavior just


to accommodate a PD-PE requirement which seems easy to solve with the 

existing fsm design. My two cents on this issue.



regards,

victor






--=_alternative 0025A86865257283_=--


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

--===============1567832247==--




From dime-bounces@ietf.org Mon Feb 19 01:34:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJ26I-0003xQ-8c; Mon, 19 Feb 2007 01:34:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ26H-0003xH-Bx
	for dime@ietf.org; Mon, 19 Feb 2007 01:34:13 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ26F-0008CX-RC
	for dime@ietf.org; Mon, 19 Feb 2007 01:34:13 -0500
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 <0JDP005KJ67ZS9@szxga02-in.huawei.com> for
	dime@ietf.org; Mon, 19 Feb 2007 14:33:35 +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 <0JDP00LF767YJY@szxga02-in.huawei.com> for
	dime@ietf.org; Mon, 19 Feb 2007 14:33:35 +0800 (CST)
Received: from huawei1515 ([10.18.4.137])
	by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0JDP002YQ67US9@szxml03-in.huawei.com> for
	dime@ietf.org; Mon, 19 Feb 2007 14:33:34 +0800 (CST)
Date: Mon, 19 Feb 2007 12:03:30 +0530
From: Rajith R 
Subject: RE: [Dime] Liaison Request from ITU-T
In-reply-to: <45D45FE2.40902@tari.toshiba.com>
To: 'Victor Fajardo' , Sudhir.Mittal@relianceada.com
Message-id: <008e01c753ef$df4d1b10$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: AcdRBSYlYDbu64HkRgiGmnJkAjE8TAC6ni5A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

If you look at the stateful client & server FSMs in RFC 3588, the behaviour
of ASR and STR are different. ASR provides for client NOT to consent, in
which case the server will resend the ASR. However, I cannot find a similar
provision for STR. 

>-----Original Message-----
>From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] 
>Sent: Thursday, February 15, 2007 6:58 PM
>To: Sudhir.Mittal@relianceada.com
>Cc: dime@ietf.org; 'Sun, Dong (Dong)'; rajithr@huawei.com
>Subject: Re: [Dime] Liaison Request from ITU-T
>
>Comments inline:
>>  
>> 1. For push mode, PD-PE acts as diameter client PE-PE as diameter 
>> server.  PD-PE sends message to the PE-PE for the session 
>inititation.
>>
>> 2. In this case, since PD-PE is a diamter client, it will 
>not send RAR 
>> and ASR messages.  The functionality of RAR and ASR messages 
>needs to 
>> be fulfilled by some new messages.
>
>In this case, the PD-PE can use STR in place of ASR. If you 
>have been using RAR in the pull mode then you probably already 
>have an existing message used for authorization. If you do you 
>can re-use that.
>
>hope this helps,
>victor
>



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



From dime-bounces@ietf.org Mon Feb 19 11:01:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJAx3-0004ES-U5; Mon, 19 Feb 2007 11:01:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJAx3-0004EN-H7
	for dime@ietf.org; Mon, 19 Feb 2007 11:01:17 -0500
Received: from wr-out-0506.google.com ([64.233.184.232])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJAx2-0003XH-AX
	for dime@ietf.org; Mon, 19 Feb 2007 11:01:17 -0500
Received: by wr-out-0506.google.com with SMTP id 55so2364023wri
	for ; Mon, 19 Feb 2007 08:01:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=Os1Ahdd0tNMjlYPgfQEJ87ZF0cCSiUaW1QOIFzolXFAjxlZVovcukYEHONwerY8946cYcg1ockFI+lJKWpecwdy1M+kzgohjyO5scVr14LevNZM7sfrMS1x+e+GO6rrMRTNZmUnSH334HXDHczeguo3HcfAkpz8PaiIU/ch8n/E=
Received: by 10.114.145.1 with SMTP id s1mr2954914wad.1171900875175;
	Mon, 19 Feb 2007 08:01:15 -0800 (PST)
Received: by 10.114.193.10 with HTTP; Mon, 19 Feb 2007 08:01:15 -0800 (PST)
Message-ID: 
Date: Mon, 19 Feb 2007 21:31:15 +0530
From: "naveen sarma" 
To: dime@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.5 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: [Dime] Use of ICMP messages
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="===============0234160923=="
Errors-To: dime-bounces@ietf.org

--===============0234160923==
Content-Type: multipart/alternative; 
	boundary="----=_Part_29860_20780632.1171900875032"

------=_Part_29860_20780632.1171900875032
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

Can any one clarify the following question:

As per section 2.1 " Diameter implementations SHOULD be able to interpret
ICMP protocol port unreachable messages as explicit indications that the
server is not reachable, subject to security policy on trusting such
messages."
As per section 2.6 " Expiration time --- Specifies the time at which
dynamically discovered peer table entries are to be either refreshed, or
expired."

Does the expiration time has got anything todo with the ICMP messages
described in the section 2.1?

-- 
Yours
Naveen.

------=_Part_29860_20780632.1171900875032
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


Hi,


 


Can any one clarify the following question:


 


As per section 2.1 " Diameter implementations SHOULD be able to interpret ICMP protocol port unreachable messages as explicit indications that the server is not reachable, subject to security policy on trusting such messages."



As per section 2.6 " Expiration time --- Specifies the time at which dynamically discovered peer table entries are to be either refreshed, or expired."


 


Does the expiration time has got anything todo with the ICMP messages described in the section 2.1?


 


-- 
Yours
Naveen. 


------=_Part_29860_20780632.1171900875032--


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

--===============0234160923==--




From dime-bounces@ietf.org Wed Feb 21 06:02:44 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJpFA-0005gu-CL; Wed, 21 Feb 2007 06:02:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJpF9-0005gp-SU
	for dime@ietf.org; Wed, 21 Feb 2007 06:02:39 -0500
Received: from jaguar.hughesbpo.net ([61.246.186.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJpF7-000768-1o
	for dime@ietf.org; Wed, 21 Feb 2007 06:02:39 -0500
Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1])
	by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l1LB2LJe008093
	for ; Wed, 21 Feb 2007 16:32:21 +0530
Received: from sandesh.hss.hns.com (sandesh [10.203.142.21])
	by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l1LB2D5H008051
	for ; Wed, 21 Feb 2007 16:32:21 +0530
To: dime@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006
Message-ID: 
From: Nimish Bhargava 
Date: Wed, 21 Feb 2007 16:36:41 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30,
	2005) at 21/02/2007 04:35:59 PM,
	Serialize complete at 21/02/2007 04:35:59 PM
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Subject: [Dime] Vendor Specific Application Id AVP
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="===============2108536471=="
Errors-To: dime-bounces@ietf.org

This is a multipart message in MIME format.
--===============2108536471==
Content-Type: multipart/alternative;
	boundary="=_alternative 003CE15265257289_="

This is a multipart message in MIME format.
--=_alternative 003CE15265257289_=
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: base64

SGksDQoNCkluIFZlbmRvciBTcGVjaWZpYyBBcHBsaWNhdGlvbiBJZCBBVlAsIHNob3VsZCB0aGVy
ZSBiZSBhbnkgY2hlY2sgb24gdGhlIA0KdmFsdWUgb2YgQXV0aCBBcHBsaWNhdGlvbiBJZCBBVlAg
KGl0IGlzIGEgcGFydCBvZiBWZW5kb3IgU3BlY2lmaWMgDQpBcHBsaWNhdGlvbiBJZCBBVlApIGRl
cGVuZGluZyB1cG9uIHRoZSBjb21tYW5kIGluIHdoaWNoIHRoZSBBVlAgaGFzIGJlZW4gDQpyZWNl
aXZlZC4NCg0KRm9yIGVnLiBJbiBjYXNlIG9mIFVEUiBjb21tYW5kIHRoZSB2YWx1ZSBvZiBBdXRo
IEFwcGxpY2F0aW9uIElkIEFWUCBzaG91bGQgDQpiZSAxNjc3NzIxNyBvciBpbiBjYXNlIG9mIEND
UiB0aGUgdmFsdWUgaXMgNC4NCg0KUmVnYXJkcywNCk5pbWlzaA0KDQoNCioqKioqKioqKioqKioq
KioqKioqKioqICBBcmljZW50LVVuY2xhc3NpZmllZCAgICoqKioqKioqKioqKioqKioqKioqKioq
DQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFu
ZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdo
b20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVu
dGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZv
ciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBv
cmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp
ZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZy
b20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBv
ZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxv
c3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFu
c21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCg==
--=_alternative 003CE15265257289_=
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5IaSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv
bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5JbiBWZW5kb3IgU3BlY2lmaWMgQXBwbGljYXRpb24gSWQg
QVZQLCBzaG91bGQNCnRoZXJlIGJlIGFueSBjaGVjayBvbiB0aGUgdmFsdWUgb2YgQXV0aCBBcHBs
aWNhdGlvbiBJZCBBVlAgKGl0IGlzIGEgcGFydA0Kb2YgVmVuZG9yIFNwZWNpZmljIEFwcGxpY2F0
aW9uIElkIEFWUCkgZGVwZW5kaW5nIHVwb24gdGhlIGNvbW1hbmQgaW4gd2hpY2gNCnRoZSBBVlAg
aGFzIGJlZW4gcmVjZWl2ZWQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJB
cmlhbCI+Rm9yIGVnLiBJbiBjYXNlIG9mIFVEUiBjb21tYW5kIHRoZSB2YWx1ZQ0Kb2YgQXV0aCBB
cHBsaWNhdGlvbiBJZCBBVlAgc2hvdWxkIGJlIDE2Nzc3MjE3IG9yIGluIGNhc2Ugb2YgQ0NSIHRo
ZSB2YWx1ZQ0KaXMgNC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs
Ij5SZWdhcmRzLDxicj4NCk5pbWlzaDxicj4NCjxicj4NCjxicj4NCioqKioqKioqKioqKioqKioq
KioqKioqICZuYnNwO0FyaWNlbnQtVW5jbGFzc2lmaWVkICZuYnNwOyAqKioqKioqKioqKioqKioq
KioqKioqKjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48Zm9udCBjb2xv
cj0jMDAwMDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0
byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5k
aXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdl
ZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0
ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRl
bmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNl
IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGlu
dGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkK
cHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0
aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2li
aWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5m
b3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20g
dmlydXMuIgo8L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwvdGFibGU+
--=_alternative 003CE15265257289_=--


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

--===============2108536471==--




From dime-bounces@ietf.org Wed Feb 21 12:17:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJv5W-00010m-0W; Wed, 21 Feb 2007 12:17:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJv5U-00010e-Da
	for dime@ietf.org; Wed, 21 Feb 2007 12:17:04 -0500
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 1HJv5O-00031p-TZ
	for dime@ietf.org; Wed, 21 Feb 2007 12:17:04 -0500
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
	l1LHGarO009809
	for ; Wed, 21 Feb 2007 12:16:36 -0500 (EST)
	(envelope-from vfajardo@tari.toshiba.com)
Message-ID: <45DC7E9B.2040908@tari.toshiba.com>
Date: Wed, 21 Feb 2007 12:17:15 -0500
From: Victor Fajardo 
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Subject: [Dime] Diameter Interoperability Report - Jan 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's is a short summary of the Diameter Interop Event that took place 
on Jan 29 - Feb 1, 2007 (http://www.diameterinterop.com).
We also like to thank Intellinet Technologies for hosting the event and 
making it successful.

Diameter Interop Report
Event: Jan 29 - Feb 1 2007
 
The minutes of the meetings as well as details of the events can be 
found in http://www.tschofenig.priv.at/twiki/bin/view/Dime/DiameterInterop2007
 
Participants concentrated on the following tests:

  * Base protocol
  * Diameter Credit control
  * 3GPP interfaces

Limited testing was done on:

  * NASREQ
  * EAP

Below short list of what was tested. Note that the section numbers
correspond to the test suites in http://www.ietf.org/internet-drafts/
draft-fajardo-dime-interop-test-suite-04.txt.

Legend:

  (ST) Successful tests
  (NT) Not tested (but implemented)
  (NI) Not implemented

A. Base Protocol
 
  3.1.1.1. Capabilities Negotiation       ST
  3.1.1.2. Election                       ST
  3.1.1.3. Disconnection                  ST
  3.1.1.4. Re-Connection Algorithms       ST
  3.1.1.5. Failover and Failback          ST
  3.1.2.1. Peer Based Request Routing     ST
  3.1.2.2. Realm Based Routing            ST
  3.1.2.3. Answer Message Routing         ST
  3.1.2.4. Loop Detection                 NT
  3.1.3. Relay Agent                      ST
  3.1.4. Redirection                      NT
  3.2.1. General Statemachine             ST
  3.2.2. Dynamic Peer Discovery           NT

  Not present in the test suite

  Duplicate Detection Test                NI  
  TLS                                     ST
  SCTP                                    ST


B. Diameter Credit Control and 3GPP Ro Interface

  4.2.1.1. Session Based Credit Control First Interrogation             ST
  4.2.1.2. Session Based Credit Control Intermediate Interrogation      ST
  4.2.1.3. Session Based Credit Control Final Interrogation             ST
  4.2.1.4. Sub Sessions                                                 NT
  4.2.1.5. Session Based Credit Control Failure Procedures              ST
  4.2.1.6. Service Price Enquiry                                        ST
  4.2.1.7. Balance Check                                                ST
  4.2.1.8. Direct Debiting                                              ST
  4.2.1.9. Refunds                                                      ST
  4.2.1.10. Event Based Credit Control Failure Procedures               ST
  4.2.2.1 Tariff Time Support                                           ST
  4.2.2.2. Graceful Service Termination                                 NT
  4.2.2.3. Validity Time                                                ST
  4.2.2.4. Server Initiated Credit Reauthorization                      NI

  4.4.2.1. UDR Sh                                                       ST
  4.3.3.2. Rf Interface (not using SIP)                                 ST

C. Diameter EAP

  4.5.1.1. Non-Roaming case           ST
  4.5.1.2. Roaming scenario           NT
  4.5.2. Optional Tests               NT

D. Diameter NASREQ

  4.6.1.1. Auth Session               ST
  4.6.1.2. Diameter/RADIUS Gateway    NI     
  4.6.1.3. Multi-domain Scenario      NT     
  4.6.2.1. Auth Session               ST

E. Diameter Cx nterface

  4.4.1.1 UAR exchange                ST

F. Diameter Sh Interface

  4.4.2.1. UDR exchange               ST
  4.4.2.1. PUR exchange               ST

G. Diameter Rf Interface

  4.4.3.1 Required                    ST
  4.4.3.2 Optional                    NT

H. Diameter MIP

  4.7.1. Generic MIP Test Scenarios                       NT       
  4.7.2.1. Co-located Registration                        NT     
  4.7.2.2. Intra-Domain Registration                      NT     
  4.7.2.3. Inter-Domain Registration                      NT
  4.7.2.4. Allocation of HA in Foreign Network            NT     
  4.7.3.1. Co-located Registration (optional features)    NT     
  4.7.3.2. Inter-Domain Registration with Redirect        NT     
  4.7.3.3. Inter-Domain Registration with Proxy/Relay     NT     

Some of the participants manage to form a complex topology
to test failover and general routing. A pictorial diagram of
this tolopogy can be found in:
http://www.tschofenig.priv.at/twiki/bin/view/Dime/ToshibaTests
The tests performed on this topology is also summarized there.

It was also observed that the test suite document does not cover many of the
more detailed cases and it was suggested that we split the document into
several test documents such as base protocol test document and a test 
document
for each diameter application.

A summary of issues raised by the participants can be found in:
http://www.tschofenig.priv.at:8080/diameter-interop

For general DIME activity, see:
http://www.tschofenig.priv.at/twiki/bin/view/Dime

best regards,
victor


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



From dime-bounces@ietf.org Wed Feb 21 12:21:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJvA8-0001ie-L9; Wed, 21 Feb 2007 12:21:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvA7-0001iX-Ik
	for dime@ietf.org; Wed, 21 Feb 2007 12:21:51 -0500
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 1HJvA6-0004Fr-TA
	for dime@ietf.org; Wed, 21 Feb 2007 12:21:51 -0500
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
	l1LHLWkQ009845
	for ; Wed, 21 Feb 2007 12:21:32 -0500 (EST)
	(envelope-from vfajardo@tari.toshiba.com)
Message-ID: <45DC7FC3.7010701@tari.toshiba.com>
Date: Wed, 21 Feb 2007 12:22:11 -0500
From: Victor Fajardo 
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 8de8c36679aaa17b008853e74231c885
Subject: [Dime] Issue Summary for rfc3588bis - based on the last interop
	event
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

Summary
-------
 
The following is a summary of issues raised during the last interop. 
Note that these issues are rolled into the interop report. Also, issues 
are mapped to tracking numbers in: 
http://www.tschofenig.priv.at:8080/diameter-interop/index
 
Issues List
-----------
 
 
#32 What is the set of application ids that should be returned in the CEA
 
   A question was raised on what is the set of application ids should  
   a diameter peer return in the CEA. Should it be:
 
   a. An intersection of its own set of app ids and its peer. OR
   b. All of its own supported app ids.
 
   Concerns          : Some edge devices may not be capable of storing  
                       all app ids of peers.
 
   Current consensus : It should return all of its own supported app ids.
                       The intersection can be computed locally by both
                       peers. It maybe an implementation decision but
                       edge devices concerned about storage need not keep
                       the ids. In general the received set of supported
                       apps would only be useful as a future hint about
                       the peers capabilities.
 

 
#33 Why is there a need for Vendor-Specific-Application-Id
 
   A question was raised on why do we need the vendor-specific-app-id
   if the app id space is flat and vendor app ids have an allocated  
   lot in this space.  
                        
   Current consensus  : The intent of this AVP was never fully understood
                        hence we just have to clarify what we currently
                        have and make sure we treat Vendor-Spec-App-Id
                        as an ordinary app id and ingore the vendor-id
                        associated with it.
                         
   Comments from Glenn McGregor: Does this play into the possible ability
                        to route DCC and Ro differently?
                         


#34 Precedence of routes discovered via Redirect indications
 
   A question was raised on what would be the possible precedence order
   when messages matches routing criterias in multiple cached redirect
   routes. The sample scenario is as follows:
 
     a. message with realm='a.com' is redirected to host 'y' with usage 
ALL_REALM
     b. message with user='x' is redirected to host 'z' with usage ALL_USER
     c. both redirect routes (a) and (b) are cached
     d. message with realm='a.com' and user='x' arrvies.
 
   Strawman proposal: The order would be
                         DONT_CACHE
                         ALL_SESSION
                         ALL_USER
                         REALM_AND_APPLICATION
                         ALL_REALM
                         ALL_APPLICATION
                         ALL_HOST
 
   Comments from 3588 Authors (Glenn Zorn):  
 
      This should not happen because the intent is to have only on cached
      redirect route at any given time. If a new redirect route was 
injected,
      it would replace any existing cached route.

   Comments from Glenn McGregor:
   
      Another possible point of interpretation is what is the scope of
      the redirect info? Should it apply to requests before a peer is
      chosen, or does it only active when picking a peer that sent the
      redir info.
 
   Consensus: Discussion continues
 


#35 What is the expected representation and/or encoding of FQDN as used 
in diameter identities
 
   The question raised comes in two parts:
 
   1. Does the FQDN have a syntatic meaning or semantic., i.e. Is it 
suppose
      to a) just look like an ascii version of an FQDN or b) does it 
actually have
      to be DNS resolvable ?
 
   2. If the answer to (1) is (b) then how do we deal with the different 
DNS FQDN
      transliteration/encoding ? Specifically how do we do comparisons ?
       
 
   Comments from 3588 Authors (Jari Arko): For the most part it is
            interesting to diameter from the point of view of comparing
            identities in usage such as lookups. My quick guess is that
            there is no need to do a DNS lookup. I could be wrong. 
Resolution
            maybe only be needed when you a redirect for a particular 
server.
 
   Comments from 3588 Authors (Glen Zorn): With regards to FQDN, you still  
            have a problem since the diameter identifier was expressed 
in FQDN
            and I remember that the internationalization stuff was 
ongoing at  
            the time the diameter spec was being defined. So you did not 
want  
            to guess what they are going to do and what FQDN would have 
become  
            would be fine.
 
            You have to make a new rule. You can have a bunch of different
            names in DNS and one of them has to match what you claim is 
your
            diameter name. You might have to say what transliteration 
method
            is used. It gets real complicated. We need to talk to some 
expert
            in this field to get clarification.
 
   Consensus: Need to talk to experts to do futher clarification.
 
   Notes: See interop minutes for full details of the discussion
 


#36 Relevance of vendor-id when computing common applications in CER/CEA 
exchange.
 
   A suggestion was made to add text stating that vendor-id will not be 
used
   as a descriminator when computing common applications between peers 
during
   capabilities exchange.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.
 
   Notes: 01 version of bis document mentions that vendor-id is not used in
          discriminating routes.
          
   Comments from Glenn McGregor: Should AUTH vs ACCT be used to 
determine intersection?
 


#37 Several clarification on election
 
   1. A question was raised on why the winner of the election would be 
the one
      to disconnect.
   
      Answer from 3588 Author (Jari Arko): It was thought that the 
winner of
      the election should do less work to managed the connection as 
oppose to
      the looser.
 
   2. A suggestion was raised on changing the text regarding the 
lexographic
      comparison (alpabetical) in Sec 5.6.4. The text should simply say 
that
      a lexographical comparison of the identities is done, however that 
identity
      (FQDN) maybe encoded (ascii, unicode, internatinalization etc) and
      however such comparison is performed in that encoding.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.
              
   Comments from Glenn McGregor: Not clear to me which has more or less 
work.
              Once you have a socket handle, it doesn't really matter which
              end initiated the connection. (At least in the languages/OSs
              I've worked in).
              
   Proposal from Glenn McGregor: If old-style FQDN ([A-Za-z0-9-_]+) then a
             case insensitive comparison may be used. Otherwise, byte by 
byte.
 


#38 Need to state clearly what transport layer security version should 
be used
 
   A suggestion was raised in which 3588 should clearly state which 
transport  
   layer security version should be used. There where issues when one 
implementation
   uses SSLv2 as opposed to TLSv1. See minutes for details.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.
              
   Comments from Glenn McGregor: Actually, we need to clearly call out what
              kind of ClientHello envelope is to be used. Everyone so 
far has
              initially attempted to negotiate TLS inside a SSLv2 client 
hello
              message.
 


#39 Need for additional verification of received certificates when using 
TLS
 
   A question was raised if there should be additional validation of 
received
   certificates, maybe against the origin-host.
 
      Strawman from Glenn McGregor: Match the CN of the certificate with 
the
                                    origin-host of the peer
 
      Comments from 3588 Author (Jari Arko): How would you go about this ?
            Would you add something in the certificate
            that says you can use this to authenticate for example
            domain foo.com and anything beyond that is not valid. There
            are definitely questions in this area. Worth investigating.
 
      Consensus: Discussion continues
 
      Notes: See interop minutes for full details of the discussion
      
      Comments from Glenn McGregor: One of the guys here recommended we look
             at RFC 3280 - Subject Alternate name.
 


#40 Clarify the minimum amount of information a relay has to inspect for 
a message
 
   A question was raised on how much processing a relay agent must 
perform for
   every message that it forwards.
 
   Consensus:  You cannot avoid some validation of the message since a 
relay needs
               to inspect not only the message header but relevant 
routing avps
               as well. At the minimum, full validation will be done by 
a relay
               on the header and relevant routing avps and some sanity 
check will
               be peformed for the remaining avps since parsing the 
message requires  
               walking through most/all of the avps headers.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.
 


#41 Description Clarification and Terminology changes
 
   1. A suggestion was made that since routing information is not 
restricted to
      realms and app ids espcially with regards to redirect routes, the 
"Realm
      Routing Table" should be changed to "Routing Table"
 
   2. A suggestion was made that we calrify the description of 
NO_COMMON_APPLICATION.
      It should read as "A node that is not acting as a relay and 
supporting  
      a specific set of application that has a empthy intersection with 
the set
      of application advertised by its peer MUST return 
NO_COMMON_APPLICATION
      in the CEA".
 
   3. A suggestion was made that additional text stating "Vendor-Id or 
Supported-Vendor-Id
      SHOULD NOT be zero" needs to be made.
 
   4. A suggestion was made to clarify description of the routing table to
      account for addition of redirect routes. The suggested text is:
      "Realm and application ids are the minimum supported routing 
criteria,
       additional routing information maybe needed to support redirect 
semantics"
       
   5. Don't send 'supported-vendor-id = 0' CER/CEA. Don't the send the 
same ID
      multiple times.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.
              


#42 Interoperability of DCC and Ro

    During the last interoperability event. There was an issue with 
regards to
    interoperability of DCC and Ro. DCC was routed using the normal app 
id and realm
    descriptor while Ro had embedded the application id (???) into a VSAI.
    
    A question was raised on whether DCC and Ro should be routed/treated as
    different applications.
    
    Comments from Tolga Asveren:
    
    IMHO they should be, but it is hard for us to do anything about it.
    The problem is that 3GPP did not use a new Application-Id. They 
needed to
    use a new one because they defined lots of new AVPs with M-bit set. 
Ro and
    DCCA are used for the same purpose but the semantics are different 
due to
    the new AVPs defined by Ro. IMHO, in such situations people 
shouldn't try to
    use "initiative", they just need to follow the rule which dictates 
that a
    new application has to be defined. We can document that there is a 
problem
    and hint that presence of Ro defined AVPs could be used for routing
    purposes.
    
    Regarding the confusion of the contents of DCCA messages, I guess 
the main
    problem is that command ABNFs are defined genericly, e.g. there is no
    separate ABNF for CCR for session and different event based 
scenarios. So,
    only AVPs, which are mandatory for all scenarios are marked in the 
ABNF as
    mandatory, e.g. User-Name in CCR is mandatory for session based 
messages and
    for event based messages except Service Price Enquiry, hence it is not
    marked as a mandatory AVP. There seem to be two options: Defining 
command
    ABNFs per scenario or relying on textual description (this is pretty 
much
    what is done now).
    


#43 Which application id should be used in NASREQ accounting

    A question was raised on which application id should be used in NASREQ
    accounting message. A further consequence of this are:

    Comments from Glenn McGregor:
        
    Does "Acct-Application-Id = NASREQ" need to be separately announced 
in CER/CEA
    exchange? Do we want to call out separate routing for AUTH vs ACCT 
NASREQ?
    Or is it like STR, RAR,  ASR commands that come for free?



#44 Diameter Extensibility Clarification

    While writing the diameter extensibility guidelines, a question was 
raised
    on the following text. The suggestion stated below requires some 
relaxation
    of the diameter application id allocation rules.
    
    "In order to justify allocation of a new application identifier,
     Diameter applications MUST define one Command Code, or add new
     mandatory AVPs to the ABNF."
    
    Comments from Tolga Asveren:
    
    IMHO, the second part of this sentence causes much confusion. Adding 
an AVP with
    M-bit set but optional in command ABNF MUST cause a new 
application-Id to be
    used, which according to that sentence doesn't. I would prefer the 
following:

    (The following is a change to RFC3588. IMHO, it is a necessary 
change, but I do
    not know whether this document is the right place to do so. Is this 
again bis
    material? If so and if we want to stick to what is said in the 
RFC3588, would it
    be really useful to clarify something we want to change (of course 
only if you
    guys agree with my understanding :-) )

    Proposed text:
    
    In order to justify allocation of a new application identifier, Diameter
    applications MUST define one Command Code, add a new AVP with M-bit 
set to
    one of the existing commands or change the state machine/processing 
rules for
    an existing application.
    


#45 Clarify the possible accounting models


    While editing the application design guidelines doc, it was realized 
that
    the possible accounting usages and models was not clearly described in
    RFC3588. The text below is a proposal to add a new section describing
    these models.
    
    Comments from Tolga for text describing accounting models in the bis:

    Application Accounting Models
   
    Applications MAY use one of the following accounting models:

     o Coupled Accounting

       In this model, the same entity provides both application processing
       logic and accounting functionality. Accounting messages are sent by
       populating the Application-Id field in the message header with the
       application identifier of the corresponding application. No special
       behavior is exptectd during capability exchange procedure or during
       message routing.

     o Split Accounting

       This model assumes presence of a standalone accounting server, which
       MAY possibly be handling accounting for multiple applications. 
Accounting
       messages are sent by using the base accounting application 
identifier 3
       in the Application-Id field in the message header. Accounting servers
       operating in this mode MUST advertise the identifiers for the
       applications for which they can provide accounting service in the
       Acct-Application-Id AVP during capability exchange procedure. For 
split
       accounting scenario, accounting messages MUST include the 
identifier of
       the corresponding  application in the Acct-Application-Id AVP. 
During
       routing of accounting messages Acct-Application-Id AVP value MUST 
be used
       as well in addition to Application-Id to select an appropriate 
accounting
       server. It should be noted that all intermediary nodes, e.g. relay
       agents, MUST be able to route accounting messages by considering 
both the
       Application-Id in the message header and Acct-Application-Id AVP 
in order
       to utilize split accounting.


regards,
victor

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



From dime-bounces@ietf.org Thu Feb 22 17:44:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKMfi-00047Q-Ld; Thu, 22 Feb 2007 17:44:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKMfh-00047L-N5
	for dime@ietf.org; Thu, 22 Feb 2007 17:44:17 -0500
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKMfg-0001i8-G9
	for dime@ietf.org; Thu, 22 Feb 2007 17:44:17 -0500
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id
	5AE111D088 for ; Thu, 22 Feb 2007 17:44:14 -0500 (EST)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l1MMiDrB019548
	for ; Thu, 22 Feb 2007 17:44:13 -0500 (EST)
From: "Tolga Asveren" 
To: 
Date: Thu, 22 Feb 2007 17:38:48 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Subject: [Dime] Issue #39: Need for additional verification of received
	certificates when using TLS
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 think we all agree that we need some checks on certificates in addition to
what TLS already does. TLS verifies that the certificate is valid but it
doesn't perform any check about for what purpose the certificate is issued.
IMO, the proposal of using  Subject Alternative Name extension makes sense
(dNSName or uniformResourceIdentifier). We can store DiameterURI, Diameter
Identity or domainname.

I believe performing a check for the manual configuration case is relatively
straightforward. The identity of the entity on the other side of the
connection is already known and we check this identity against what is
present in the corresponding field in the certificate.

For dynamic peer discovery case, RFC3588 already provides some guidelines in
5.2 regarding certificate checks (both domainname in the query and
domainname in the replacement must be valid). I am not sure though, how one
would handle the case, where certain service (or routing of messages for
certain service) is delegated to another organization. For example, if I
want to outsource DCCA to OrganizationA but want to handle NASREQ myself,
how could I indicate in the certificate prepared for OrganizationA, that it
is valid for my domain but only for DCCA? Does it make sense to include
application identifier in the certificate to deal with this type of
scenario?

   Thanks,
   Tolga


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



From dime-bounces@ietf.org Fri Feb 23 04:18:18 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKWZD-0007Y3-TC; Fri, 23 Feb 2007 04:18:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKWZC-0007Wr-3C
	for dime@ietf.org; Fri, 23 Feb 2007 04:18:14 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKWZA-0004WX-QI
	for dime@ietf.org; Fri, 23 Feb 2007 04:18:14 -0500
Received: (qmail invoked by alias); 23 Feb 2007 09:18:11 -0000
X-Provags-ID: V01U2FsdGVkX183ka0wjns3rYNRnNjl0QAQ2GBShQRdg8YVgSJ4fh
	pFUQ==
Message-ID: <45DEB152.2020904@gmx.net>
Date: Fri, 23 Feb 2007 10:18:10 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Subject: [Dime] Meeting Agenda -- 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,

I have uploaded a new version of the agenda. It still has some holes. 
Please help me to complete the agenda.

Here is the current version:
http://www3.ietf.org/proceedings/07mar/agenda/dime.txt

Ciao
Hannes


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



From dime-bounces@ietf.org Fri Feb 23 04:38:42 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKWsw-0006QI-BX; Fri, 23 Feb 2007 04:38:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKWsv-0006Q8-B8
	for dime@ietf.org; Fri, 23 Feb 2007 04:38:37 -0500
Received: from mail119.messagelabs.com ([216.82.241.179])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKWsu-00018q-4R
	for dime@ietf.org; Fri, 23 Feb 2007 04:38:37 -0500
X-VirusChecked: Checked
X-Env-Sender: liyaqatali@motorola.com
X-Msg-Ref: server-5.tower-119.messagelabs.com!1172223511!9966500!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.9]
Received: (qmail 16675 invoked from network); 23 Feb 2007 09:38:31 -0000
Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9)
	by server-5.tower-119.messagelabs.com with SMTP;
	23 Feb 2007 09:38:31 -0000
Received: from az33exr02.mot.com ([10.64.251.232])
	by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l1N9cUIP024029
	for ; Fri, 23 Feb 2007 03:38:31 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l1N9cTS8014934
	for ; Fri, 23 Feb 2007 03:38:30 -0600 (CST)
Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM66.ds.mot.com with
	Microsoft SMTPSVC(6.0.3790.2709); Fri, 23 Feb 2007 17:38:27 +0800
Message-ID: <45DEB6FF.7050908@motorola.com>
Date: Fri, 23 Feb 2007 15:12:23 +0530
From: Liyaqatali 
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: dime@ietf.org, Tolga Asveren 
X-OriginalArrivalTime: 23 Feb 2007 09:38:27.0765 (UTC)
	FILETIME=[5F056650:01C7572E]
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: 
Subject: [Dime] DCCA
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="===============1299470455=="
Errors-To: dime-bounces@ietf.org

--===============1299470455==
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  




Hi



Couple of questions. 

In RFC 4006, sec 5.2 which states  "If several unit
types are sent in the Answer message, the credit-control client MUST
handle each unit type separately." What does it it actual mean to
handle it separately? 



Suppose the client requests some units in time but the server grants
both in time and money i.e. server adds cc-time and cc-money avps in
the granted service units AVP then how is the client suppose to handle
this? if client can understand only time then? Should the client
request and report used units  in both time and money or is it fine to
report in either ?



I would really appreciate if you can help me out here. 

 

-- 
Regards,
Liyaqatali G Nadaf








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

--===============1299470455==--



From dime-bounces@ietf.org Fri Feb 23 14:18:57 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKfwX-0001Ua-Lw; Fri, 23 Feb 2007 14:18:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKfwV-0001Td-Nq
	for dime@ietf.org; Fri, 23 Feb 2007 14:18:55 -0500
Received: from ns6.comverse.com ([192.118.49.220])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HKfwS-0008Bk-V3
	for dime@ietf.org; Fri, 23 Feb 2007 14:18:55 -0500
X-SBRS: None
X-IronPort-AV: i="4.14,212,1170626400"; 
	d="scan'208"; a="108101150:sNHT15472421363"
Received: from dencomexch01.csg.csgsystems.com ([10.8.33.55]) by
	UKADEXCH01.csg.csgsystems.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Feb 2007 19:18:26 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Feb 2007 12:14:09 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question: source of address/port to be used for server responses
Thread-Index: AcdXfsuftBaCQTV/QtGtKC0rM/PLXg==
From: "Parker, James" 
To: 
X-OriginalArrivalTime: 23 Feb 2007 19:18:26.0962 (UTC)
	FILETIME=[64F57720:01C7577F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [Dime] Question: source of address/port to be used for server
	responses
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 am looking at implementing the Diameter protocol for a server, and I
cannot find a clear statement as to how to create the proper channel to
send responses (answers).  Is the proper method:
=20
    - Clone a response channel (e.g., by an accept() system call)?
    - Open the CER Origin-Host/port 3868
    - Open the CER Host-Realm (port 3868 if none specified)
    - Open the CER Host-IP-Address(es)/port 3868
    - Some other method

The first seems the most logical; however that could result in security
issues if a firewall is crossed (since arbitrary ports must be opened).

Thanks in Advance

James Parker
Distinguished Software Development Engineer
Comverse, Inc.

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



From dime-bounces@ietf.org Fri Feb 23 14:36:51 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKgDf-0008RE-5B; Fri, 23 Feb 2007 14:36:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKgDd-0008R4-8z
	for dime@ietf.org; Fri, 23 Feb 2007 14:36:37 -0500
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKgDc-00027Y-0Z
	for dime@ietf.org; Fri, 23 Feb 2007 14:36:37 -0500
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id
	DBA471492D for ; Fri, 23 Feb 2007 14:36:21 -0500 (EST)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l1NJaGJN012137
	for ; Fri, 23 Feb 2007 14:36:21 -0500 (EST)
From: "Tolga Asveren" 
To: 
Subject: RE: [Dime] Question: source of address/port to be used for
	serverresponses
Date: Fri, 23 Feb 2007 14:31:46 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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

James,

There is always a single Diameter connection between two adjacent entities,
and answers are always sent on the connection from which the corresponding
requests has been received.

    Thanks,
    Tolga

> -----Original Message-----
> From: Parker, James [mailto:James.Parker@comverse.com]
> Sent: Friday, February 23, 2007 2:14 PM
> To: dime@ietf.org
> Subject: [Dime] Question: source of address/port to be used for
> serverresponses
>
>
> I am looking at implementing the Diameter protocol for a server, and I
> cannot find a clear statement as to how to create the proper channel to
> send responses (answers).  Is the proper method:
>
>     - Clone a response channel (e.g., by an accept() system call)?
>     - Open the CER Origin-Host/port 3868
>     - Open the CER Host-Realm (port 3868 if none specified)
>     - Open the CER Host-IP-Address(es)/port 3868
>     - Some other method
>
> The first seems the most logical; however that could result in security
> issues if a firewall is crossed (since arbitrary ports must be opened).
>
> Thanks in Advance
>
> James Parker
> Distinguished Software Development Engineer
> Comverse, Inc.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime


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



From dime-bounces@ietf.org Fri Feb 23 17:39:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKj46-0005nT-Ns; Fri, 23 Feb 2007 17:38:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKj44-0005nN-Rr
	for dime@ietf.org; Fri, 23 Feb 2007 17:38:56 -0500
Received: from ironport.comverse.com ([192.118.49.220] helo=ns6.comverse.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKj43-00027p-FJ
	for dime@ietf.org; Fri, 23 Feb 2007 17:38:56 -0500
X-SBRS: None
X-IronPort-AV: i="4.14,213,1170626400"; 
	d="scan'208"; a="108139201:sNHT32081294"
Received: from dencomexch01.csg.csgsystems.com ([10.8.33.55]) by
	UKADEXCH01.csg.csgsystems.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Feb 2007 22:39:38 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
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] Question: source of address/port to be used for
	serverresponses
Date: Fri, 23 Feb 2007 15:33:00 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Question: source of address/port to be used for
	serverresponses
Thread-Index: AcdXgnKfx98AqpPeSnasSq/VPRJT9wAFh0Ig
From: "Parker, James" 
To: "Tolga Asveren" ,
	
X-OriginalArrivalTime: 23 Feb 2007 22:39:38.0136 (UTC)
	FILETIME=[7FF07180:01C7579B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Thanks.

I *think* this means my first method (clone a response channel) is
correct, and the use of "accept" in the RFC is a term of art rather than
a common language term.  My concern was that this creates a connection
with one end being an ephimeral port on the client.

This means the statement "The base Diameter protocol is run on port 3868
of both TCP [TCP] and SCTP [SCTP] transport protocols" does not mean
that all messages must use that port, even once a connection is
established.  Given that this has an impact on the configuration of
firewalls over which the connection may pass, this could have been
interpreted differently.

James Parker
Distinguished Software Development Engineer
Comverse, Inc.


-----Original Message-----
From: Tolga Asveren [mailto:asveren@ulticom.com]=20
Sent: Friday, February 23, 2007 2:32 PM
To: dime@ietf.org
Subject: RE: [Dime] Question: source of address/port to be used
forserverresponses

James,

There is always a single Diameter connection between two adjacent
entities, and answers are always sent on the connection from which the
corresponding requests has been received.

    Thanks,
    Tolga

> -----Original Message-----
> From: Parker, James [mailto:James.Parker@comverse.com]
> Sent: Friday, February 23, 2007 2:14 PM
> To: dime@ietf.org
> Subject: [Dime] Question: source of address/port to be used for=20
> serverresponses
>
>
> I am looking at implementing the Diameter protocol for a server, and I

> cannot find a clear statement as to how to create the proper channel=20
> to send responses (answers).  Is the proper method:
>
>     - Clone a response channel (e.g., by an accept() system call)?
>     - Open the CER Origin-Host/port 3868
>     - Open the CER Host-Realm (port 3868 if none specified)
>     - Open the CER Host-IP-Address(es)/port 3868
>     - Some other method
>
> The first seems the most logical; however that could result in=20
> security issues if a firewall is crossed (since arbitrary ports must
be opened).
>
> Thanks in Advance
>
> James Parker
> Distinguished Software Development Engineer Comverse, Inc.
>
> _______________________________________________
> 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 Fri Feb 23 17:59:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKjNF-0003as-Rn; Fri, 23 Feb 2007 17:58:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKjNF-0003am-E7
	for dime@ietf.org; Fri, 23 Feb 2007 17:58:45 -0500
Received: from bender-mail.tigertech.net ([64.62.209.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKjND-0005P1-PB
	for dime@ietf.org; Fri, 23 Feb 2007 17:58:45 -0500
Received: from localhost (localhost [127.0.0.1])
	by bender.tigertech.net (Postfix) with ESMTP id 2A6127E23;
	Fri, 23 Feb 2007 14:58:40 -0800 (PST)
Received: from [128.107.112.42] (dhcp-128-107-112-42.cisco.com
	[128.107.112.42])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bender.tigertech.net (Postfix) with ESMTP id 0501F7E09;
	Fri, 23 Feb 2007 14:58:37 -0800 (PST)
Message-ID: <45DF719C.2060805@frascone.com>
Date: Fri, 23 Feb 2007 17:58:36 -0500
From: David Frascone 
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: "Parker, James" 
Subject: Re: [Dime] Question: source of address/port to be used
	for	serverresponses
References: 
In-Reply-To: 
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net
X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, 
	HTML_MESSAGE
X-Spam-Level: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1814383785=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.
--===============1814383785==
Content-Type: multipart/alternative;
	boundary="------------090700020508020509040102"

This is a multi-part message in MIME format.
--------------090700020508020509040102
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

It means that the destination port of the peer doing the connect should
be 3868.  The source port will vary.  Firewalls should work fine with
this mechanism

-Dave

Parker, James wrote:
> Thanks.
>
> I *think* this means my first method (clone a response channel) is
> correct, and the use of "accept" in the RFC is a term of art rather than
> a common language term.  My concern was that this creates a connection
> with one end being an ephimeral port on the client.
>
> This means the statement "The base Diameter protocol is run on port 3868
> of both TCP [TCP] and SCTP [SCTP] transport protocols" does not mean
> that all messages must use that port, even once a connection is
> established.  Given that this has an impact on the configuration of
> firewalls over which the connection may pass, this could have been
> interpreted differently.
>
> James Parker
> Distinguished Software Development Engineer
> Comverse, Inc.
>
>
> -----Original Message-----
> From: Tolga Asveren [mailto:asveren@ulticom.com] 
> Sent: Friday, February 23, 2007 2:32 PM
> To: dime@ietf.org
> Subject: RE: [Dime] Question: source of address/port to be used
> forserverresponses
>
> James,
>
> There is always a single Diameter connection between two adjacent
> entities, and answers are always sent on the connection from which the
> corresponding requests has been received.
>
>     Thanks,
>     Tolga
>
>   
>> -----Original Message-----
>> From: Parker, James [mailto:James.Parker@comverse.com]
>> Sent: Friday, February 23, 2007 2:14 PM
>> To: dime@ietf.org
>> Subject: [Dime] Question: source of address/port to be used for 
>> serverresponses
>>
>>
>> I am looking at implementing the Diameter protocol for a server, and I
>>     
>
>   
>> cannot find a clear statement as to how to create the proper channel 
>> to send responses (answers).  Is the proper method:
>>
>>     - Clone a response channel (e.g., by an accept() system call)?
>>     - Open the CER Origin-Host/port 3868
>>     - Open the CER Host-Realm (port 3868 if none specified)
>>     - Open the CER Host-IP-Address(es)/port 3868
>>     - Some other method
>>
>> The first seems the most logical; however that could result in 
>> security issues if a firewall is crossed (since arbitrary ports must
>>     
> be opened).
>   
>> Thanks in Advance
>>
>> James Parker
>> Distinguished Software Development Engineer Comverse, Inc.
>>
>> _______________________________________________
>> 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
>   

-- 

David Frascone

           Why doesn't DOS ever say "Excellent command or filename!"


--------------090700020508020509040102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


It means that the destination port of the peer doing the connect should
be 3868.  The source port will vary.  Firewalls should work fine with
this mechanism



-Dave



Parker, James wrote:


  
Thanks.

I *think* this means my first method (clone a response channel) is
correct, and the use of "accept" in the RFC is a term of art rather than
a common language term.  My concern was that this creates a connection
with one end being an ephimeral port on the client.

This means the statement "The base Diameter protocol is run on port 3868
of both TCP [TCP] and SCTP [SCTP] transport protocols" does not mean
that all messages must use that port, even once a connection is
established.  Given that this has an impact on the configuration of
firewalls over which the connection may pass, this could have been
interpreted differently.

James Parker
Distinguished Software Development Engineer
Comverse, Inc.


-----Original Message-----
From: Tolga Asveren [mailto:asveren@ulticom.com] 
Sent: Friday, February 23, 2007 2:32 PM
To: dime@ietf.org
Subject: RE: [Dime] Question: source of address/port to be used
forserverresponses

James,

There is always a single Diameter connection between two adjacent
entities, and answers are always sent on the connection from which the
corresponding requests has been received.

    Thanks,
    Tolga

  

  

    
-----Original Message-----
From: Parker, James [mailto:James.Parker@comverse.com]
Sent: Friday, February 23, 2007 2:14 PM
To: dime@ietf.org
Subject: [Dime] Question: source of address/port to be used for 
serverresponses


I am looking at implementing the Diameter protocol for a server, and I
    

  

  

  

  

    
cannot find a clear statement as to how to create the proper channel 
to send responses (answers).  Is the proper method:

    - Clone a response channel (e.g., by an accept() system call)?
    - Open the CER Origin-Host/port 3868
    - Open the CER Host-Realm (port 3868 if none specified)
    - Open the CER Host-IP-Address(es)/port 3868
    - Some other method

The first seems the most logical; however that could result in 
security issues if a firewall is crossed (since arbitrary ports must
    

  

  
be opened).
  

  

    
Thanks in Advance

James Parker
Distinguished Software Development Engineer Comverse, Inc.

_______________________________________________
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
  






-- 

David Frascone

           Why doesn't DOS ever say "Excellent command or filename!"





--------------090700020508020509040102--


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

--===============1814383785==--




From dime-bounces@ietf.org Sat Feb 24 00:04:33 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKp5D-0006FW-Ka; Sat, 24 Feb 2007 00:04:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKp5C-0006D0-Ha
	for dime@ietf.org; Sat, 24 Feb 2007 00:04:30 -0500
Received: from szxga01-in.huawei.com ([61.144.161.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKp5A-0001ya-Ji
	for dime@ietf.org; Sat, 24 Feb 2007 00:04:30 -0500
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JDY004E8BEI5X@szxga01-in.huawei.com> for
	dime@ietf.org; Sat, 24 Feb 2007 13:03:54 +0800 (CST)
Received: from huawei.com ([172.24.1.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JDY00MRUBEILM@szxga01-in.huawei.com> for
	dime@ietf.org; Sat, 24 Feb 2007 13:03:54 +0800 (CST)
Received: from IBM4307EA0CEF3 ([58.60.175.55])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0JDY00JDABEHG0@szxml01-in.huawei.com>; Sat,
	24 Feb 2007 13:03:54 +0800 (CST)
Date: Sat, 24 Feb 2007 13:03:51 +0800
From: Tina TSOU 
Subject: Re: [Dime] Meeting Agenda -- Update
To: Hannes Tschofenig 
Message-id: <005301c757d1$2d5d2950$6501a8c0@IBM4307EA0CEF3>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
Content-type: text/plain; format=flowed; charset=ISO-8859-1;
	reply-type=response
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <45DEB152.2020904@gmx.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi Hannes,
1) We applied "Diameter Explicit Routing", didn't we? And you said it could 
be put after WG items:P
2) Are you going to discuss on site about the handling regarding to ITU-T 
LS, and prepare an LS reply to ITU-T?

B. R.
Tina

----- Original Message ----- 
From: "Hannes Tschofenig" 
To: 
Sent: Friday, February 23, 2007 5:18 PM
Subject: [Dime] Meeting Agenda -- Update


> Hi all,
>
> I have uploaded a new version of the agenda. It still has some holes. 
> Please help me to complete the agenda.
>
> Here is the current version:
> http://www3.ietf.org/proceedings/07mar/agenda/dime.txt
>
> Ciao
> Hannes
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime 


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



From dime-bounces@ietf.org Sat Feb 24 03:40:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKsRq-0002rL-Q9; Sat, 24 Feb 2007 03:40:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKsRp-0002rD-GB
	for dime@ietf.org; Sat, 24 Feb 2007 03:40:05 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKsRm-0008H6-1C
	for dime@ietf.org; Sat, 24 Feb 2007 03:40:05 -0500
Received: (qmail invoked by alias); 24 Feb 2007 08:39:52 -0000
X-Provags-ID: V01U2FsdGVkX19S1N44l21SiPHez4LJoDgCXjVQu71UUEt7G8vOAq
	Mp1g==
Message-ID: <45DFF9D8.2040905@gmx.net>
Date: Sat, 24 Feb 2007 09:39:52 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Tina TSOU 
Subject: Re: [Dime] Meeting Agenda -- Update
References: <45DEB152.2020904@gmx.net>
	<005301c757d1$2d5d2950$6501a8c0@IBM4307EA0CEF3>
In-Reply-To: <005301c757d1$2d5d2950$6501a8c0@IBM4307EA0CEF3>
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
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 Tina,

Tina TSOU wrote:
> Hi Hannes,
> 1) We applied "Diameter Explicit Routing", didn't we? And you said it 
> could be put after WG items:P
Right. Forgot this one. Thanks for the reminder.

> 2) Are you going to discuss on site about the handling regarding to 
> ITU-T LS, and prepare an LS reply to ITU-T?
>
Sounds good to me.

Ciao
Hannes

> B. R.
> Tina
>
> ----- Original Message ----- From: "Hannes Tschofenig" 
> 
> To: 
> Sent: Friday, February 23, 2007 5:18 PM
> Subject: [Dime] Meeting Agenda -- Update
>
>
>> Hi all,
>>
>> I have uploaded a new version of the agenda. It still has some holes. 
>> Please help me to complete the agenda.
>>
>> Here is the current version:
>> http://www3.ietf.org/proceedings/07mar/agenda/dime.txt
>>
>> Ciao
>> Hannes
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime 


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



From dime-bounces@ietf.org Mon Feb 26 11:40:19 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HLitK-00026v-QB; Mon, 26 Feb 2007 11:39:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HLitJ-00026H-MT
	for dime@ietf.org; Mon, 26 Feb 2007 11:39:57 -0500
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLitG-0001qu-CU
	for dime@ietf.org; Mon, 26 Feb 2007 11:39:57 -0500
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id 500AA65853; Mon, 26 Feb 2007 11:39:41 -0500 (EST)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l1QGdY84006004;
	Mon, 26 Feb 2007 11:39:40 -0500 (EST)
From: "Tolga Asveren" 
To: "Liyaqatali" , 
Date: Mon, 26 Feb 2007 11:34:44 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <45DEB6FF.7050908@motorola.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: 
Subject: [Dime] RE: DCCA
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 Liyaqatali,

In the scenario you described, I would expect the client to report used
units only in time. It does not have the knowledge to do the translation
between time and money.

I couldn't think of a scenario, why the server would use both cc-time and
cc-time in the answer. Does anybody have any idea about that? What could be
the reason to do so?

    Thanks,
    Tolga

-----Original Message-----
From: Liyaqatali [mailto:a21917@motorola.com]
Sent: Friday, February 23, 2007 4:42 AM
To: dime@ietf.org; Tolga Asveren
Subject: DCCA



Hi

Couple of questions.
In RFC 4006, sec 5.2 which states  "If several unit types are sent in the
Answer message, the credit-control client MUST handle each unit type
separately." What does it it actual mean to handle it separately?

Suppose the client requests some units in time but the server grants both in
time and money i.e. server adds cc-time and cc-money avps in the granted
service units AVP then how is the client suppose to handle this? if client
can understand only time then? Should the client request and report used
units  in both time and money or is it fine to report in either ?

I would really appreciate if you can help me out here.

--
Regards,
Liyaqatali G Nadaf


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



From dime-bounces@ietf.org Tue Feb 27 04:08:37 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HLyK0-0000Rs-MI; Tue, 27 Feb 2007 04:08:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyJz-0000Rn-HX
	for dime@ietf.org; Tue, 27 Feb 2007 04:08:31 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLyJs-0004xI-TV
	for dime@ietf.org; Tue, 27 Feb 2007 04:08:31 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	CB6DB21C32; Tue, 27 Feb 2007 10:06:31 +0100 (CET)
X-AuditID: c1b4fb3e-af6d2bb0000007e1-6a-45e3f4977705 
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	BA1A521C21; Tue, 27 Feb 2007 10:06:31 +0100 (CET)
Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 27 Feb 2007 10:06:31 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] RE: DCCA
Date: Tue, 27 Feb 2007 10:06:29 +0100
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] RE: DCCA
Thread-Index: AcdZxRsqigffCxIIRpm1EqIbkY1ENAAiOT9A
From: "Patrik Teppo \(KA/EAB\)" 
To: "Tolga Asveren" , "Liyaqatali" ,
	
X-OriginalArrivalTime: 27 Feb 2007 09:06:31.0433 (UTC)
	FILETIME=[92735790:01C75A4E]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi all,

If the DCC client is implemented to only handle cc-time then it can't
measure money and report back USU/CC-Money.

The service-context should define which unit types that shall be used
and in the case below there is a configuration error for the specific
service-context.

BR,
Patrik=20

-----Original Message-----
From: Tolga Asveren [mailto:asveren@ulticom.com]=20
Sent: den 26 februari 2007 17:35
To: Liyaqatali; dime@ietf.org
Subject: [Dime] RE: DCCA

Hi Liyaqatali,

In the scenario you described, I would expect the client to report used
units only in time. It does not have the knowledge to do the translation
between time and money.

I couldn't think of a scenario, why the server would use both cc-time
and cc-time in the answer. Does anybody have any idea about that? What
could be the reason to do so?

    Thanks,
    Tolga

-----Original Message-----
From: Liyaqatali [mailto:a21917@motorola.com]
Sent: Friday, February 23, 2007 4:42 AM
To: dime@ietf.org; Tolga Asveren
Subject: DCCA



Hi

Couple of questions.
In RFC 4006, sec 5.2 which states  "If several unit types are sent in
the Answer message, the credit-control client MUST handle each unit type
separately." What does it it actual mean to handle it separately?

Suppose the client requests some units in time but the server grants
both in time and money i.e. server adds cc-time and cc-money avps in the
granted service units AVP then how is the client suppose to handle this?
if client can understand only time then? Should the client request and
report used units  in both time and money or is it fine to report in
either ?

I would really appreciate if you can help me out here.

--
Regards,
Liyaqatali G Nadaf


_______________________________________________
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 Feb 27 12:21:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HM612-0001li-0A; Tue, 27 Feb 2007 12:21:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HM610-0001gQ-Mm
	for dime@ietf.org; Tue, 27 Feb 2007 12:21:26 -0500
Received: from ik-out-1112.google.com ([66.249.90.177])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM60z-0001d2-EI
	for dime@ietf.org; Tue, 27 Feb 2007 12:21:26 -0500
Received: by ik-out-1112.google.com with SMTP id c30so749786ika
	for ; Tue, 27 Feb 2007 09:21:24 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=Z31QDHPWOhlvwAbnb1ZiLNRcAyPJ9Bl2kjZSLlwrtt7WyXo4ZgYRDw5XigSanSojocLxACUZl3YYhp+rxNJDjch5079TfNdM112NYrhTyoWml7k6qR/f6G4hRIxO2oMRNk4hTCNzQqLXDPytrjcfLB6V5s3RON4mzzYQXR8aIZk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=o0eh1rz3nFOS/BPYaA0uDqTc1eybd8jgq1JhxknX6LS71U4IPZ6gdMD2JPZl2NuCB2VfB9hDfKcqFkPMT1elCXnkKTtwUNguJGHlEU0O482x+rE8dDoAmqTiINWzdp5oVd8TFoTw3AAqAfpyTzzFhsAjapGoym/dI4C/9OYJnIY=
Received: by 10.115.78.1 with SMTP id f1mr1199120wal.1172596884237;
	Tue, 27 Feb 2007 09:21:24 -0800 (PST)
Received: by 10.114.241.17 with HTTP; Tue, 27 Feb 2007 09:21:23 -0800 (PST)
Message-ID: <5e2406980702270921y2481138fi4a64943b7fae8813@mail.gmail.com>
Date: Tue, 27 Feb 2007 18:21:23 +0100
From: "Julien Bournelle" 
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-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Subject: [Dime] Auth-Grace Period AVP ?
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 have a quick question concerning the Auth-Grace-Period AVP. I was wondering
if this AVP should always be present with the Authorization-Lifetime
AVP. And if it is not
 present what would happen if Authorization-Lifetime expire ?

 Thanks in advance,

 Regards,

 Julien

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



From dime-bounces@ietf.org Tue Feb 27 14:08:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HM7gg-0001MD-1J; Tue, 27 Feb 2007 14:08:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7gf-0001LE-9N
	for dime@ietf.org; Tue, 27 Feb 2007 14:08:33 -0500
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HM7gd-0007nW-8m
	for dime@ietf.org; Tue, 27 Feb 2007 14:08:33 -0500
Received: (qmail invoked by alias); 27 Feb 2007 19:08:29 -0000
X-Provags-ID: V01U2FsdGVkX19HRsgpMONHskNq/Ut2/1eBnqegeHY/K6N41WMZCm
	pMhg==
Message-ID: <45E481AB.2050608@gmx.net>
Date: Tue, 27 Feb 2007 20:08:27 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Subject: [Dime] Rechartering / Milestone 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 the updated rechartering / milestone update:

Mar 2007     Submit "Diameter API" to the IESG for consideration as an 
Informational RFC
Mar 2007     Submit "Diameter Application Design Guidelines" as a 
workigg group item
Aug 2007     Submit Revision of "Diameter Base Protocol" to the IESG for 
consideration as a Proposed Standard
Aug 2007     Submit the following two Diameter Mobility documents to the 
IESG for consideration as a Proposed Standard:
             * "Diameter Mobile IPv6: Support for Home Agent to Diameter 
Server Interaction"
             * "Diameter Mobile IPv6: Support for Network Access Server 
to Diameter Server Interaction"
Sep 2007     Submit "Diameter QoS Application" to the IESG for 
consideration as a Proposed Standard
Sep 2007     Submit "Diameter Application Design Guidelines" to the IESG 
for consideration as an Informational RFC

Comments?

Ciao
Hannes


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



From dime-bounces@ietf.org Wed Feb 28 08:48:41 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMPAb-0001Nw-K2; Wed, 28 Feb 2007 08:48:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMPAa-0001Nm-OG
	for dime@ietf.org; Wed, 28 Feb 2007 08:48:36 -0500
Received: from mail153.messagelabs.com ([216.82.253.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMPAX-0007Ui-9J
	for dime@ietf.org; Wed, 28 Feb 2007 08:48:36 -0500
X-VirusChecked: Checked
X-Env-Sender: liyaqatali@motorola.com
X-Msg-Ref: server-2.tower-153.messagelabs.com!1172670507!3699989!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.103]
Received: (qmail 13350 invoked from network); 28 Feb 2007 13:48:27 -0000
Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103)
	by server-2.tower-153.messagelabs.com with SMTP;
	28 Feb 2007 13:48:27 -0000
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233])
	by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l1SDmRWP021272
	for ; Wed, 28 Feb 2007 06:48:27 -0700 (MST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1SDmPmo014029
	for ; Wed, 28 Feb 2007 07:48:26 -0600 (CST)
Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM66.ds.mot.com with
	Microsoft SMTPSVC(6.0.3790.2709); Wed, 28 Feb 2007 21:48:24 +0800
Message-ID: <45E58905.8070600@motorola.com>
Date: Wed, 28 Feb 2007 19:22:05 +0530
From: Liyaqatali 
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: "Patrik Teppo (KA/EAB)" ,
	Tolga Asveren 
Subject: Re: [Dime] RE: DCCA
References: 
In-Reply-To: 
X-OriginalArrivalTime: 28 Feb 2007 13:48:24.0674 (UTC)
	FILETIME=[1DF0DC20:01C75B3F]
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
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="===============1724097807=="
Errors-To: dime-bounces@ietf.org

--===============1724097807==
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  






There couple of scenarios.



According to the sec 4.2.1.1 of the test suite used as a reference for
the interop
(http://tools.ietf.org/html/draft-fajardo-dime-interop-test-suite-04),
in the first test case the client is not supposed to add
Requested-Service-Unit AVP  in the initial CCR. In this case the DCCA
server can send back a CCA and have, say, more than one unit types
included in Granted-Service-Unit AVP. 



And according to RFC 4006, if the client is does not know the cost of
the service it can request in terms of service events and if the client
requests in time and if the service context at the server says that
both Money and time are the supported unit types then the server might
send back a CCA with both time and money. 



Is there something that I am missing?




Regards,
Liyaqatali G Nadaf







Patrik Teppo (KA/EAB) wrote:


  
Hi all,

If the DCC client is implemented to only handle cc-time then it can't
measure money and report back USU/CC-Money.

The service-context should define which unit types that shall be used
and in the case below there is a configuration error for the specific
service-context.

BR,
Patrik 

-----Original Message-----
From: Tolga Asveren [mailto:asveren@ulticom.com] 
Sent: den 26 februari 2007 17:35
To: Liyaqatali; dime@ietf.org
Subject: [Dime] RE: DCCA

Hi Liyaqatali,

In the scenario you described, I would expect the client to report used
units only in time. It does not have the knowledge to do the translation
between time and money.

I couldn't think of a scenario, why the server would use both cc-time
and cc-time in the answer. Does anybody have any idea about that? What
could be the reason to do so?

    Thanks,
    Tolga

-----Original Message-----
From: Liyaqatali [mailto:a21917@motorola.com]
Sent: Friday, February 23, 2007 4:42 AM
To: dime@ietf.org; Tolga Asveren
Subject: DCCA



Hi

Couple of questions.
In RFC 4006, sec 5.2 which states  "If several unit types are sent in
the Answer message, the credit-control client MUST handle each unit type
separately." What does it it actual mean to handle it separately?

Suppose the client requests some units in time but the server grants
both in time and money i.e. server adds cc-time and cc-money avps in the
granted service units AVP then how is the client suppose to handle this?
if client can understand only time then? Should the client request and
report used units  in both time and money or is it fine to report in
either ?

I would really appreciate if you can help me out here.

--
Regards,
Liyaqatali G Nadaf


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

  







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

--===============1724097807==--



From dime-bounces@ietf.org Wed Feb 28 15:51:07 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMVlL-00027L-EK; Wed, 28 Feb 2007 15:50:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMVkv-0000Ot-LQ; Wed, 28 Feb 2007 15:50:33 -0500
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HMVku-0000hS-Sc; Wed, 28 Feb 2007 15:50:33 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C95AC17652;
	Wed, 28 Feb 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HMVkQ-0004us-Hb; Wed, 28 Feb 2007 15:50:02 -0500
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, 28 Feb 2007 15:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: dime@ietf.org
Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-qos-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 Quality of Service Application
	Author(s)	: G. Zorn, et al.
	Filename	: draft-ietf-dime-diameter-qos-00.txt
	Pages		: 46
	Date		: 2007-2-28
	
   This document describes a Diameter application that performs
   Authentication, Authorization, and Accounting for Quality of Service
   (QoS) reservations.  This protocol is used by elements along the path
   of a given application flow to authenticate a reservation request,
   ensure that the reservation is authorized, and to account for
   resources consumed during the lifetime of the application flow.
   Clients that implement the Diameter QoS application contact an
   authorizing entity/application server that is located somewhere in
   the network, allowing for a wide variety of flexible deployment
   models.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-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-diameter-qos-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-diameter-qos-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-2-28144150.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dime-diameter-qos-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dime-diameter-qos-00.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-2-28144150.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--