From jouni.nospam@gmail.com Mon Jun 1 03:41:17 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550313A7142 for ; Mon, 1 Jun 2009 03:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou7c+7b8f8aS for ; Mon, 1 Jun 2009 03:41:16 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id DB1733A6BE1 for ; Mon, 1 Jun 2009 03:41:15 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id d26so123372eyd.31 for ; Mon, 01 Jun 2009 03:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=c0xpMMNJMNtIPJqjTp2u3YrZJiAcW79Rqhh7Ige5oG4=; b=LXJ5GyoaNk5B1C3BhXoZ41BfLDUnyMHZPmrfThqPZT7Ku1DFS3pfAbUYaV+bfm2RwX fktL59Cb18do8WK2jE33DbPSN/bpy/sY3LlJwPhiGYCUvN+mWlDZlGCsrmS0MrlcVtz9 a9a4paPwB8PeOwphCJ11uKP/tR/rZnj4+r9hA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=gNzQo36gz4w7yhCFSvIpq3BgrzG3QFIQrhL2Azq1SCpBZQDquig2Rw/0PWAC0vWItM rJ6HWxx9G+YquX2PyjrRy28821XWPBKbjQyXp3THIClyAlyyGmKAV9fEPLHbGGDt8dIq jCjqbByOQgXSdmiV3D1nfi+DEobuYvg/dwRts= Received: by 10.210.82.2 with SMTP id f2mr3875513ebb.18.1243852872723; Mon, 01 Jun 2009 03:41:12 -0700 (PDT) Received: from a88-112-207-49.elisa-laajakaista.fi (a88-112-207-49.elisa-laajakaista.fi [88.112.207.49]) by mx.google.com with ESMTPS id 24sm7153754eyx.23.2009.06.01.03.41.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 03:41:11 -0700 (PDT) Message-Id: <4FE159FB-7B34-4847-8E06-4BC3D7B5D1BA@gmail.com> From: jouni korhonen To: Marco Liebsch In-Reply-To: <4A1D633B.5000006@nw.neclab.eu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 1 Jun 2009 13:41:09 +0300 References: <4A1D633B.5000006@nw.neclab.eu> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Diameter PMIPv6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 10:41:17 -0000 Hi Marco, Thanks for the review. I have my responses inline. On May 27, 2009, at 6:58 PM, Marco Liebsch wrote: > Hi Jouni, all, > > please find a few thoughts about the current version of draft-ietf- > dime-pmip6-02 > attached. And sorry for the huge delay in providing comments. Hope > the comments > style is clear. Anyway, proposed changes are optional :-) Hope it > helps. > > Best regards, > marco > > Editorial for clarification: > ============================ > > 1. Introduction > > "..Dynamic assignment and downloading of PMIPv6 policy profile > information is a desirable feature to ease the deployment and network > maintenance of larger PMIPv6 deployments. " > >> you probably mean "..maintenance of larger PMIPv6 domains." Yes. >> > > --- > > "..The Diameter server in the > Mobility Service authorizer's (MSA) network may return these > parameters to the Network Access Server (NAS). " > >> you may add ".. to the Network Access Server (NAS) during access >> authentication." Sounds OK. I'll add this. >> > > -- > > "..Once the MN authenticates to the network the MAG sends.." > >> Isn't it vice versa that the network authenticates the MN? You may >> change to > "..Once the network has authenticated the MN, the MAG sends.." or > "..Once the MN has identified to the network and the network has > authenticated > the MN..." Hmm.. well you could say it as "..Once the network has authenticated the MN, the MAG sends.." I can change this as well. > > > -- > > "..The NAS functionality of the MAG may be co-located or an integral > part of the MAG.." > >> I'd consider the NAS and the MAG as functional entities, which may be > colocated on an access router. So, the proposed alternative may be > "..The NAS functionality may be colocated with the MAG function on the > network's access router.." Yes, NAS & MAG are functional entities. "The NAS functionality may be co-located with the MAG function in the network's access router." > > > -- > > 3. Solution Overview > > "..This document defines Diameter based AAA interactions between the > MAG and the HAAA, and between the LMA and the HAAA." > >> Hmm, since the extension is generic for any interface between a >> Diameter Client and > Diameter Server, I'd consider such operation also useful with a AAA > in the visited network. > So, why limiting this to the HAAA? I'd suggest to write simply AAA. > Loading profile info is anyway transparent, as the AAAvisited contacts > the AAAhome. Hmm.. eventually the AAA signaling will hit the Home AAA server where the subscription & policy profile is store. Whether the AAA signaling goes through some AAA nodes in the visited network in transparent typically. > > > -- > > 4.2 PMIP6-IPv4-Home-Address AVP > >> Would it make sense to include a BNF of this AVP as well? > Or provide a reference here to the document where the > type Address is defined. I'll add the reference here.. and all other places where rfc3588 additional types are used. > > > -- > > Section 5.1 > >> Some text as you have it at the beginning of Section 5.1 I'd > propose to have much earlier to understand what the document is about, > which problem it addresses and which protocol extensions it proposes > to solve the problem. Hmm.. right. I could move the whole Section 5 immediately after Section 3, just before going to AVP descriptions. > > > General comments: > ================ > > As the spec does not define a new application for PMIPv6 anymore, > can the text > or even the title reflect that it's in fact a Generic Extension to > Diameter > Applications for Proxy MIPv6? So far it says it's Diameter Support for > Proxy Mobile IPv6. Good point. Will add such claim there. > > > I'd be more precise and clear in 1. Introduction and the beginning of > 3. Solution Overview about what the specification does. Well, the > intro > says what PMIPv6 demands and what NAS does. Then it says that the spec > defines the Diameter support for PMIPv6 (to do what?) and that the NAS > may be colocated with the MAG.. The Intro looks very unsystematic to > me. > All this is ok if you (as reader) know the details of why and how > you're > doing this. I'd recommend that in the Intro you're precise with > describing > the problem, the existing protocols you can re-use and extend and > with what > you specify in this document to solve the problem. Then it should be > ok for > most readers to understand the rest. Right. I'll have a look at this and propose some better wording. > > > One feature of the LMA-AAA interface should be HNP delegation, where > the > LMA can request an HNP for the MN from the AAA during mobility session > authorization. As far as I remember, this was in some time ago (? > maybe not..). > Would be good to have this feature mentioned in the spec, e.g. > Section 1 and > Secion 5.2. The HNP delegation is still mentioned in Section 4.3 so it is there. But I can point it out more clearly in those sections you pointed out. Cheers, Jouni > > > > From Hannes.Tschofenig@gmx.net Mon Jun 1 03:51:28 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704A93A6AF9 for ; Mon, 1 Jun 2009 03:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huu-Wt6a4t1B for ; Mon, 1 Jun 2009 03:51:27 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 86EFC3A65A6 for ; Mon, 1 Jun 2009 03:51:27 -0700 (PDT) Received: (qmail invoked by alias); 01 Jun 2009 10:51:25 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp011) with SMTP; 01 Jun 2009 12:51:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/x2xUHMIjxB8+eOI1pbr3lpXUw/3Xtga+sxKAANh HmKf+Hjjn1KYHf From: "Hannes Tschofenig" To: Date: Mon, 1 Jun 2009 13:53:16 +0300 Message-ID: <000001c9e2a7$2c068390$0901fe0a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnipyCP8ucVjLzqSKaUt6DEX/j6ZQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [Dime] Reminder: Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 10:51:28 -0000 Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30 GMT) Take a look at the Wiki: http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim Ciao Hannes From wwwrun@core3.amsl.com Mon Jun 1 10:22:19 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2D0953A6B4E; Mon, 1 Jun 2009 10:22:19 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090601172219.2D0953A6B4E@core3.amsl.com> Date: Mon, 1 Jun 2009 10:22:19 -0700 (PDT) Cc: Internet Architecture Board , dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Quality of Service Parameters for Usage with Diameter' to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 17:22:19 -0000 The IESG has approved the following document: - 'Quality of Service Parameters for Usage with Diameter ' as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-11.txt Technical Summary This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has been sent for review to DIME, NSIS, TSVWG and RADEXT. This document is part of the solution for extending the QoSFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. Personnel David Frascone is the document shepherd for this document. Dan Romascanu is the responsible Area Director. From Hannes.Tschofenig@gmx.net Mon Jun 1 11:53:20 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04B328C17C for ; Mon, 1 Jun 2009 11:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6vbC0pB+w60 for ; Mon, 1 Jun 2009 11:53:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C6B5628C178 for ; Mon, 1 Jun 2009 11:53:19 -0700 (PDT) Received: (qmail invoked by alias); 01 Jun 2009 18:53:18 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp025) with SMTP; 01 Jun 2009 20:53:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fXBBnlV7fAA/koYO9x1SofaGmixuoQ6JxUb/FLX lBqzt3p8XzePhm From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , References: <000001c9e2a7$2c068390$0901fe0a@nsnintra.net> Date: Mon, 1 Jun 2009 21:55:05 +0300 Message-ID: <006d01c9e2ea$7d271df0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000001c9e2a7$2c068390$0901fe0a@nsnintra.net> Thread-Index: AcnipyCP8ucVjLzqSKaUt6DEX/j6ZQAQjXYg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Importance: High X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Subject: [Dime] Reminder: Virtual Interim Meeting (Important!) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 18:53:21 -0000 Folks, Dan pointed out that I made a mistake with my announcement. The virtual interim meeting is Wednesday, June 3, 2009, 8:00-9:30 EDT (12:00-13:30 GMT) Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Hannes Tschofenig >Sent: 01 June, 2009 13:53 >To: dime@ietf.org >Subject: [Dime] Reminder: Virtual Interim Meeting > >Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT >(17:00-18:30 GMT) > >Take a look at the Wiki: >http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim > > >Ciao >Hannes > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From gwz@net-zen.net Mon Jun 1 20:21:08 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196473A69BD for ; Mon, 1 Jun 2009 20:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD5+gJKJEK1d for ; Mon, 1 Jun 2009 20:21:04 -0700 (PDT) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id CE59E3A6802 for ; Mon, 1 Jun 2009 20:21:04 -0700 (PDT) Received: (qmail 4675 invoked from network); 2 Jun 2009 03:21:04 -0000 Received: from unknown (124.120.230.143) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 02 Jun 2009 03:21:03 -0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" References: <000001c9e2a7$2c068390$0901fe0a@nsnintra.net> In-Reply-To: <000001c9e2a7$2c068390$0901fe0a@nsnintra.net> Date: Tue, 2 Jun 2009 10:17:55 +0700 Organization: Network Zen Message-ID: <00b401c9e330$bbfe7280$33fb5780$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01C9E36B.685D4A80" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnipyCP8ucVjLzqSKaUt6DEX/j6ZQAiNrng Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Reminder: Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 03:21:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B5_01C9E36B.685D4A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hannes Tschofenig [mailto://Hannes.Tschofenig@gmx.net] writes: > Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30 > GMT) > > Take a look at the Wiki: > http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim The wiki says: It would be good to discuss the status of our new documents so that we can figure out how to finish them: .diameter-nat-control .capablities-update .diameter-base-protocol .diameter-cc-appl-mib Should I understand from this that draft-zorn-dime-capablities-update-01.txt should actually be draft-ietf-dime-capablities-update-00.txt? ... ~ gwz Half a loaf is better than no loafing at all. --T-Bone Slim ------=_NextPart_000_00B5_01C9E36B.685D4A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hannes Tschofenig [mailto://Hannes.T= schofenig@gmx.net] writes:

 

> Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30

> GMT)

>

> Take a look at the Wiki:

> http:= //trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim

 

The wiki = says:

 

It would be good to discuss the status of our new documents so that we can = figure out how to finish them:

 

•diameter-nat-control

•capablities-update

•diameter-base-protocol

•diameter-cc-appl-mib

 

Should I understand from this that =
draft-zorn-dime-capablities-update-01.txt should actually be =
draft-ietf-dime-capablities-update-00.txt?
&nbs=
p;

...

 

~ gwz

 

Half a loaf is better than no loafing at = all.

  --T-Bone Slim

------=_NextPart_000_00B5_01C9E36B.685D4A80-- From gwz@net-zen.net Mon Jun 1 20:26:59 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA063A6B15 for ; Mon, 1 Jun 2009 20:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyRMvyVqHg-m for ; Mon, 1 Jun 2009 20:26:56 -0700 (PDT) Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by core3.amsl.com (Postfix) with SMTP id 2896C3A6949 for ; Mon, 1 Jun 2009 20:26:56 -0700 (PDT) Received: (qmail 13788 invoked from network); 2 Jun 2009 03:26:51 -0000 Received: from unknown (124.120.230.143) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 02 Jun 2009 03:26:50 -0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" References: <000001c9e2a7$2c068390$0901fe0a@nsnintra.net> <00b401c9e330$bbfe7280$33fb5780$@net> In-Reply-To: <00b401c9e330$bbfe7280$33fb5780$@net> Date: Tue, 2 Jun 2009 10:23:42 +0700 Organization: Network Zen Message-ID: <00bf01c9e331$8a711820$9f534860$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01C9E36C.36CFF020" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnipyCP8ucVjLzqSKaUt6DEX/j6ZQAiNrngAABP53A= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Reminder: Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 03:26:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C0_01C9E36C.36CFF020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hannes Tschofenig [mailto://Hannes.Tschofenig@gmx.net] writes: > Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30 > GMT) > > Take a look at the Wiki: > http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim The Wiki says that the call begins at 8:00 AM EDT, which is also what I have on my calendar. Has the time changed? ~ gwz Nuclear power: more toxic than Britney Spears. ------=_NextPart_000_00C0_01C9E36C.36CFF020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hannes Tschofenig [mailto://Hannes.T= schofenig@gmx.net] writes:

 

> Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30

> GMT)

>

> Take a look at the Wiki:

> http:= //trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim

 

The Wiki says that the call begins at 8:00 AM EDT, which = is also what I have on my calendar.  Has the time = changed?

 

 

~ = gwz

 

Nuclear power: more toxic than Britney = Spears.

 

------=_NextPart_000_00C0_01C9E36C.36CFF020-- From gwz@net-zen.net Mon Jun 1 20:43:10 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4893A69CB for ; Mon, 1 Jun 2009 20:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnD4P00Wu0Pe for ; Mon, 1 Jun 2009 20:43:07 -0700 (PDT) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id 2779C3A695D for ; Mon, 1 Jun 2009 20:43:07 -0700 (PDT) Received: (qmail 15259 invoked from network); 2 Jun 2009 03:43:07 -0000 Received: from unknown (124.120.230.143) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 02 Jun 2009 03:43:03 -0000 From: "Glen Zorn" To: "'Glen Zorn'" , "'Hannes Tschofenig'" References: <000001c9e2a7$2c068390$0901fe0a@nsnintra.net> <00b401c9e330$bbfe7280$33fb5780$@net> <00bf01c9e331$8a711820$9f534860$@net> In-Reply-To: <00bf01c9e331$8a711820$9f534860$@net> Date: Tue, 2 Jun 2009 10:39:55 +0700 Organization: Network Zen Message-ID: <00ca01c9e333$ce9b95f0$6bd2c1d0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01C9E36E.7AFA6DF0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnipyCP8ucVjLzqSKaUt6DEX/j6ZQAiNrngAABP53AAAGWb4A== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Reminder: Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 03:43:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CB_01C9E36E.7AFA6DF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hannes Tschofenig [mailto://Hannes.Tschofenig@gmx.net] writes: > Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30 > GMT) > > Take a look at the Wiki: > http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim The Wiki says that the call begins at 8:00 AM EDT, which is also what I have on my calendar. Has the time changed? I also notice that there are no toll-free numbers listed and that there are no local numbers listed for anywhere in Asia. Call me silly, but I suspect that there might be a few more interested folks in, say, Seoul or Beijing than in Calabasas. ~ gwz Nuclear power: more toxic than Britney Spears. ------=_NextPart_000_00CB_01C9E36E.7AFA6DF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hannes Tschofenig [mailto://Hannes.T= schofenig@gmx.net] writes:

 

> Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30

> GMT)

>

> Take a look at the Wiki:

> http:= //trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim

 

The Wiki says that the call begins at 8:00 AM EDT, which = is also what I have on my calendar.  Has the time = changed?

I also notice that there are no toll-free numbers listed = and that there are no local numbers listed for anywhere in Asia.  Call = me silly, but I suspect that there might be a few more interested folks in, = say, Seoul or Beijing than in Calabasas…

 

~ = gwz

 

Nuclear power: more toxic than Britney = Spears.

 

------=_NextPart_000_00CB_01C9E36E.7AFA6DF0-- From hannes.tschofenig@nsn.com Tue Jun 2 01:47:08 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6943A6E10 for ; Tue, 2 Jun 2009 01:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7GuMt-aZTpO for ; Tue, 2 Jun 2009 01:47:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 6D7763A6CF9 for ; Tue, 2 Jun 2009 01:47:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n528l6Wo006181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Jun 2009 10:47:06 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n528l5hW024744; Tue, 2 Jun 2009 10:47:05 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 10:47:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Jun 2009 11:48:56 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45016841EE@FIESEXC015.nsn-intra.net> In-Reply-To: <00b401c9e330$bbfe7280$33fb5780$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Reminder: Virtual Interim Meeting Thread-Index: AcnipyCP8ucVjLzqSKaUt6DEX/j6ZQAiNrngAAumY7A= References: <000001c9e2a7$2c068390$0901fe0a@nsnintra.net> <00b401c9e330$bbfe7280$33fb5780$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" , "Hannes Tschofenig" X-OriginalArrivalTime: 02 Jun 2009 08:47:05.0749 (UTC) FILETIME=[B4DB9450:01C9E35E] Cc: dime@ietf.org Subject: Re: [Dime] Reminder: Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 08:47:08 -0000 Hi Glen,=20 =20 that's a good observation.=20 =20 With the May status update, see http://www.ietf.org/mail-archive/web/dime/current/msg03487.html, I stated that Dan wants to have the following two documents included in a re-charter proposal: =20 *diameter-nat-control=20 *capablities-update=20 I will have a new charter proposal ready for the call so that we can go through it and make sure that we are happy.=20 Ciao Hannes =20 =20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Glen Zorn Sent: 02 June, 2009 06:18 To: 'Hannes Tschofenig' Cc: dime@ietf.org Subject: Re: [Dime] Reminder: Virtual Interim Meeting =09 =09 Hannes Tschofenig [mailto://Hannes.Tschofenig@gmx.net] writes: =20 > Just a reminder: Wednesday, June 3, 2009, 13:00-14:30 EDT (17:00-18:30 > GMT) >=20 > Take a look at the Wiki: > http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim =20 The wiki says: =20 It would be good to discuss the status of our new documents so that we can figure out how to finish them:=20 =20 *diameter-nat-control=20 *capablities-update=20 *diameter-base-protocol=20 *diameter-cc-appl-mib=20 =20 Should I understand from this that draft-zorn-dime-capablities-update-01.txt should actually be draft-ietf-dime-capablities-update-00.txt? =20 ... =20 ~ gwz =20 Half a loaf is better than no loafing at all. --T-Bone Slim From Mark.Jones@bridgewatersystems.com Tue Jun 2 12:50:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C0D3A6CA2 for ; Tue, 2 Jun 2009 12:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_PENIS=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbPmbhtnAbFJ for ; Tue, 2 Jun 2009 12:50:36 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 378603A6C76 for ; Tue, 2 Jun 2009 12:50:35 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Tue, 2 Jun 2009 15:50:35 -0400 From: Mark Jones To: "Romascanu, Dan (Dan)" , "dime@ietf.org" Date: Tue, 2 Jun 2009 15:50:33 -0400 Thread-Topic: AD review of draft-ietf-dime-qos-attributes-11.txt Thread-Index: AcneCjORJ9rC1V8fTg6MsLb7F0ex4wFqccCQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:50:37 -0000 Hi Dan Thanks for the detailed review. Comments inline.=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Romascanu, Dan (Dan) > Sent: May 26, 2009 10:00 AM > To: dime@ietf.org > Subject: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt >=20 > Please find below my AD review of=20 > draft-ietf-dime-qos-attributes-11.txt >=20 > T are Technical comments, E are editorial.=20 >=20 > I believe that the document is in reasonable shape. Function of the > responses to the review we may decide to do a revised ID or send it to > IETF Last Call and consider the comments below as IETF LC comments.=20 > =20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 > T1. IP-Address in 4.15 and 4.16 should not include also a type AVP? > (IPv4 and IPv6) As written the specification and examples seem to deal > with IPv4 only. SO I miss something?=20 >=20 The draft is indeed intended to deal with IPv4 and IPv6. The IP-Address AVP= s in the draft are of Diameter type Address and so already contain an Addre= ss-Type indicator. > T2. Was this specification sent for review to IEEE 802.1? I=20 > believe that > it should - maybe during the IETF Last Call, especially because of the > VLAN and priority AVPs semantics. For example one of the questions to > ask is about the usage of the values 0 and 4095 for VLAN-IDs. These > usually have special semantics in IEEE 802.1 headers and I=20 > would suggest > that we get expert assessment about their usage in filters.=20 >=20 We sought out an IEEE 802.1 expert contributor (Max Reigel) and he wrote th= e VLAN sections in the draft. The VLAN sections have also been reviewed by = the WiMAX folks who are reusing the Classifier. However, we did not formall= y request a review by IEEE 802.1. > T3. In Section 5.1=20 >=20 > 0: drop > 1: shape > 2: police > 2: mark >=20 > Should be 3: mark I guess >=20 Agreed. This will be resolved in the next revision. > T4. Why is not the list of actions in 5.7 (Excess-Traffic-Action) > consistent with the list of actions in 5.1?=20 >=20 The coauthors are validating an approach to simplify the Action AVPs and im= prove consistency/readability. We will communicate a proposal shortly but d= o not expect these to impact any other sections of the draft. >=20 > E1. In section 3.3 the last sentence in the paragraph ('The lower the > numerical value of Rule-Precedence AVP, the higher the rule > precedence.') should come second in the paragraph.=20 >=20 Agreed. This will be resolved in the next revision. > E2. Under fig.1 the text speaks about one Unmanaged Terminal,=20 > while the > figure represents multiple Unmanaged Terminals.=20 >=20 Agreed. This will be resolved in the next revision. > E3. Section 4.1.4 s/both direction/both directions/ >=20 Agreed. This will be resolved in the next revision. > E4. The term ETH priority in 4.1.8.23, 4.1.8.24, and 4.1.8.25 is > slightly mis-leading. There is no such thing as Ethernet=20 > Priority, on an > Ethernet there is no priority, and tagged packets are=20 > prioritized in the > routers or switches. I suggest to drop ETH from the names and to use > either 8021 or nothing.=20 >=20 Agreed. We will drop the ETH- prefix in the next revision. > E5. in Section 5.3 - Private Enterprise Number (PEN) is a=20 > preferred term > to SMI Network Management Private Enterprise Code >=20 "SMI Network Management Private Enterprise Code" was the term used in the D= iameter Base RFC3588 (and bis) so we used it here for consistency. We can r= eplace it in the next revision if the current preference is "Private Enterp= rise Number (PEN)". > E6. The registry policies in the IANA considerations section should be > expressed in terms and with reference to RFC 5226.=20 >=20 Agreed. The next version of the draft will add RFC5226 as a reference and r= eplace: "A specification is required to add a new value to the registry." With: "The definition of new values is subject to the Specification Required p= olicy [RFC5226]." Thanks Mark From hannes.tschofenig@nsn.com Wed Jun 3 00:19:31 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14D83A68E1 for ; Wed, 3 Jun 2009 00:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.995 X-Spam-Level: X-Spam-Status: No, score=-3.995 tagged_above=-999 required=5 tests=[AWL=2.604, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRARfT2vK40S for ; Wed, 3 Jun 2009 00:19:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A4F1328C14F for ; Wed, 3 Jun 2009 00:19:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n537JIUk011957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Jun 2009 09:19:18 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n537JH5W022358 for ; Wed, 3 Jun 2009 09:19:18 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 09:19:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9E41B.9ABB6342" Date: Wed, 3 Jun 2009 10:21:08 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recharter proposal Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 03 Jun 2009 07:19:17.0336 (UTC) FILETIME=[9B0D4D80:01C9E41B] Subject: [Dime] Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:19:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E41B.9ABB6342 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 Here is the first attempt to update the charter text to include the new work items we have been talking about at the last IETF meeting.=20 Please t <> ake a look at it! Ciao Hannes =20 ------_=_NextPart_001_01C9E41B.9ABB6342 Content-Type: application/octet-stream; name="dime-recharter.pdf" Content-Transfer-Encoding: base64 Content-Description: dime-recharter.pdf Content-Disposition: attachment; filename="dime-recharter.pdf" JVBERi0xLjQKJcfsj6IKOCAwIG9iago8PC9MZW5ndGggOSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1cW3fcthF+16/Yt+72ZBmCNwB5s2u1TRu7TqqetqfpgyxFtmtZlm3Jdvvr izsGxAwBrmQ78QtDgeQAmG8u3wz27aZtWLdp9T9/cfb66O3Rtz9Nm+fvj95uRNPr/8xf4PXZ683D EzWMsQ0Tm5OLo7aRUjDzN7aR7WaSrOm7zcnro39tH+3aZurkMLLty92+a8a+E3J7uturh0Ymu377 erdnjWSyH7a/7PZ9M7JpYtsbM2Liouvg7Xe7vmFTx8ftRt8UbBTD9vFuPzTDJOSgXjw2vOPqpvta 32+vdqyZWD+K8NK25fClcYCXS/1zdzs+bc/sUD70/il9CQRwj3XhY/qp83AFRh6bkf3Uqol/srK2 vZdLTH2Qa+QSvOu9uhrlNExhEQexfYN9NY4EX/15Cz4Q5QLvyjdBT/HnnX1Ojur+Zvfvkz8d9UMz TpuTH45Ofptsrn+q7ZwIamZ+4ezGhcu4M9fZzujtjn9/k22HHgsmBgdcgFdsdl2jJqvk+ruZWNu3 6duAOK+w9YgL+jyuMvjwH/TlIAYRZqbXC+zI7U40nexY5yapX/Wdk1CJ41ZTgajfKPB5ELUSoKjj jRgsik70k2zi4zhtX9iPqJUWatUVHEauELXRdwc1+Va4bWFSzdNNaewnpaR+7GsjvOzB4zdxnNrJ SS0e6/QqdU0/WXHj6x/rserzsgPvBB+6sgJOA+Ppe/1YOOAU3mXqNh814PRNyRgxwVP0VefgGo4+ tosnuILUp/gRJ9o0CkK091p1+DCFVdRD34AB+GD3aTn0RvvUJjI+caUxZlP6dkhGfIy3wVcu7eXA Bn85WcUPz12YreGpQGdGqZRJafjIlR6dnCvduS1KSc0Jjgk6k225lgzZcnpd8d07C3edAvaTtzl7 P6M9U/izs8peYvBwDq6hCkRBvAJMXVk3MwXQQ6sVwHz4Bn+QGPICDFmCdjcq47oEbcYFBW5/E8f2 tZVAqOV3I2YqdoNDIe4evEvo7juNimlkPbRAb8FzUGWBlgWB4lMI5s0nlJhMPTaOXAlkQDHwZjAB jFEfOLakpc/wGWUbZF4GxAVLheMOR6Z97ziW4R7Ww+/g0MsAGTdfFDK3ACZeOSQnPMsVMrifoPrF zT/FdK4CPN8AFcQN/W2ug3PE5EujtRt8/X/Rsy0Jqq3u4YKeIVdvCN0mzGZqWL2/er6TTauCgi7Z 7mpXaNToGtMeKN2HBHkWOGOjtt4DZ5VTJDxENpM5cignBO9n5k0/CLwpCpRX7qYwoHFAsfNDgQI3 M+hO/HJcDNz6nyIj4d8/RmseX3oZFRJcrnnthbWvLWMEJuBgxLjnriiNCJUpoOYJFQxeX641HDMc rAu7cIv+AddMFAfwORAuh3W4ctiYGs6Yx0bR4Ks8LPNgDfh7BAa8+w24Vm/rWp1t8O33u65rhlZl ME93e6XDvJ0BCvjATLtSBwZ3irKoV+bLUg58+98dU3IKJueiqWvRCjFGbNn1Adhyi9n1wSoax/IM XL+MHukyXoK7fmLDqETpZMNaplNVr90NYqOjZ7Si/HCk/vc3Jomtyq2UER4k79Wiqy/3QiVzx+Cx EzOACRXm/343NGqNWBq2wUUtoRd3G0EJCVQVor2ZQ/DTsQao5yNhKF6lj6FG4wqEjDP185q2GNea wY/QNKgmZbWaPEtZeRpwPtQEUSd6Y6rCULf8QzsSQqXe0gB+mpppkh7wdw2MRbpi63z5ywVrk0SC TmYAwo+RIIAgtGsnhs7v+xyOi06cUoy5zkXtiquOmGatv2gCthgS1SZUXhhnd0ZmuMMcmHgWlodR MvJLBgj3kSZFKa6TaQQFjm8DuhAyBXBvlZ/1ixtdnDJnXuOhX4KyOiM6adYOX3QkeavVZpKk0GHc PiaTUR3e5PpUFU0Dv6UnfQBkXGhZhYgw5hxdsQssh0HC6ypQ/GRNoPJR2wcx6ny028uml5oG/T58 7W/x73+1kYVGxzKdEvk0nT1l8ZfBxD3waess5EoPZJaCi+DkJwmpzmOv4WNK4FEUnwGP6BrGg7tY 5Ppml+VwNq4QTClpmCUK7gQDCk7wAHmiLFPdzYFRGUPAXaO0ADe/BBzgPCl1D5fHMWT7R7wLY0Hi i6VM7xIzZBj3l2bv0AOiFOslFhatoqYgh+RBC8Ml4xPVgpVjMRsKdY3oOq/bRFyWWf8GUUb3pqCM 6g8n/6mPzbNdkiBcRgJHqHgoiYpG0CBowP1MpgK0tsDHLtCsHKQ4L0CIkm/sNHWpFTemS3Q1pquW Lan0ol5/nmPvoiiw6xQZ/h2ntXHDjVNGtcldj8XluPuAOnCOwKGK46lwMjLmwk5EYHIvQvAAQwqQ 84JLOOIjWt8rB+eoFcPdCDb/79zjIb8PKfQ+TKS6ThiziTmxXKwp1szZQ7UcMHyLs9OL5ZE88M8B YYscgzAFrSVlWpyOXpsZyZJDBFj+mSMlY8L18VEU+AZzClc4oCCOEcYMbkQRXgGcGD8LbVXOSmHz 9SLmSM1ZK6SiLnlOT2hW6y5lNzyhnFOzQN0W80maNq6pmgOnAuoi9U0E5ITNVjyIrqdAGc8S1Puj jHtem8361S7mqK5iMg7q4dHrOF7kBrO7JXYDMxt4WvCFuxoQcgMWVNz0Pz98vJF/qBupet7hlRGS wkmd/jLg6hicOeKIKA6NNHEKGMcs3IxnqMYAP4FLXFQJXBPR0j2VfxNMtxcM6qfFjRozBd+Ac+Yp mpCaHCXMRQzt6CrwHI6L8SDFTqEUNNymW+iY59KmBRS3JGjQCKAEulowSamqNR77RYV5ka+lee5J zJgfJAySLkjxBJs4uIhq/qpodp7FZlVJDEXXqFK5zTEsFZ5yz9o61DUfJCiEUW0d8Hvn6LdRg42i ZJ2V97V7JadHVEV/Q9SI3DfOSnv21UjSjmcDD6IPgIE/kb9DmS5QFYqKhbSmres+QTN3gjyN9b3f xZtA35FvjHP69BT1SJWtXWQJzEexGKUDwq2n6u6olFZKwHPmrEwht6v06OuiQ7uGEwHXO7UTVGoC 5OZSBzivGqaJW7RQaNELDiB623B3i1sghCGVGGCXSzPFaJYiaOMyA0fmSMFR7fow5KQg0elEsFG1 7LjZp+qeJpEWxfAVx8hyNynghN12Mpa00gEkwEbUvLVHkiTGQpzhWnsQ0gHPKUupxMsYnJLqW2Ys vd17FDoJDmo5z9i+r5bopKYwWNDYbZOqr/97or3W9/YNb0MWWK7y4PuFki04Pggw4dQOlU4QhWu0 SGonCGCRpRpG/6G7z60nCRZcq7HuAbyPtqI6uswSFiueKJ+aOByuoqaeiyQSsBKwlooJ1vIhy9lM he4fXmBdq2UeLDcYF0iR9jguPqB3CSbUL6OYGZYsEFvoMv0Ii7sIGDLOMNtRo9/wGu9uu1sUI0CN zaZ7Xzea67c/xrgWCoy0FgwJ/5Pb+vRjFSc1MK+W039ZoyBSdZwXHvCIaU1BjarM4mEWMtM1lASB Q2KxbSSnzApbDuQ+D5VIuRsr0Bck5SvO7uAECmXB8fSV4ABp2Oj0TZ+Nc6MnKcgi0uGp8wG+Y3kv l8lKxCQjHNG8UpVOKjCTQG575GMU2oN7bl4IjtWfDneDK09VIGlXxUovMZwzztBOESCFKLoS9Ex2 aZSwnFoQCbqaUGwcd93a+rixPjTbUc1NN5ipXc1SPI0+JjbqwdAU9DQdTPLfq8eqtJ15LoiAm7Bl i/0kZjBiFWAfH2ihjtH0L0vBQkX2nyeYa5uSEI1KWhIt/FVEzkLTUiHbLB/Pwu9invne2Zn1scbM StiVKLajZGHILI8rMRY1/a+rjsCiqdaqRgQPEKIRLDsmqJ3tYTwiTp3MFA7tk0n56RLgqozpjLGI 7G8aMQQ36gTvJWdRrXzzn3oJC260MnqQfTeQ0YMt4k4tzGOLWubnEg9WPTasFu86BiYIzn/Ex92J IeL4rJsg3iAL8YFXnCj+A+3pTsjhnNQ7+CQ4aRBrot9ElZAeb/BRHBslw+D2TH83C6ONn1msQy4V mImGn0LkedgRpHjCzp8y7wv+JTmMVNGuUBdipsF3VX/QkgueST4r/dlJfsFUDNTaMFwQhpzIrMDL KPsNnsQL2Gks6KkOSPPB0SUqPj+8aPp6a+IEXF1wxiDxI6VXFN0WoX15Z11K6/tOj1AkoqPN3Plh Qh8Wb64EVF1q4KM13bQxJk0cQznQeoemMIsuZZbjoxWdvJ0lP1G0fHQo9TT+C4ewg+FYOqQuigng XTzN/Ldrgi7hrRvFZqqABIKdqDuK4wL4cOAotbzWkUi91x4jFHGI10wJt1fxAwurHCbsdV7R5d9g HsXOtrqZ5LMS1r/KhF4MqRMLM4RDn+W7PaY/I5FqiQ9eAi/zxSxk0peWJcXr+tKQXykpBYYg5Sqs 36zGihoF9JcYIOc3pXDLO/hLDdlJpSn7vZIizfXJUXBj77d6Vn2sX4+ZPqHno+IhJCAZtR5YEWYp vwkW/K4/dZXDPLGcX6nksaD/9WWFOBOdqcE3vwg0GIuHust6SJHZhcaNVzAW3DO1c0IpXrA2dSez M9qKpSez8e6BD+hd4kDVNTol6mRE4fjpakLrj1HT/xK7af+MnlX9Z2izgW/IziBnjH31ebq0QTb/ WY2V9G0psijSnFHK8Nqcooqqb5qAwbdS2tUXNlvhemJtnLH396rjjycx/sg6BPTNzxM+I7HK52uV 9IK+ATktbtzusbv818LqRCew/MMyT4JKxR+FAb22MGmHj5WPZGDH3mgKJw8ovvShqjyoPz7Z/Hik //0fl7O/6mVuZHN0cmVhbQplbmRvYmoKOSAwIG9iagozNTg3CmVuZG9iagoxNyAwIG9iago8PC9M ZW5ndGggMTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXct2HLcR3c9XzE4z OZ5O49mAd5boOPGxHFNmThY6WdAiaSmmJCshJecz8sfBG4XuQvc8mhzRobgQOIPGs+reqkKh+WHZ NoQuW/sTC6/eLj4sPixVw+w/9xEsv3q7fHq2+OMLwpbmgbOrRdtorVrtviRL3S67Vjfmm7eLl6uz 9ca0Kzsh5Oq1LWvRtVSt3qw3tBFM6G717/WGNB2XYrW0FXinaKtWP69100pKyOpfa9owqVu2eu8b kJx0q1tQ/hWUYRuf1m0jKRW0S/0xuboeFlXZ9/maNUR0SsO6eZjvK929So/BGu9A+cK0YX7pzGLA 8ecHb3J/lYnApv3KdGr1y3BEmjNSHQesAz+/TAPxPRLWclvZDJprJVcn+dOwoFLA5Xq73jBTk4GG zIyIqSgEbD0NHA7kfP2Ps28XVGgja8KI0tmFkZ9fK9t8nbsHI8kLed5f0l7N2soMhNENza8G6wRs AjT8urK2lSp+IYTtw055E+e8IaxRft55/FAOwvprIqACTa1/lKj++luVipvbMdDMxKLbtoA+jSx6 r+aEOLopXkFtj8rixmtwQ+yob7mxN0EMuQjIYkHoFtMlsMPv8ggCHHW02N/vsz58lYsB86QBzFKe ohrldcLFbUxsZMtYkBsqSGO+iKpyhcwgzSp3BBqHfeKCfTkUrQY85BtQrVJAlv2gkiybL87+ufC/ fbc4+8PLuFRWii8AJcAykO6bXASf1nYche7rvPn/WROzkYro1RdAkqBUfZWxFi/CymZZqVlXxRVo ebDWXvk2slGSGBkOS0mKbYGtZvXM6/9hyH1KSZbWxOxA2uzLPnj0dxiuGLrbqan3JRREdUBq5pX/ CTwDOsUhG3SfVzDKt2mG6CjflfHX+C4N7KJQobQLKAfd4AwRN4ezghknuXioK76NpCt+ggD3a/bS YEuBXeA0aTgWKz+/DLfCCmMN2CIV5A93M756OjVklutpMhggLZgpYGDbBFAvhIHdc6MM3OkSdwGG A0vni3ITI4h/Qm2ha7Q4bW/l0kU5k9hdVTK9phgBapPRlBv7OAaNtq1btAKKCagA+35RwyUKmaRJ s3mxN1FyVMYZJ+s3Ga4vYWt9yOpZF6iUwf5yY79l+UftI9wi3MKSwfH8HG34oiKyI+gviOYY+nuq 33SNFISxyp59RAUPs3ugJRGN98NN6xJnndgy1XCSxPb1lCxubVr3qQ9iVI3aUvk9up9VBR3oRJgU 0Imh4Elo1gzkzmnBTnIH5QdUx8VxFwTCP20qttOz9YY3VBFVjhTnJthgyU1J1Ld0KJwqYMvR4+vd nDc46klpg9ZEhOy/rI3yMCX16mvgEZy5CkQZ9+9Pa95ornjpVHwKkC6ajqqoG5OmxhZuSxxXn917 ulAj96EwFUzgh1tjAtTKh6LTI4CoG2OrHfzX1MSP641o2s4Kzkk21/+ai7g6bB0l6tHJLbo2wMK8 AJKM2CR9fY4yIA1hTlER6rni2FcRXSAvudlmsLHmvyc21keWRKVYH8mhPiFFDPV949wa4wol1SGa WuMvl8NKOr+YNGZ/vTtlRIYIxVNV82PmbfxIYvwas4yxBKo+t0jDpdJJq5ltnjeEyzZQuRFxETpS rYMQ07pZKErTAMueLm37gnQ8jk9yufoyPOalza7JWOhTMO5X42RgmjvRhqpQGKG01WZCpU4s18ZD sD1+fbY8XZwuPiyMWLVLLni7fGvKkvnydShzKl3Z1vHl14u/L9/tH8slIs3Iu/FpIAc0yfIiAY2F Eg0dyBR3wO1+CEVPDK7JjtNC/VEDca84WdqW57aq2UFNC/2ddnsBNhQ0QWnDW0lWP/jlaA0yQ2NN gvKXuDX0Y36yBt81EyfBR8XQusI4AnWe/4x7xshig9kDn+tnFOvfeTrs2kZ1XaTDuFuqGjjDkNVW 2S+EPRIhGW6DVDRGGoxpkmt+BNYK8nXS9k2cLCDTYEsoWnOEBpENK7Xn+UP0jGELyzIrFVS1cQrr s1zVQI8Bgjw7aCkBof4GPY64yi7PpHBOB4sHBrcU/eDRSNBrf1+oEg0eBovhQwAqgBHnnSptbD+F HaDs4dn00eUG05maV3ueAtb9YJxmTqCctLOWNa22UTAZpf0A8hQtaTgTM1KLFeZHajkutXy/3uiG GbEu19XJu2ZR1svQ7PDwqHZMCjgow8SrvKKXiIbiJzdgsRC0KCMwe0aiE0lQbUiiCB7frWwCjcKq fqyfDvQOGqtcNnJQPMZkW2LugMm2NRm2CTWN+/xbMNm2mrAjj8UlvfC6wjvzKxvGie+D0JDvpxlt GmRsH6YTGeXO8c0FMLWAyoTpA5UBQn2DqcwotfVEPH6v3Ja5HqWpRVs5E7dNOYbMNBodQ1cOjiFT LYmOYSjP4Bhyoed2DEOT+zmGShybvQGPGGkmZgZKawAJT2xdxrnSVYABvHVPELQHG+9vS291flwi T0Swsivk1Gs/CAqjNrYFwRdxmE/SqYF5YT9LsrMHhjqgyuZyMOy4OzBL6DU8bHuR4+0+lmw0Bgbh kUDtPSOSlClU5coRkQRPoapQngORqGpmD1alRucMV5WodJpRCT+PxROvwDkpTJ3IPbwfiG7FpvP2 6tAghQZrkWaHmMYVLu8TZbdLsGU4IlydJ6ErqvXfMvTlloBtmY9GUGit5AF6MKKNlsm0qh0qzRd+ SqGP49q1luVsaL8glQxZflEAZBX5fb296kvnHjxj9aIWs3Er1hKy7bHi6CnrrEZu5JKjB2tKRUWO fGupTAitgDS/W0AlQcVoCYYU1GhBt7Cs16LtcQwx1MF466xeopQvX4cy1c7qdXV8+VCOYcZ/oMa0 7uwcZ6QZznOjL7fi1TBnx6Vhzq4c5uzqzDNn51fMPWHB4ITnPQb6b8ISYB7hKVFoqsSOQDAk2Z61 3Pc+huDfzwzd7/DhqZ8tq4DTJFOjXneFRnBkvs7Wepi0rLoxI6QU2yhJyccvdKNYOgW6D6cndjD/ +YE9/M4m/002+d/kYuQGVTgKMKLhFwRNu5hKRoOf/pBVEE/5PDRDqhdBPCjY0qOm43s5FiQjGtty ROOWZS/Hl+dAY9n5lItZ0Tg2endezt3GXk7xw2eAAGXEP50n3PcNo88xDI3CYfXyTYgBxSw1LVOK /gM+Ws0ui58RQNQHhY39zMqjgyNVOpmqrhzAkXYqmaqhPAc4MtnI2cExNvpQwfGgM9wUaDj4FBdi URkrxzD6RbZns+xthvAAZzSJkZWbT3hwa38IijdZtSH9tkCR2SztWBnnk6nwxIn5VDe2qUwVIfmg 5V2xUxAb/YwANo7eTB6/gZQ+rlxBwlrb9QY4roLIrcbjw6TMSZ2uHGFS5KTOUJ4DJtv5QbJ90BDZ iwzDE2XwlOIyQxBIShkdxejB04DQxyGwMDwBCkBBjubN07VoOiZbMREPGOmd8Ia1FEbDkXuoPYit XDX2WZy8UTyd2IHp1RQbB94aeuQESt8PACpwKnaNSU+WCiBcV9iHh993zytUgPfwuiTuwZ94uZOS DMHbZo6V4I1dWNzxNskIUrvrJEhjOwD1btfPjw/UTGV71pYjUNMu27O+PANQ007Mf6SZGn2oYD1l S/1md9RM21gyxcloFNkD0ixRZ3s6yzI607Nba4jCp8c+ZYIK03RpDrtpvMdtM6h8E79Q/r3ukh2g +sXbJhgzQM/myh2eVH3Ks+rbclR9wrLq+/Icqi/U/K5savQxm2HrbAbgqt6gsordof6pogWoiO+Z 1bBLVgGxN9so2SmvwB+5CCNEvRwrqZU4cshy28zZfFLi5gEswpmzC/KdmztNLpg+wzk4g/YY6QWf V0oB0bqNKQWuHFIKiOpkTCkI5XlSCiidPaEgNLlVOkGcryWzOF9XDvN1deaZr6PR2ZMJ0mQfpj0L GGbX46gZgpUoj2DkBFrLdl+vrYjLAK3hRkye/+DzxF9ZAYBr6Eij78wJab4+PMsNyaRYxG5UFQ3+ u6GqMLLfIVfFEEcOTT3LMaDKOQCcBB4Zv8W0ezLmf/RIAulYcidcOaKu6S+hri/PgLpEd/NHElKj DxV5f2+RhPs3ylOIYeC6uJyBEus88Cqj+3yJXNuYOckquTL3dqstvJ0zI7mf6mMywVyQyVU2VG05 QiaT2VD15TkgU8r5815Tow8VMh9Pyh5Pyo58UpZkcab3kBiKF6TrPuurk2Dkw9DmfV/b9i8akUZ7 aC2/ZcD+n/HlFuRkgWojbwbDAa+hL0CALzHdPfpUPBtfXbINDxp0Tzxoy5EHzb/Eg748Bw+anZ49 4zg1+lB58DGp7v8tqe5OnCtNFMY2zDxVuVM5SMJ7vFP5MO9UbudOfZuNbHjoAd2pCeIZkFCPeKQh HulPT+7m9Vljf2Nm8DcVivQmFw/pGJLt4F6RD7QpCzb+Hmn4Mqot/yLNcU44jTscrRAvBP6vZlTE IJroujtUCpRZa5v7eydScJ/v5wTeZuWvsoBNeYZ7VhVKQ0mm8qL/Aw51qm7T1neMvA/ZGTDpn91v czHmJK9gDkk+d3rTUUpGEo62SjF0pzB3/8JqJMnI3qkENy3zWziDxNEuvuQ3GLmni/8BRG1vO2Vu ZHN0cmVhbQplbmRvYmoKMTggMCBvYmoKMzQzMwplbmRvYmoKMjEgMCBvYmoKPDwvTGVuZ3RoIDIy IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic3ZjNbtw2EMfv+xS6VTqIJYffx7pJ iwZIEKdb9BD04Nhx09Zrx67bPkfzxBlSIjlaUbax2E3txkAw4JKc4fA/P5K6bjgT0PDwl4zTzep6 dd04JsO/2ETt001ztF59/UbIBgesz1ecee+4jz+KxvPGcsuMatab1dv2RdcLwazRpv2r67Grthxc e9H1wLTU3rZNaFbWAXctkC58bhslbOtH21kXxjoAxlWcRnPBlNTtj2gyboVXyWcc+I7Ym66XTHnZ /jYGIk17W8wUk5K+/arzzFgFqn3WcWYANFg67KSTTGjrfJn0fW4ic5bGmw6YNJ7Lydq/7XrFwEk0 y5QfMX0YtNXUD13IGIjROafBJK231dYSzJ/ogVlldArGKynan+JSheQqhJC9nRH7ZHuR03lL2pq4 BuUdXQN1+8v6xQqMYhwUSmh9hrJ51vWeSW+dbH/oBKbLGd++DH5QDx7a5yEQYQyKchL3P2XcFYl1 yDgK5o966i5J868YODdggQZeGuNUGISeOKA6owmjsdU35f22fLRwY076lJReGOaGxLwaNsaL7D8W yN/EvqegYlzTgtKcB3/P183x6hiLXwhlG+3wvw3azg32xWhbBMHF2GewP6x+bi53R4aQkRdYEcxF bOAS1r+XcHafWNFZ3x6GESHNo9jNtPWL8SLLu4w5qwsd58dq0lpPpUnmoqqmZUEkm93RvoQ+dOZv 6iD5WB9JIj3NS5mBRjtNey5FTMN4GddtAQThyVFZNaXVgCPOuLYJR7d1b9QD6fKBdCk7QmhSQqAc GyXJETLfl6xRH+ck8elYyJvRdKD5gA0tGJcesSETNko2l7JVgEy0elZdSdHjfGtwEBl/z9ZEHdfP hNnvXm/PAJxpYS3JJu1wXhPpTdcjarTAbOfiq55jD5BXGbcg/TdFXt91innlFKRKA4AEeYPTADf/ EeS1hwz5YCfI49QZ8oO9J8hjYcH+IZ9nPRDkw0Xw3yz7w4L9qNPMSsP1VmmM1+gJUbLYXhd4VPG8 QLA6FxYEfRdEg6A/FRRVuVhBZ0zsF0bnwHeLIoLE95ta5DswMyxhyswei9oIvC1mF7vyhoY2Y6Yw Yt7BcEzN5XhUTA8IFw4PekCMeXWQB6DUzrM+55fp0LrM0AeeAzOGbl+sRoYK3PmBoVjMj46hUpaL crATQwHKRXmw98RQ8OP7eq8MzbP+Dxi69JiuKO9d0fvjfEzjzWcHsh74UpouyThdgujCjesJkjWC s76X5ff0RsfLtqIkfV0K5qbKT6qBq+qa5884Z6e4IlV5W6uey3t1VmKb+ljiKfmQN3PzEJpGW1TI Oi7NmHiOPf3veK/KJyjy+F1PP1ilontaD+8H1FPYzU8DHazHJ7RMdHg05Ko/p6vASg72wqupahKu IkrGxSqh0vBgXuWb2+jJOSPpLU5o5iVQ9tz1lg41cELTlxV7EGJtP/P3RSzr7gYW5sSEZEyuRser z8TzHQxlbmRzdHJlYW0KZW5kb2JqCjIyIDAgb2JqCjExMTEKZW5kb2JqCjcgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE0IDAgUgovRm9udCAxNSAw IFIKPj4KL0NvbnRlbnRzIDggMCBSCj4+CmVuZG9iagoxNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDE5IDAgUgo+PgovQ29udGVudHMgMTcgMCBSCj4+CmVu ZG9iagoyMCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDIz IDAgUgo+PgovQ29udGVudHMgMjEgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdl cyAvS2lkcyBbCjcgMCBSCjE2IDAgUgoyMCAwIFIKXSAvQ291bnQgMwovUm90YXRlIDA+PgplbmRv YmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgo+PgplbmRvYmoKNiAwIG9i ago8PC9UeXBlL0V4dEdTdGF0ZS9OYW1lL1I2L1RSL0lkZW50aXR5L0JHIDQgMCBSL1VDUiA1IDAg Ui9PUE0gMS9TTSAwLjAyPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1I2CjYgMCBSPj4KZW5kb2JqCjE1 IDAgb2JqCjw8L1IxMQoxMSAwIFIvUjEzCjEzIDAgUj4+CmVuZG9iago1IDAgb2JqCjw8L0ZpbHRl ci9GbGF0ZURlY29kZQovRnVuY3Rpb25UeXBlIDAKL0RvbWFpblswCjFdCi9SYW5nZVstMQoxXQov Qml0c1BlclNhbXBsZSA4Ci9TaXplWzI1Nl0vTGVuZ3RoIDEyPj5zdHJlYW0KeJxraBjZAABEwIAB CmVuZHN0cmVhbQplbmRvYmoKNCAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0Z1bmN0aW9u VHlwZSAwCi9Eb21haW5bMAoxXQovUmFuZ2VbMAoxXQovQml0c1BlclNhbXBsZSA4Ci9TaXplWzI1 Nl0vTGVuZ3RoIDEyPj5zdHJlYW0KeJxjYBjZAAABAAABCmVuZHN0cmVhbQplbmRvYmoKMTkgMCBv YmoKPDwvUjExCjExIDAgUi9SMTMKMTMgMCBSPj4KZW5kb2JqCjIzIDAgb2JqCjw8L1IxMwoxMyAw IFI+PgplbmRvYmoKMjQgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAyNSAwIFI+PnN0cmVhbQp4nJ1Xe1hTV7Y/Ec05Rcq0pLlCweS001K8etHeVi299Vqt T6qAj4oVAuRxAokhieeEl4QkBALoljcESJRAEsgUA4K8UYt9WAf18zpaO/067cy1D3Vqp9MZO3cf uvnj7kA7ne+b/yZ/nXPWb6+111q/9YiAWLyIEAgE4ZtSNuHfym1rQm//zscK+LhF/PIwgBQ/aGaT l/CSCAJEhIGIxd64R/8SNZv4OA9/wX/y2MLxWkGvYELAJ7yxN33FypWrXjMYS1hNbp6Jfj4pKYlW lNA/SugtDKfJ1dPx+KGQ0RmM+YzelEjvYxjalMfQao2OodPe2Lxr52t0wiadXKXS6OltLJamFSh0 GiW9S6Nk9ByzglYbWFq38EIrDXqVxqQx6LlEehNHy2nOyCg1ch3NFCsZY0iwijYybL6G4/AzreHo XFauNzEq2mSgNXqlrkAVMo+/qw16E21kDViejyVYVZqBM3FKVmM00dhi2pZtC3c05clNIbucBotp gxojVQZlQcibv8tMco2eo01MsSlkR8HQKg1n1MlLsF2syshq5q9QwGn0uT9bX0WzTK6cVekYbl5v KCo/+0f/g9dyo1FXMn/WMI/6u32NiWN06sQUTb6igKP3GvLlejrFkETvonczKk1B/j8Lfk7Xv5ZA giBi9crdBpWR2aLeyuZy202agsM6eXF+esIK+mWCSCW2EIlEGrGV2ENsI54lthPxxD5iB7GfSCDe IJKJA8QuYjexmXiTSCFeIh4hwgkBEUvEYWYRi4kS4teCtQKz4G+LShd9GpYc1r84frF9yatLLgo3 C8uFH5LryGHyLlX6SPQjM+H7wt3hX4TfXRoL6yL5i8DHR13P9UXdhlIogdJlogmYx8vFaB8nHK9s KQdyCk2RQF5hz7JTHHT4SHWD1QUGKeghQX1Ta2sLJfrY2+1r88YOnDTuk6IqEqgtpZpqDLb6SFVd eRsYpWA9eefAu0mpMkOaWhLJp5Vd52P6BH74VBi/BgrEavmRMgWgXtz/OYz76+kr025Xha1R2mAH AMhPHDplGgTUaI/v7MyOcy+guOeeQs8gyVcJ8LGP3+u7fUka+cMW4J8V+gXfj/IBuDps9mX+b+K5 RhLsK7O+Wkmx8H/95IbWcie4SfEpJLjlcn3YQPlRA4ky53Qok9ctQY2s8EOH2wLSqTkDCVIt1g0V +JzFTyY1FneC2xSvJWHD3N0lvcJIvqasj98Quvtz8Hn4XBis5/PFSJTwNIpDv/z6GbgMih88xKGk Vz5EYukJnfhS5370EkosSt+TVvQ2jIdbTk3PSHHcy94r8PLh78Htvig/TIDrQ6E3w3sW8WS7v2Gm aaY52kvK6iztOHr8LXSYI69XtVQCGYVeJ3Mm890yQKFFSTR6VioKorjfJnx/Mei+MCWpuSwGjvKj VkuRqdBWAKgD7GUoguLeDy4F+zimI2QYybsKfRyUW97lw9/Hif8I33YdTFgm2v4PiW8NJX7uGAkU FfaMCkr0Sw72kCJ3F5lSd9QDrlPwKfJcZo9lHFBw8e8e4vtLX/0ahaXlmvbopKLYWpkYNLW429o9 3d62bkBN+1LRMvSYIW2vVu8dMktDDLgFUwfhi30CPh4+LlYe0pXkABXQnyocKDldEay+QcEGoeMP 5qnDQ9qzMs9+7O3j6xNQPIr/bCV87NPzp+9fkyIX3CiugxGnhs+DAOgsbdY1FNcaag9SZjJyVg38 7AD/sJ/1R32D3WuFm5eJTnxzVwyy2aI9xyiRjoU3SKiDz2DSK6EC0fBxVCpFl4SiOJa86ug041CL dHCdV+z1tJ299bZ2W7+k90DHZrAerCpaezhLI8swJQMqy9I+IY2Ed3AVLR+HGX2Cm1AadpNfK0Z3 SJBjs8qqcB30+cittdY2cI2C1z8ffxFGku+6ugdOOSut1TWVjnKJ3VxtA+WUrofrH/T7Bz9IG1m/ I53LNkoK8ioVYC21N1sYObsaO9THw5BDD+G6ZaIE/qvZl8Rzt4Widpa8Ud1ZCg5Sc8UkSC+zbcIJ y2P5z8hhqFpiEOp2FBly9TL1/tKNgHq9uH1MCqtIKAAjqjZEUT3w7hGhGQlVuYg4QUEzOdTeMg3X n9egGL/Ejwmfhn173lfhifp9iKI3oD5Ekj2ccMzhtADlfHdQlNuyK7CjnT4ypd7aDmYouIecDowF m1sqS52STqPL3gOowZ7AWalozYQmmPkmY9yRiRtBDVKchpEw4vNeqLto74sKfPEKXA6jYaz6k2Wi KIIv5J8WX0T/Roq+JtzZhkZlLFq6fucqTbvWa5B2c52WqaJXjEoGpAPFqZKrJkr0jW2XXcsqntzz kQZGwZe/mP72492Tz0qShf9V1BR4K9A9LJ04PgX8jf2eGNFviIke78jFJ8Gw9S1DgPrvuQNi0Ye2 d3qOamX7jyS8IPOOdzU5A16paCXxJW8XT3UyiYnFuZkZJWfu/7FzcAqTOKasn38pKOj9M5Q8CIP3 4Sdi+GwB6TA7qqzAAcprSxu0TlM9rsI1O3ev3zki+y5H+j/5ARYcplT5R7K2yiY+L5QYUJJf6Oxq bGoBDaD5WGt1r/WiLQCou1dmvrqpGksYlW7/lcEP+qlgwD/U02sr7JZ0FTlLXNlU5GxncXA2OigY hFvhNFwTNlsNh8XoASu8U+WygTeop8mD+oIdu+SdY1pJ9nuFdwCMoCBzBYbBRyfHSphxyRjj1Qxs pPzQYhSW5dlsxcAOzPUFrWm+DGcGrrgMtAIlIgVSwHj0DFT/FQp8Q1elUISbqLPto2YK8956E/4w LriFSQ8vYV78B9zAClPWKrOS91PGafQxmTymvHF9+K3PRiSss4gpLSsEMQbbyWEpfOePZCTsm6fW R3B11GW4GsWH+HUfqkL82o+bkL3FDhQL/KqskNkwvyp8ZF6DtQMMUaLvtvL/J87Jy5NnBbXj4/3B 8THNQM58X72m8/ISX9S1n+ZZMXxgEY+5fPXXmmaacFPNrsUMHaPgHJJx5IXqNivIodAZUjSh1Rba DLEKs+dtKbyH0jhypKLZHpp/DeQLF9J/Pz3gvnBJMj8xZymf4DfYZ741dFetSeg81nq87rivxlkJ LMBeXmKzoSfQE9H8ayiVI/trOo4ChpprIoHKXKKtWXAks6mqEUxRUEh6fV+jJ0+yTVZQEQOsZQ7D cYyw+EgbqKqzt6EDsCv6z9/3nLoSCnjfgvHroYArcP2jvZxwoMZdAtTz+tVHizQ/6teeKO0Ew1Ro YHn47afxkInHlSZBy+FyXMV8/lVxeXlNTc3xKhBTVtnilsIO8g8bL6JItGTjwVcVPnZkOODr73C0 W90Se2tNI2ikugLuAYno/qUeY4p0M4mW5h4qUrM5+YUaHMCUqayr7096LrwrcR7sLj4PxkCfe2gE pwmlvy826oqsHKDyC3uHL42O/q4Lp6kGePgkj4Av9olLGyrrK50oARZHfwejOr0eZ19DjA+9wpEt x5uP1wHv8WYHMANz+VHDYYfDXGwudDRVN9bUHx49MgbaQVtHY/AE5UN1HNlT3VjlyYdPoDej9Wqj 1l62b1PRUfUxHI8NPjK3tqwJuICrZ3RosrauqbmppVN/km20e7WtxcAairsuhHTg2XH7p53o5gKH Fnh0Hip/Go8Op/UnZtoWOl9liJm2EDNDe1Gju7O9lRJ96u462XQy9qzLlDq/FylsFnXNQm7z6vES tQBuCIG7T2IkoIZcXNo8VG6zMiGoHa9Qtba2EF8XVqi9jOn1dEn+lTzfLrALyIxMKhX5g9ns4Xd6 4AGPAP8NwaRIZoXv1LjKgQ5YjpmrytBi9CAaEfDL8tPVLtASA3yulvG6WtxwGk/gTegaS44c89id 3MDKaBSOfo0ieKLKfaw5hPxVW8t0PcZMseSoo9V+8hDMm/s2OiCEKfwRuHHuCF6JYCb/bfuwtytY F4Mbwuw6j2ASLgmDH8wmi3drDYUqxbrVMrQUIDFY4//PcxsnXxtT/imNCpB7z7A9hRP5M2X3AFwO oKTju8DlrnFfz+Vh6kc9cDNW1IteEc8EA11DI3fuTcKlAD4B7rFfZvxWditneMUHlIF8X+1nu7Le 2t2RCFAcQJKyeENqUTZ7JFWJ9dRhVRa4AS9rGwTwZbhGLGNUWRln1FPnhgYnp5izmVJ4Y7GMYbIO nVGfmxoawt+GMqWRRR5e7oHpHmEwHNJLg8GICEh7Ix4liP8HlYuGcQplbmRzdHJlYW0KZW5kb2Jq CjI1IDAgb2JqCjMxNTIKZW5kb2JqCjI2IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGggMjcgMCBSPj5zdHJlYW0KeJydeHlck1fW/xMDeZ7WtaQpidokbbXu 1q0V1NYNra2ogIgsImuAQCCBBEggKyRsFwIkBEKAhEV2ZBUQ9w2XjtXWVqvd1JnuO21n7sNc5n1/ Nzjv9P38Zv56+eQPkruce8/5nu/5nssgPGYQDAbjab/92/Hfit1r3d+W0wsY9MIZ9PPMPJT2d5/J rZ40fxYBZjHBLI/Ghc+f95p0PjP5/Fz6k3lPlpcx2hljjMmlh4IOL1uxYuVOqUyVIU5MUgjX+vr6 CmNVwn+OCP1EcnFimvBl/E+WSCKVpYrSFKuFB0UioSJJJEwQS0TCgEM7/N/aKVy6XRITHy9OE+7O wKMBmbEScZzQXxwnSpOLlgkTpBlCyZMvwjhpWrxYIZamyVcLt8uFMUK5TBQnjpEIRco4kcw9sFIo E2WkiuVy/L9QLBcmZsSkKUTxQoVUKE6Lk2TGu83j3xOkaQqhLEOKx1PxCN4qQCpXyOMyxDKFEFsM 8Nv95IyKpBiF265cjIeF0gQ8M14al+m+zb/GFDHiNLlQIVIq3HZiRcJ4sVwmiVFhu3grWYZ4+giZ cnFa4h/WVwozRIkxGfESkXx6X7dX/rif8H/dOkYmk6im10qnZ/3LvlghF0kSVu8Xp8ZmyoVB0tSY NOF+qa/QXxgkSsyUxGT8+8gf8fq/RZAgiG3bVWlxoft25Ejjw/bvlIkO+KUnBOzKSAzcLU8KelMh PrgnM/itrJRDb2dLYvYqU2MPr12yzrJ02WvClat8V296pXINQbxIhBMHCD/Cl1hNvEREEAHELmIT 8QqxiAgkdhNriMVEEPEmsZZ4mThI7CHWEUuIYOItYj2xlDhEvE1sIJYRIcSrxHLiMOFPvEasIEKJ fcQOYiURRuwndhI+hBeRRLAJiniKeJrwJhjEbGIOMZ+YSywg5hHbiWeI7RjJhAchIr5kHGb0zdgz Y5gZxqxnfuOR6PGJ59ueF1g7WE3k82QNNZeSUF88JX3q1tOtM1+beWzW5lkDszfPfmfOqjlg7sq5 zfPY86Ln1c2besbqxfTa6/WYzWdfePbAsw84xZwvn5M9d/q5z703eKd6D3pDbgJXzO3knuUt5+3i 5fAqebfmvwLNcyYTgAuGnqBfcDEmQ5yco2aDLekuKqNvcrNZKH5Ktxe9rMuNKOYpYbiTjMi2t9eY ayvsgjH4lCd0sE6sqJFZ0oGGBzJy8kNKKCW0klNaaONAErZDCrV7zqGLUNpD+rqLQUvpEA5aoGZ1 1+XlFpaYioyC5agDkbDSVFtoB9U80OCwjJRRDhSrIVsL6/XWHMhCJVxzviO1PawuEah5QK3wz0nV pGcqNcAE8soMFUpLTnkOoBTZ2fLk7ozhW6cvw0UXBXA1vdLeXW1rMfOwfeCg519ifPIQ+j1k1tEv cirNttJqQLVXqcMFqJQEQXpNaCGlhkkOMrRcXQP6KHicPH2yqaYHUGdaJG8JkIgE/tqcMPekeAcZ XqGrAWcoqCK/jbq8PVKSs/dN/seksSxcJdYH52KLAYYPaM8OxrH7TPpFuIYTsStRHgSoNXs/geSv l+582mfXJ9gElZlWaYOqEfBam5zNl3ed2hgemp0YKwiLkr4JtlDouY9XQ+bJobquPn5bi7Ot8yo1 HarJGThO/pPLOShPybpYXGcECqDWq9ISkSfic2Ou7n8kHwFNPOByWHtK20u5TnRJSd4salD/iASQ gTZw0Vp0aN0LBYWhhTikGicZWK6ygmbgcBzrH4Mz4VLud0jYE94gdntblWsQlxQCfYnOHdmzTjKk Um2LHkfBsI0LX4Zv33zgqvlTOW/O32cD56SHkwEZo3TDBHPyNfp9zlQYCXx02i0FeGWPk9xRoakF dyg6gAR37Pa7lZQTRZAofaoM5dJlnihcyfqswK4DO6ip5SRYpFH6mPA6nZN8ozynGfxC0UtIWD51 yrOWNWfyFeBU9tOP+pVOL+g5AQsmNkHSm728HjuF7VCSDwtq9GA7NYUtbddqfYoodrIS/pl8AO40 9h/v63adBKfBqGpI0pHaJqt5u+68vdHW0kixJceaHP0n5kOPdeNoO98XfcH5AYwV9Knx8ivytjj/ +eBQVnycIkUVm/8WoMI1Vd0CeMIDY6DRUuXgj7LYEkhej1j3ekjUKgFGAOik53cy6NfgAo6q3BBm ytXm8DQ54rxQQCE+CzbRyzwd6GeyCD3t2cCq+tDhuAYoyGch59QyTzU9m8SwNbTT69oZHV/C2i+Z 0ExHc9Bza1YgPlrwzcvQC3p9/1fIh96vfIeeFWilnIdXV6DnkefRN7fFJ7QMZQmk53Pfx/7+7tSN O3z3XudBHf10O6PtMcx+yIQ/GDhwyXnPOlJVUgyKAJWYXz0moP9EFpRF5CQZ9ubwcklraSWwAqq/ yhArQGtIUbesOg6fnVyNgfYievbeBjjj8oDr1HHBXhIyPIDRqDPoVdkZhjRA+QR/AudCzzN3P7pw 5kiIwI1b5yTTxYC3MTYOurErVbLOl9TnAzkwFOjy1OgllMVFS2GGvs5UP00EtVXdZeXABqpLMVB6 lOTp4lrNz+gF6I2CuWgHCTYYDGsKMUKuOsl1ZZoa8BEFQ0i4FGZd/0tr0zkMyckEvSvPDUovNyjX j3qzT9K0nkM3k+Card9pr7XVlg+U4811SnKgqLbQkefSVCWCfRT6kpzi0EpPtFXJGgG1+UNHqKl9 JDv0P4FyIcm20/sxLDEoNaP0r0MMzHnMSQLzXB7M8sximbJyddkgD6jN6srwujDrEeALfCT7gnft E60GaAZY3fnquaBrb38t+glAT/DT2PVPKVXDdr+3Un0Azx8cdEUPBJ+RfAkgk4JvfQOfgouvnM+K G+J3pzikzrcpN7Wm1uc0qGCqoZuec83r3kOY+dibXVBFP8+pKrWAKkAdtxiOCKaSSHBYrw8wUeyX c2AByT7aQG4r1VaDdyi4luxNbjEMY/Q9/TX0gIvhvF1fLD8YlXEoSnCfNJUdykrSBufw4PJtnM7L fWN3z2xFFGKGb9t5JKivk++muvdgWjck+xj0SujDidganbYXBIHojrQrqgFjT/F1Cl5n5d80dGR0 p/ZFNh4GYeCISiQ+EivzA744FT54FZLf3bsKiWE+egBXcqofHO+/Dq6DFql9g5vxNH30f/UxjkMW /QZkMeE/Jn046CBaiBahyFXday4GCsb9v4j/Cz59GFwIhTDyp7RHwdcE/u9t7FuBYe0xBsZUfSkX w7tWATQTBGh3Zx/Oy8jJUCiSko6qQkAkONqQ1HV4LPkX7GMw0f7D8ClqcORM0yUwzbb/4pnfJmgW ZHizS3+DDA7YqdNuLcCMoYT9JKTA7z03Lt+82v8F+AF8mfog+NKb7yFGH3oeJ0szi71QSX5srMrD hMSWTPRwuqqtJx7fzBWf5j84dOJVgAiAno7duOlIaFqgbgOg4nSYVqbDWquph0HXaa92r5bHMPeh N1sNp+jXOZFtqVXxeOdnViAP7AOvd9d9O36p9fSoAGG6O6hS++FzncmB+loyuCbfCoYp+js9uQN9 zgHyQq0hP1OZrJMACZDZsl0pHVk3wbs47BfuPrrRlbyHPwc+xpVySTeMaWf8iknihrtcz4UUa9zZ NdBYa0hr4Nel1xjqAdXsbGjui2o9sC9EFpkuSI/KTyzZTPmmfIZuscAOvW6nu07aHaSvWV8N7lHw FpyD+ewCcMKmIXjW7c+fJ2Cu258SeBSOclqL60tawQNw0TbScq277zp4FwxrBmQdcaMb2lfhy9az 2PVK8m6+zQB2UlO7SLAx37DV+KSubDGra8GH2Ll0lkebxdIGF9w4smh5QBgiszWlZQqMUOgOIxw5 AasGsOWfJrzZCvpb+DpHygpDRLQcvQQoGSscxFQYLQXm4mpQT0EAV5OfAYfW7kM1Q7WCZYwtVOs1 2hxp/hF8nNUwg9VeWdnGhwtYOGub1PVrqWOsIviS51Q7i12KT2qya8Cu6Qq0S6PegUPip6T7ySf+ fd3F+Ogh00LP59Saq0prAHWsKjdKgMwkCDMa9+qw54wO8k1zjgNcoWAm2T1ytq2yqsBQza/TVJvs gGpx1Lf3ZLnEuKnwCxd8jSk7JDNRG6DkTQutK3C9C3ofg8mDFe2M9vdh7v22diadTHM5g2+Q2ZiH si2ZVq7MJqtIB9Tq7TvX+LeJ3k0WKFWqHFNBcpo2G2SDrBrdiWy/w7JkkECFPIj67t6D1uHz/IGu +m4wAG4cGd5uRpxKbkhZRhWoA66e3jZrVYmlxAycxfaSStAPhhxdbT3tjl5wFnQUNGu6KWScms/p MX5iOgOor3q0iYFb45Hn+sCO0WaLffisoAJ+w7na3jvW1ZqTWsdvSKqJBPHUwbSkyAMxN7/n4zyc fPYPBpgMROs5iGXePLrp99v2vvqxobvvDnw1zZCRaCFchMnhCT1ELev0vbqXPxjTnX1HfiqYe3sL nB0N1wMHZkVcVSpZ6MvJcc4IGFP2Si5GdK8AyBMsTVscF5kQe1gRDCJAVH1id8iplJ8BfAp83/Hj ibETo6caxzExTCP5+v/CUxIth7kcDBRSt1ml3owhstgNkQo3RBb+B4jc/wMiGMw+ejebTIP5jXIs kj6gYBpcTH4K6tU1m7A1nqFJ56JXu7RNXuduQN/3vdkr4W14i1MIF3rqWcXFecYSrNF4JmAo01dQ 7HprZmZ5+oItQaE7D3bHPYoQjCf3ZtfLgYQXlSINFUvsTUp+1rG8Zu0VKhetsbMstvIyjEK2fxWo LW7GFaLe1N5W2LDg/p/G3z8r7znQJ0DEn6R16mOgjTfU1T52pVO8rpn/RFUvuMj48CHcj7liLfye MzzWWT8IqLPHEncJUDgJ3jRoA01PZPUhm8kK3qNgBPl7zMVNATHyA5F8eIUsMIt1GfkHc3myfM9c srzUDCoANWLNjxZMpeDcMeUF5uP1EgcZWGmoweuntR/9q5tBJiag1s0g9yeXODkic7Yt7TiKhZXc W/bOmp627lbnMDgFRrT96R2iEz6tbhbpYLFPKsl7+TY98HvieINum7ugd2LHV2jtbseHkZfLYB66 7glfZbFDpyLox5z2ausQfGY8elVYVkyikh+ZnmRaUTxdmYbovw0xujEuhT8wJ8Pg3zjIqmKNFNUU 1eQ78ioVIJpCr5Ep+2U70cYlkAX3f9v+1egZ/uiZG223wWVwRjmY2Cmtkx3bTzWz8mGiZybLpFRp soAB5JpVlqOOSOtRfOojWBstQdHL2rZdDhDc2v29CM4AjwF8pneol4JRJLhaYx+voObALsN5ela3 lx0WoH24WjyCVsze7PdexvRtKzGb+MY8U57RIAqOjsgtpNiP9EaTsWA+KCotNhdT7PcuoIusjZ3R V88MtJzv4WurszJyDJmAl6Bue0cAB0n2o19Y2ASO+ExHrwvOnvB6MPEatvI73OmWpa8Ee6qxXqwp s5dWAV7LNJ+pSbDToN/trgQGB/lWRb7N7V9IsulQmMWRKRRSaZOivaO5qaNd0ZyGa94FTV+mi0Yn xC6vO4+h5hdv9kL6IK72WaxChV6fg92CGz0rxe6pTUiwpiyIBlE5yWlJElUMOAw2jx6EHgEfiM7H HhNVaSuygJzaExa5Y53/JTgnjK9gdaIkzyYW299ZWlPrWIApvtBpxDupB4byhxZA8ouPf/0s+Cbi 3hG8OB4zCi5Sl4YHbpwcVib28rtSatPrAnDuTssBeGYU9jsZf5uAlyeYUAQRB6tO8EF19X0LVpJd SvK+sVr/PzXKoHvdndZdTnJbJUbXHQrGwsvo8H8acXdF/74LCpnuAsaDXPSmek2t152HcPdDt1vk ZzkFrEg9luzwe7SOZPfkkDeKagwgjEI6EkgLNBq9LFOiSwVUfMrxYQG7Hn6MXtaQp4tq1SCSQhXk ltOhH/YP1rW18UdGPH1Itn958VlXX/W5Wt50uaR/HGZAC76hZZLgTBWR4DW93sd94pNO0rdcY8f1 lrZeJCELNKma0QyqhWWCb3hOXWeZ0BueLawWyGh2Qg/MlLjgPekLSbwZ6ZZO27S6jUVPeklfc667 crvv/mGt/aFbi59Vko+edG/44hoXvcXFoNPdKkSgZnUXOQxACQzFhkLDUlTDXQyrTLVFtaAKdwvV ll4z5UChanKg2GIYWwRnoSFumclsNOdXqirzK0ElsNgd/fBZeJfbcbvS0mmmnhCYj4PxGS7Gk0wO hm6pDVA9Nm2EYCoLy+Wiop3uYqx1kNmlcWVYZPTyoD8JheiAubCsqKzIXMSzGswmUEDl5Zl0fKUa pjlYUWaJM+YcWgVDuB1td969MdZh5TnKa8uwZrI6ULSGNVhSXQg0ID9Po9Hhfm0Ol/YhC8tEurT8 wFxear6nm1dG6Ukn47cJ+I9RJg3pGg6YqKn7zIbdo1aSD0x1mWAJVpaYXo2i3FRZxF7JNuAHwltk p1Tdxn63ov9wGkyfuMHUh9WnCYNpB4Vukmj7p77wDci413t7kN8yXDUG7rvLi2aA/m8cIj8coi76 LAd8WF39qbs9H1KSnz1ZOxVHHtVlpWtM1mNGvqE3tw5rB1mmQhZzInUcEtc/gM+4e7x/xus2jpea PG60GUEOUJvketlalMHdCBU5YwAAOw80VVtOWXC0otRkf2GN3nXIorQoK1VrUAR3KawttBXbgI0H Gmusx8vxrD1qsrnYamgKhQvQd9yaVKumEhcJq72mFTcrRu5XSF+bUG6qBDwLqKiqG8It8U/chmFz hQubIKc5i/HjQyZuPzmVrOrSmlLc0nbbNLglSifBIY3WvwDHWO8g/ct1NnCJor/F0TicIzLszpl+ xrkSNE5zW7wufw6XfuruIPe/y8nR6ArUgFIYa0cFEGfz+YIOdUtmX7QzAFCrtof7K1zZzS2Nrqby kooSi6C4qsQKLFRbd9PQmba0Q/z9JFq9Lyc/WpSZrRGDZIod6j8adX30ROP563y2/XBFQ9aJBcfx 5XsH8BB6Bet2SUFelk6ukeZlASpJenxEUI5J/0QfnD36pEWZzq95E0x67aQ3p6bEBspBZ3FNPtZx mYrU4FC0C73KhTHkv8La7wZRjfZ/aqD+yQtNr5N83f2q9SEFD5CtjX998aNtF/2AnAc0GqO0pADo wfQT0LiTPFyqsa35AWmgmQuDYMDtm3XW2xU8J3K4yQq46PUOBux6DkY6WBKQXScZRc/CUO7ncJaz rbOuu5TnQOvUZGexzYSzQKfLzJAUmHQqbbbGxZUOq44DO6i1WzpLceDj1FVkJ6jTdh35Fi3iIhby TY01GJOLeGq42EFKdRX2SovD7hJ8DOd+hYTlpjITMPGAyliY7K7OTpzcz59nPH4I/d0fppN+kWM3 W93Pfq1VuRECVOkOv/pgCQ5/hoMMKVNXg0EK9pKgzGqzWI41j9T3Amq0KQlLmVTcWen1Qe5SpnCQ QaXqenCDghVk50hPwxigrjTIfAQokQRB+fmBRjxJ6iDTy1LLtA1gkAdjSfh0/LU3AkPTAw/xVVfE bYdAFJBqfPype6SxLFQp1ger3dIdN/Az32G89xBm/4UJV02+zikoi1HL8o9oeWlubVRZWg4sgBqq yosRTNWRkkfJn0DuBJwBX4Jzt367ZH9gYng2P8Rj8FTf+QdnX0dzEDNir+/ho83H+HP+7qd3Tc52 Mf7u4355CVeyzhU06IEMZJnSDVL0DPqai7jw2+KKvKYSMy+v0eQE1aCl2XbR/fLiUpJXSmx5xzf3 +HKFqBctomcZGwqnn2iaai3nzHhKsZI8V+BQ9a+Ch6aOcx0suJreDDdMbfZ0sB7BWls7ZMBTzvPV VRds/+TcC7V3XAwofsyEo+5mfs8aTw1ZU1FdXl7WYKkvxxzcWKVOEbifD5PzFbl56jxNUYw7TB0O cktprg2cpugfcGbvoXfCYsYv9E6OZajuo6proIPXpGxQyJUqRa5jWf3aaYn6Ed18lwG/esykpfB5 jrYiIUibdxTwUD4LboF+X3wz+BF4wPt50/2Xgg9nxiXwU8TqlBy/xgLu0I993e8B6uGVoI2vR67e uE6AdqNATx09393E0e/9xoBvDjL/Su/i3Oo5eR1co84mDR5NkivEKc3KvkpLaWkl31IGQClm/UpT frI08VCCAC+cXORinMb3Po3vvT0iNT0h0m9D0hKAngKI3b/sL4tPRLRmnk+pqeNufkfaK7snv6X/ CPwMfrd/1naj/UZn3wfj1D83gRGPmQNoF+fu6c7W/rE7f+6dblLgswk/rJ+IPZ3edLhbl8v9xL8t qX1by57qrWAJeEnrI9sv9U9N3Bk4XVvbaY8xxvFvYPmXTDpochvuqAyByh2hiHgjALEAmg82tK0f CRuIuii/ASg47/F3mFif3fEpIqOyjCJ/QRtcgemXgGtbKRSLBjmPz+7ESJoRv3/X+kPfwlfOWdtd DkFjXVdVr1sFmPHH5Mr9zQuuGfRmR3+OXvj//cZnN/7hOnZ0mQU7b4HbdynShCe+gyHvMAZhCXMQ 2jj+sOQdN9tAwwjt0c7o/Jp5NZMDPeyXnLfP/PbRdTgPwAUU9H0FPoU4aOa6l9ECNOeDTZC4NFx3 4gI/Fm1ETCFamU7Bq3CSA7IL8/R5UnmCNhFQWyPuwZlX6q41tgrqXceqOwD155Ovoi34AGY9dvsz P3NSM9IlaccyOrpaj3V0pbem4qEuPWTCUshkwIV01L9PQMjjPy3SuCb5eMshjIU9LKT6x27P2yw3 uHb9Bmfi38lBJsx2jyUf3Q8OUKG9opO9Lc3HuxSuRBNu+LCgLwagBFD5pkprT3vfxX73s5GmddKr ldHyPbR/7xZvPpxgEJOTkBR4UITIaZgxetBTpw72R52Tj4NzYKS+r3f80gCkAJxNwZg18AXkzS9K 5zw8iTyRCImihK++GvU3GA+TTkLmY8GcbBcd4oLBLlbn049mdlpnzXrUMGs2Qfw/HclGnQplbmRz dHJlYW0KZW5kb2JqCjI3IDAgb2JqCjY2ODgKZW5kb2JqCjExIDAgb2JqCjw8L0Jhc2VGb250L0FO QUFBQStGMC9Gb250RGVzY3JpcHRvciAxMCAwIFIvVHlwZS9Gb250L05hbWUvUjExCi9GaXJzdENo YXIgMC9MYXN0Q2hhciAxMjAvV2lkdGhzWwowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw CjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMz MyAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAwIDAgMCAwIDAKMCAwIDAgMCA3 MjIgNjY3IDAgNzc4IDAgMCAwIDAgMCA5NDQgMCAwCjAgMCAwIDAgMCAwIDAgMTAwMCAwIDAgMCAw IDAgMCAwIDAKMCA1MDAgMCA0NDQgNTU2IDQ0NCAzMzMgNTAwIDAgMjc4IDAgNTU2IDI3OCA4MzMg NTU2IDUwMAo1NTYgMCA0NDQgMzg5IDMzMyA1NTYgMCAwIDUwMF0KL0VuY29kaW5nL1dpbkFuc2lF bmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjEzIDAgb2JqCjw8L0Jhc2VGb250L0ROQUFB QStGMS9Gb250RGVzY3JpcHRvciAxMiAwIFIvVHlwZS9Gb250L05hbWUvUjEzCi9GaXJzdENoYXIg MC9MYXN0Q2hhciAxNDYvV2lkdGhzWwowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMjUwIDAgMCAwIDAgMCAwIDE4MCAzMzMgMzMz IDAgMCAyNTAgMzMzIDI1MCAyNzgKNTAwIDUwMCA1MDAgMCAwIDAgNTAwIDAgMCA1MDAgMjc4IDAg MCAwIDAgMAowIDcyMiA2NjcgNjY3IDcyMiA2MTEgNTU2IDcyMiA3MjIgMzMzIDM4OSA3MjIgMCA4 ODkgNzIyIDcyMgo1NTYgNzIyIDY2NyA1NTYgNjExIDcyMiAwIDk0NCA3MjIgNzIyIDAgMCAwIDAg MCAwCjAgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzggMCA1MDAgMjc4IDc3OCA1 MDAgNTAwCjUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDQgMCAwIDAg MCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAzMzMgMzMzXQovRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTAgMCBvYmoKPDwvVHlwZS9G b250RGVzY3JpcHRvci9Gb250TmFtZS9BTkFBQUErRjAvRm9udEJCb3hbMCAtMjA2IDk4MSA2OTRd L0ZsYWdzIDQKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2OTQKL0Rlc2NlbnQgLTIwNgovSXRhbGlj QW5nbGUgMAovU3RlbVYgMTQ3Ci9NaXNzaW5nV2lkdGggMjUwCi9DaGFyU2V0KC9uL2MvTS9vL2Qv cC9lL0QvZi9FL3IvZy9zL0cvdC9pL3Uvay9sL2EveC9tL1cvcGFyZW5sZWZ0L3BhcmVucmlnaHQv c3BhY2UvY29sb24pL0ZvbnRGaWxlMyAyNCAwIFI+PgplbmRvYmoKMTIgMCBvYmoKPDwvVHlwZS9G b250RGVzY3JpcHRvci9Gb250TmFtZS9ETkFBQUErRjEvRm9udEJCb3hbLTkgLTIxOCA5MzIgNjgz XS9GbGFncyA0Ci9Bc2NlbnQgNjgzCi9DYXBIZWlnaHQgNjgzCi9EZXNjZW50IC0yMTgKL0l0YWxp Y0FuZ2xlIDAKL1N0ZW1WIDEzOQovTWlzc2luZ1dpZHRoIDI1MAovQ2hhclNldCgvQS95L24vYy9Y L00vQi96L28vZC9ZL04vQy9wL2UvTy9EL3EvZi9QL0Uvci9nL1EvRi9zL2gvUi9HL3QvaS9TL0gv dS9UL0kvdi9rL1UvSi93L2wvYS9LL3gvbS9iL1cvb25lL3F1b3Rlc2luZ2xlL3R3by9xdW90ZXJp Z2h0L3BhcmVubGVmdC9wYXJlbnJpZ2h0L3NpeC9zcGFjZS9jb21tYS9oeXBoZW4vbmluZS9wZXJp b2QvY29sb24vc2xhc2gvcXVvdGVsZWZ0L3plcm8pL0ZvbnRGaWxlMyAyNiAwIFI+PgplbmRvYmoK MiAwIG9iago8PC9Qcm9kdWNlcihBRlBMIEdob3N0c2NyaXB0IDguMCkKL0NyZWF0aW9uRGF0ZShE OjIwMDkwNjAzMTAxOTMzKQovTW9kRGF0ZShEOjIwMDkwNjAzMTAxOTMzKQovVGl0bGUoTWljcm9z b2Z0IFdvcmQgLSBkaW1lLXJlY2hhcnRlci5kb2MpCi9DcmVhdG9yKFBTY3JpcHQ1LmRsbCBWZXJz aW9uIDUuMi4yKQovQXV0aG9yKERFTVNKTjE4KT4+ZW5kb2JqCnhyZWYKMCAyOAowMDAwMDAwMDAw IDY1NTM1IGYgCjAwMDAwMDg5NTIgMDAwMDAgbiAKMDAwMDAyMTMxOCAwMDAwMCBuIAowMDAwMDA4 ODcwIDAwMDAwIG4gCjAwMDAwMDkzMDkgMDAwMDAgbiAKMDAwMDAwOTE2MSAwMDAwMCBuIAowMDAw MDA5MDAwIDAwMDAwIG4gCjAwMDAwMDg0MjIgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAow MDAwMDAzNjcyIDAwMDAwIG4gCjAwMDAwMjA2MTYgMDAwMDAgbiAKMDAwMDAxOTU4NSAwMDAwMCBu IAowMDAwMDIwOTAxIDAwMDAwIG4gCjAwMDAwMjAwMzggMDAwMDAgbiAKMDAwMDAwOTA4OCAwMDAw MCBuIAowMDAwMDA5MTE4IDAwMDAwIG4gCjAwMDAwMDg1ODIgMDAwMDAgbiAKMDAwMDAwMzY5MiAw MDAwMCBuIAowMDAwMDA3MTk3IDAwMDAwIG4gCjAwMDAwMDk0NTYgMDAwMDAgbiAKMDAwMDAwODcy NiAwMDAwMCBuIAowMDAwMDA3MjE4IDAwMDAwIG4gCjAwMDAwMDg0MDEgMDAwMDAgbiAKMDAwMDAw OTQ5OSAwMDAwMCBuIAowMDAwMDA5NTMxIDAwMDAwIG4gCjAwMDAwMTI3NjkgMDAwMDAgbiAKMDAw MDAxMjc5MCAwMDAwMCBuIAowMDAwMDE5NTY0IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMjgg L1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKPj4Kc3RhcnR4cmVmCjIxNTI2CiUlRU9GCg== ------_=_NextPart_001_01C9E41B.9ABB6342-- From gwz@net-zen.net Wed Jun 3 01:34:26 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DDA83A6F23 for ; Wed, 3 Jun 2009 01:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlQcNwVGfIrY for ; Wed, 3 Jun 2009 01:34:25 -0700 (PDT) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id 7D9ED3A69DB for ; Wed, 3 Jun 2009 01:34:25 -0700 (PDT) Received: (qmail 22926 invoked from network); 3 Jun 2009 08:34:26 -0000 Received: from unknown (124.120.224.114) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 03 Jun 2009 08:34:25 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> Date: Wed, 3 Jun 2009 15:31:16 +0700 Organization: Network Zen Message-ID: <00e601c9e425$ac168650$044392f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQACOYOg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 08:34:26 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto://hannes.tschofenig@nsn.com] writes: > Hi all, > > Here is the first attempt to update the charter text to include the new > work items we have been talking about at the last IETF meeting. > > Please t <> ake a look at it! Not sure why the following are listed under "Goals and Milestones": Jul 2009 Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME working group item Aren't these activities included in "Submit new DIME charter to the IESG"? Also, it might be nice to include some explicit provision for the addition of new work items w/o rechartering again (it is strongly implied). > > Ciao > Hannes > From hannes.tschofenig@nsn.com Wed Jun 3 01:36:49 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143BB3A6D74 for ; Wed, 3 Jun 2009 01:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pcztrzFIfx8 for ; Wed, 3 Jun 2009 01:36:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1D7A33A6781 for ; Wed, 3 Jun 2009 01:36:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n538alxQ004970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2009 10:36:47 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n538ai3l016307; Wed, 3 Jun 2009 10:36:46 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 10:36:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 11:38:36 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501684886@FIESEXC015.nsn-intra.net> In-Reply-To: <00e601c9e425$ac168650$044392f0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Recharter proposal Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQACOYOgAABwDEA= References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> <00e601c9e425$ac168650$044392f0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" X-OriginalArrivalTime: 03 Jun 2009 08:36:44.0425 (UTC) FILETIME=[6CEECF90:01C9E426] Cc: dime@ietf.org Subject: Re: [Dime] Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 08:36:49 -0000 Hi Glen,=20 >Tschofenig, Hannes (NSN - FI/Espoo)=20 >[mailto://hannes.tschofenig@nsn.com] >writes: > >> Hi all, >>=20 >> Here is the first attempt to update the charter text to include the=20 >> new work items we have been talking about at the last IETF meeting. >>=20 >> Please t <> ake a look at it! > >Not sure why the following are listed under "Goals and Milestones": > >Jul 2009 Submit 'Diameter NAT Control Application' as DIME=20 >working group item Jul 2009 Submit 'Diameter Capabilities=20 >Update' as DIME working group item > >Aren't these activities included in "Submit new DIME charter=20 >to the IESG"? The charter update also goes hand-in-hand with the milestone update.=20 >Also, it might be nice to include some explicit provision for=20 >the addition of new work items w/o rechartering again (it is=20 >strongly implied). I guess this is the text you are referring to: " - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with the a Diameter application for configuring NATs as the first item.=20 " Ciao Hannes > >>=20 >> Ciao >> Hannes >>=20 > > > From gwz@net-zen.net Wed Jun 3 01:56:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25B03A6A6F for ; Wed, 3 Jun 2009 01:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1Nj9oOx9wsX for ; Wed, 3 Jun 2009 01:56:41 -0700 (PDT) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id 31A573A6F3D for ; Wed, 3 Jun 2009 01:56:41 -0700 (PDT) Received: (qmail 27579 invoked from network); 3 Jun 2009 08:56:36 -0000 Received: from unknown (124.120.224.114) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 03 Jun 2009 08:56:35 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> <00e601c9e425$ac168650$044392f0$@net> <3D3C75174CB95F42AD6BCC56E5555B4501684886@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501684886@FIESEXC015.nsn-intra.net> Date: Wed, 3 Jun 2009 15:53:26 +0700 Organization: Network Zen Message-ID: <00f001c9e428$c498e8f0$4dcabad0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQACOYOgAABwDEAAAE498A== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 08:56:42 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] writes: ... > >Not sure why the following are listed under "Goals and Milestones": > > > >Jul 2009 Submit 'Diameter NAT Control Application' as DIME > >working group item Jul 2009 Submit 'Diameter Capabilities > >Update' as DIME working group item > > > >Aren't these activities included in "Submit new DIME charter > >to the IESG"? > > The charter update also goes hand-in-hand with the milestone update. Aren't they one and the same in this case? > > >Also, it might be nice to include some explicit provision for > >the addition of new work items w/o rechartering again (it is > >strongly implied). > > I guess this is the text you are referring to: > > " > - New Diameter applications, such as the Diameter NAT control > application. > This group will also conduct work on new Diameter applications with the > a Diameter application for configuring NATs as the first item. > " Well that, and this (taking into account the dynamic nature of the developments in the area of mobility): - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. BTW, there may be more than one document involved in Diameter extensions for hokey & I'd move the completion date for the 'Diameter Support for EAP Re-authentication Protocol' out a bit further than September if I were you ;-). ... From dromasca@avaya.com Wed Jun 3 01:57:03 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787D13A6A6F for ; Wed, 3 Jun 2009 01:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vzv20s4Rh3VM for ; Wed, 3 Jun 2009 01:57:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 652B83A6781 for ; Wed, 3 Jun 2009 01:57:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,297,1241409600"; d="scan'208";a="147508411" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Jun 2009 04:57:01 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jun 2009 04:57:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 10:56:58 +0200 Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Recharter proposal Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQADLtMA References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , Subject: Re: [Dime] Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 08:57:03 -0000 Hannes, Should the 'Updated IANA Considerations for Diameter Command Code Allocations' I-D be included as a milestone? If the WG agrees we can resubmit it as a dime I-D and last call it immediately - the content is quite trivial IMO - so by July it can be submitted to the IESG. =20 Dan =20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Wednesday, June 03, 2009 10:21 AM > To: dime@ietf.org > Subject: [Dime] Recharter proposal >=20 > Hi all,=20 >=20 > Here is the first attempt to update the charter text to=20 > include the new work items we have been talking about at the=20 > last IETF meeting.=20 >=20 > Please t <> ake a look at it! >=20 > Ciao > Hannes > =20 >=20 >=20 From hannes.tschofenig@nsn.com Wed Jun 3 02:00:10 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5357D3A68CC for ; Wed, 3 Jun 2009 02:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJDVNEhKg9Z9 for ; Wed, 3 Jun 2009 02:00:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EB61E3A6781 for ; Wed, 3 Jun 2009 02:00:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n538xwA4002972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2009 10:59:58 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n538xvTF005811; Wed, 3 Jun 2009 10:59:58 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 10:59:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 12:01:40 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45016848D0@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Recharter proposal Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQADLtMAAABSFMA= References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 03 Jun 2009 08:59:49.0137 (UTC) FILETIME=[A6491810:01C9E429] Subject: Re: [Dime] Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:00:10 -0000 Good point. =20 >-----Original Message----- >From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 >Sent: 03 June, 2009 11:57 >To: Tschofenig, Hannes (NSN - FI/Espoo); dime@ietf.org >Subject: RE: [Dime] Recharter proposal > >Hannes, > >Should the 'Updated IANA Considerations for Diameter Command=20 >Code Allocations' I-D be included as a milestone? If the WG=20 >agrees we can resubmit it as a dime I-D and last call it=20 >immediately - the content is quite trivial IMO - so by July it=20 >can be submitted to the IESG. =20 > >Dan >=20 > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf=20 >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Wednesday, June 03, 2009 10:21 AM >> To: dime@ietf.org >> Subject: [Dime] Recharter proposal >>=20 >> Hi all, >>=20 >> Here is the first attempt to update the charter text to include the=20 >> new work items we have been talking about at the last IETF meeting. >>=20 >> Please t <> ake a look at it! >>=20 >> Ciao >> Hannes >> =20 >>=20 >>=20 > From hannes.tschofenig@nsn.com Wed Jun 3 03:59:40 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887BE3A6ACA for ; Wed, 3 Jun 2009 03:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeRIG7JTJmt7 for ; Wed, 3 Jun 2009 03:59:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id BFD393A6BA4 for ; Wed, 3 Jun 2009 03:59:12 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n53AxCtL017016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2009 12:59:12 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n53AxBTb003086; Wed, 3 Jun 2009 12:59:12 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 12:59:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 14:01:03 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501684A47@FIESEXC015.nsn-intra.net> In-Reply-To: <00f001c9e428$c498e8f0$4dcabad0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Recharter proposal Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQACOYOgAABwDEAAAE498AAAjNNA References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net> <00e601c9e425$ac168650$044392f0$@net> <3D3C75174CB95F42AD6BCC56E5555B4501684886@FIESEXC015.nsn-intra.net> <00f001c9e428$c498e8f0$4dcabad0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" X-OriginalArrivalTime: 03 Jun 2009 10:59:11.0897 (UTC) FILETIME=[539F8890:01C9E43A] Cc: dime@ietf.org Subject: Re: [Dime] Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 10:59:40 -0000 Hi Glen,=20 Here is the high level idea of the charter update:=20 * Describe what is currenly being done.=20 * Include the stuff that we want todo next (Nat control, capability) * Leave room for further work without the need to re-charter every 6 months. The last item is, however, a slippery slope. If we make it too open then Dan and the IESG will call us crazy.=20 Was I able to roughly accomplish the 3 goals from above?=20 Ciao Hannes > >> >Not sure why the following are listed under "Goals and Milestones": >> > >> >Jul 2009 Submit 'Diameter NAT Control Application' as DIME working=20 >> >group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME=20 >> >working group item >> > >> >Aren't these activities included in "Submit new DIME charter to the=20 >> >IESG"? >>=20 >> The charter update also goes hand-in-hand with the milestone update. > >Aren't they one and the same in this case? > >>=20 >> >Also, it might be nice to include some explicit provision for the=20 >> >addition of new work items w/o rechartering again (it is strongly=20 >> >implied). >>=20 >> I guess this is the text you are referring to: >>=20 >> " >> - New Diameter applications, such as the Diameter NAT control=20 >> application. >> This group will also conduct work on new Diameter applications with=20 >> the a Diameter application for configuring NATs as the first item. >> " > >Well that, and this (taking into account the dynamic nature of=20 >the developments in the area of mobility): > >- Diameter extensions for mobility protocols, such as Mobile=20 >IPv6 and Proxy Mobile IPv6. Diameter extensions to support=20 >handover keying developed in the HOKEY WG are part of this effort. > >BTW, there may be more than one document involved in Diameter=20 >extensions for hokey & I'd move the completion date for the=20 >'Diameter Support for EAP Re-authentication Protocol' out a=20 >bit further than September if I were you ;-). > >... > > > From Hannes.Tschofenig@gmx.net Wed Jun 3 04:09:56 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1373A693D for ; Wed, 3 Jun 2009 04:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6QIvC+E+jLy for ; Wed, 3 Jun 2009 04:09:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E810D3A687D for ; Wed, 3 Jun 2009 04:09:54 -0700 (PDT) Received: (qmail invoked by alias); 03 Jun 2009 11:09:54 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp066) with SMTP; 03 Jun 2009 13:09:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181AdQUSUM1MZXLhf6VQAaSiN2oZekTtsqRFJAXXe p90HFjWYHgvtFA From: "Hannes Tschofenig" To: "'Glen Zorn'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net><00e601c9e425$ac168650$044392f0$@net><3D3C75174CB95F42AD6BCC56E5555B4501684886@FIESEXC015.nsn-intra.net> <00f001c9e428$c498e8f0$4dcabad0$@net> Date: Wed, 3 Jun 2009 14:11:45 +0300 Message-ID: <021101c9e43c$163d5a20$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <00f001c9e428$c498e8f0$4dcabad0$@net> Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQACOYOgAABwDEAAAE498AAE8KVg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: dime@ietf.org Subject: [Dime] ERP Milestone -- Was RE: Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:09:56 -0000 Hi Glen, >BTW, there may be more than one document involved in Diameter >extensions for hokey & I'd move the completion date for the >'Diameter Support for EAP Re-authentication Protocol' out a >bit further than September if I were you ;-). You are right. This is a bit ambitious. We have 2 options here: 1) We move the publication date to something like Jan 2010. 2) We turn the document type into an Experimental RFC and get it finished asap. Then, we hope that someone implements it (mabye even someone from the HOKEY/DIME group). This implementation feedback will then be used to advance the document to Proposed Standard with a much better quality. I personally would like to see more documents that follow approach #2. Implementing a spec that is has not been published as an RFC yet is difficult since the documents may change at any time (but that's another story...). Ciao Hannes From hannes.tschofenig@nsn.com Wed Jun 3 04:11:30 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42263A6BE9 for ; Wed, 3 Jun 2009 04:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7SEzjvwml4G for ; Wed, 3 Jun 2009 04:11:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EC51A3A693D for ; Wed, 3 Jun 2009 04:11:28 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n53BBS7q014451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Jun 2009 13:11:28 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n53BBRhM020967 for ; Wed, 3 Jun 2009 13:11:28 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 13:11:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9E43C.09C3D5A4" Date: Wed, 3 Jun 2009 14:13:19 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Rechartering (Update) Thread-Index: AcnkPEyeIQTIrxvVTr6NCdU2gH1kMQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 03 Jun 2009 11:11:27.0366 (UTC) FILETIME=[09FF3260:01C9E43C] Subject: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:11:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E43C.09C3D5A4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9E43C.09C3D5A4" ------_=_NextPart_002_01C9E43C.09C3D5A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the feedback I have updated the text.=20 <>=20 ------_=_NextPart_002_01C9E43C.09C3D5A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME Rechartering (Update)

Based on the feedback I have updated = the text.
= <<dime-recharter.pdf>>

------_=_NextPart_002_01C9E43C.09C3D5A4-- ------_=_NextPart_001_01C9E43C.09C3D5A4 Content-Type: application/octet-stream; name="dime-recharter.pdf" Content-Transfer-Encoding: base64 Content-Description: dime-recharter.pdf Content-Disposition: attachment; filename="dime-recharter.pdf" JVBERi0xLjQKJcfsj6IKOCAwIG9iago8PC9MZW5ndGggOSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1cW3fcthF+16/Yt+72ZBmCNwB9s2u1TRO7SaqetqfpgyxVtmvJlm3JdvPr C4C4DIAZAlyvcmK90FyQuM03l28GfLdpG9ZtWv3nLi5uTt6dfP3jtHnx4eTdRjS9/md+gdcXN5vH Z6oZYxsmNmdXJ20jpWDmN7aR7WaSrOm7zdnNyb+2T3ZtM3VyGNn21W7fNWPfCbk93+3VQyOTXb+9 2e1ZI5nsh+1/dvu+Gdk0se2daTFx0XXw9vtd37Cp4+N2o28KNoph+3S3H5phEnJQLx4b3nF10/bW 99s3O9ZMrB+Ff2nbcvjS0MCNS/3Zux2fthdzUz707il9CQZgH+t8Z/qpS38FWp6alv3Uqol/nsfa 9m5cYur9uEYuwbs+qKtRTsPkF3EQ27dYr6El6PWnLeggjAu8K98EPcWfdvNzclT3N7t/n/35pB+a cdqcfXdy9ttoc91TbWeHoGbmFm7eOH8ZduY22xm93eH3t9l26LZgYrDBFXjFZtc1arJqXH83E2v7 Nn4bGM5rbD3Cgr4Iqww6/qO+HMQg/Mz0eoEdud+JppMd6+wk9at+Z0eohmNXU4Go3yjwORC1EqCo 440YZhSd6SfZxMdx2r6cO1ErLdSqKziMXCFqo+8OavKtsNvCpJqnndLYT0pIXdsbM3jZg8fvQju1 k5NaPNbpVeqafpqHG17/VLdV3csOvBN09GYe4DQwHr/XtYUNzuFdpm7zUQNO35SMERM8R191Ca5h 69N58QRXkPocOrFDm0ZBDO2DFh0+TH4VddO3oAHe2HYth95In9pExieuJMZsSt8OUYtP4Tbo5Xq+ HNjgLqdZ8P1zV2ZreDygCyNUSqU0fORKjs4ulezcF0dJzQm28TKTbbkeGbLl9Lriu3fh71oB7Cen c/ZuRnum8DfPKnuJwcMluIYiEAbiBGDqyrKZCYBuWi0ApuM7/EGiyUvQZAna3aiU6xK0GRcUuN1N HNu38wiEWn7bIhGxOxwKYffgXUJ232tUTCProQZ6B56DIgukzA8oPIVg3nShhsnUY+PI1YAMKAbe DMaBMeID25ak9Dk+o2yDzMvAcMFS4bjDkTm/dxzLcPfr4XZw6KWHjJ0vCpl7ABMnHJITluUN0rif oPiFzT/HZK4CPF8BEcQV/X0ugyli8qXR0g16/zlYtqWBaq17+EAvkKu3hGwTajNWrM5evdjJplVO QRdtd7UpNGJ0i0kPHN3HCHkzcMZGbb0DziqjSFiIbCYpcigjBO9n6k0/CKwpCpTX9qYwoLFAmeeH AgVupped0HNYDFz7nyMt4e+fgjYPL70OAgku17z2atavLWMEJmBjRLnnpij2CJUqoOYJBQxeX69V HAkO1rlduEb/iEsmigP4HHCX/Tq8sdiYGs6Yw0ZR4as4LLNgDfg9AAPe/Qpcq7d1rY42+PabXdc1 Q6simO93eyXDvE0ABWxgJl2xAYM7RWnUN6ZnKQe+/d+OqXEKJtOhqWvRCjEGbM3rA7BlF7PrvVY0 huU5uH4VLNJ1uAR33cSGUQ2lkw1rmQ5VnXQ3iI4OlnEeyncn6r+/MUFsVWyllPAgea8WXfXcCxXM nYLHzkwDJpSb/4fd0Kg1YrHbBhe1hF7cbHghJFBV8PYSg+CmMyugno+EongdP4YqjTfAZUzEz0na ol9rGj9Bw6CakHWW5CRk5bHD+VgTRJ3ojaryTe3yD+1IDCq2lgbw09RMk3SA/1LHWMQrts6Wv1rQ NpEnaMcMQPgpEAQQhPPaiaFz+57CcdGIU4KRylyQrrDqiGrW8osGYIsuUW1A5QZj9c7IDHeYAxOP wnI3SgZ+yQDhGGFSGMVtNA0vwOFtQBZ8pADurbKzbnGDiVPqzEk8tEtwrFaJTpq1wxcdCd5qpZkk KbQbtw/BZBCHt7k8VXnTwG7pSR8AGetaViHCt7lEV+wKi2EQ97oKFD/OKlDZqO2j4HU+2e1l00tN g37je/tb+P2vs2eh0bFMpwQ+TUdPmf9lMHEEPm2dhlxpgcxScOGN/CQh1XnqJHyMCTyK4jPgEV3D uDcXi1xfcll2Z8MKwZCShlkk4HZgQMAJHiAPlGUsuzkwKn0IuGuUFODql4ADnCcl7v7yNLhs/wh3 oS9I9FiK9K4xRYZxf3H0Di0gSrFeY27RKmoKckgOtNBdMjZRLVjZF5tdoa4RXedkm/DLMu3fIMJo 3+SFUf1w9t9639y/z0G46xyERYdAmPeyQ0TYCEC2NKkEE7IXKV3nXLxYchMcGeS6uyVEhPD3i5kX XIESfgmuYyFCL7O5RDpmgQlZpYrNlDFBxbUknMMnK5ZMeUdOKg8hoEYVv6Iy7GMQN8We65Re0NhW ms0AEGHee1+hOpsWfO6Ufi3u/xpBLZvVr3EOdzGJkMt97qLMqYBBmLTPkjAtTkevTUJFOGWGKubE 3JCe03ovIgz4DlOdyfK6js+BnkR4JbsRSrOxMrw8ODEWE2qynLvB5uuGCLISFLWDpJ0lz2N4Tf0s sRUyyTs7IX2syyV63uH8Z3g4kcRcnROMZ3WcltOxgBZc9ErXpPBIqiMzqXDzHgXbXaBik8DvYiE3 spKLVWqRDhNnHd02bUhQQ1QVw0BCo19gML8ndgPTNLi/fYRyAadSDrLNME9hF+34gEuTwasAlzMj Dw84wP9a2Un4mzv8OYwGoVJNz1F5AYYFH3FRIHA5RDPiVFhLEMhuYFA6DdpG1WZiGNqoSgwk1UUN 5ir4gssKpBCklkkfVN/BbbqHljwdbZyXsEsCsHTlnTMAJVAsgo2USgbjkXkQmJf5WprnngXL8Cgi ZnSeh0fYJMMJDGg1riDkqyIEZ8k+DEW3qFDZzTHkDx7JJtUS6poPEuSXqGoJ2N8l2jeqrlGUrNPx LiWuxpkEGUtlA0EicsuYZMzmV1eHD5U2gKz1W7AAE7HBX5TXrSwIgeFgrDLT9E0cG7xA7S2YUmhA FBnhChqXWYSqktgWL3PkRZ+HYsrCMgPVZ9mZUe36MOTsDFFyUl2SiNOUGVOxWFwi4uwEvuIYa2kn BdS23U7GopomgARYEZjXWEgyTl6wTLbGAolr8XC45Hq+Cu4MKb5oOuEK89qe+JTuQbW/i9HFUR3j Sk1pBcAr7lD2EIuv+z2S3llb9w1vRweFMt2O7xcaz+P4IMCEsweUA7rM1MXZqnmCABaZc2rkH1JJ ufYkwYJLNZbGxQsaK9JUy0RUMfWE0vORweHKzvbcL4GJF+YRsDbObVXbvOMH0IdnutZKmQPLHUY3 UcQwjouP6F2CbHPLKBLFcp6q/YVyv09ZIX2auk14qWxHjXzDa7zM6Mu8GAGSHXOAoMe3dVVHv7g3 129/iNIcfsBIjneIGINc18edVZTML5EggS7KKraQ9E/KbeMeU20dKBnNkm4WMtM1QSyBQ2KxZ09O qRW27MgdIbO+wtzMA3p4Hgor6KEOUeAhN6XB8RQGwRrRsGEKNzKJ/Ql38gqN10PfyPGaw21HRZKP pLcQlYywCmkyJJ6U57LAuH+GpNIs10MjBE9yHF9oB1fWtyNxV8VSL5JiMVLmKQKoEIk9KEGPApqy SyOF5diCiNDVhEIJr62b1Qc/9fHFjiozucN0bZ7FLxi274ORCSVT0DcF1SUH88JHNVmVyjMPBhF0 E8oMktc4nY6oBVhRBTJPwZ1GEtarwv88wlxbHoJIVFQcNsNfueTMl48Uws3yQRn8Lmaaj07PrHc2 EjJ6XgmUjIYQyfyQJJArURY1lYirDiOisdaqZLcDyGW+3iN2YEsfCT6MSMS5k0Tg0FqM+FBgCXBV yjShLEK9YewyeDtqB24KALxY3fhcqmrtcHQM92HO+03tiGaaCClzcwlHXJ4aWot3HQMTBJX44XF7 dsNvRgwPO0G8VBHiA09SUAQIWl0bscM5q3fwmVxSIda4v5EoIdW2oFMcGyXFYPdM95v50cbOLKau lnKSlUU0Mm582GGQcNbJnfftC/YlOhZSkeGuczFj7zv+pAHhyCyZ4NIh3z42HQ8di/0+FNZiuCAU ORFagZdRigk8iec8Y1/QcR2Q54OtS1x8foxMTlNX5Sfg4oJTBpEdKb2iaLYI6cuqtxJe3xUH+CwR 7W3mxg8b9GH+5kpA1YUGzlvTef4xyvsPZUfrPRrCLJqUJMhHUzp5BUR+tmP5EEdsaVwPh9CD/oCw ff0kxbi8bYlNWW1p0q+IeFnCs/3F+huPBIKeqDsUYR14f/Qj1ryzIZF6rx1GKOYQT5oSZq/iqPuq qlNYT4sAiKLEGsTbsrP9NdQfwGd+xQE9+OQKbPw83+8xPtIfy4lzXzwz84vpyKiYKQuL1xUzIV+M MLIwtX1P6AQQdBXWL0mzomoBPRUPWb8pBlxeJ77MM2bVOsm3I4pE12dLwo292+okAVm/Hok8IQdc J3AQBoyMWg8sD7MU4XgdfhDKq3i7o5cVrCTKvzSxwAXl97z0PBgL52vLYkix2YXSjdfQGdwztXFC yZ2VwH5ITBLlhmTEFYtPyeIFBB/RuyDpCvFxi86JKqYvHAVcTWn9KUj6X0IJ5rfoucF/+kob+Ibs PGjG2acEGOmXxFWV+ScOVhK4Jd+iSHSmR5O5QEiqIPumchT0FROvLrfZCltIOXsae3ev2gN5FjyQ rEhA33wYBxrxVh6uWtIN9C2IanHtdsSS5CPwOok8P+xHPp55kQof6ADHYWDYDh8r1/Fjh6toEid3 KNbWEZHSUMnlYm79vCpAU1Mna4ETj7vGoeKyXIOOnWlNDtzirkzxw1egwfIpa/qLOkR64h5g7ALD IzGRVXUmNTR8TfXTipzcImPqPHQUWOcWWMoa9r6M8pcW6mLqrRx1oy7MPCm0Wqw6zJUHOsAPbzjW ZMdWVDSXAXXlHYCMCtNaBiVnKj/UYpW933hCx6PZqSOYM8eaqh8cFrBP7vhZoSeCIeuGCy7Cqi4f HTk92/xwov/+DwPteBhlbmRzdHJlYW0KZW5kb2JqCjkgMCBvYmoKMzcwOAplbmRvYmoKMTcgMCBv YmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7V1bd9y2 EX7fX7Fv3u3JMsSVQN5sK02bk6Sxo5w8+PRBseTYjSTXiWSnP6P/uLgQwIAYLLm71K1RfE48pkCQ AGa+b2YwoD4s24bQZWv/BOH1xeLD4sNSNcz+5y5B+fXF8tnx4vOXhC3NDcdvFm2jtWq1+yFZ6nbZ tboxP7lYrJbr438tCGvU8vibxfFfXq2erttGUqKJWJ2uN+ZO0bVUZfK79YY2ggndra6SCK6+940l J93qEsgna9YQ0Sm9Ou8bM2lFYmTBxeo/a6KbVhG9+szexTtFW2VeMcn+7aigXUWEjX83DyFNp7gC PZuL5hqXIr67eYez9UY2ShIqVhfrDWu4Jp0CTWGvv61pw6RumbkrDOcDGOS1l5WSLM6JEv1tptd0 V9+r5oyEllKobMau0uV0X+wKzvO/zcuaf3RCYi3TzP8M7gEPPU8iuAoen2Zwuf7n8dcLKkw3xOrU 8eniVe394RDh28YXOwUXwSrEn8MOwNu8L5+hONOrT157Wcvxx/0KLjaga9iHH98mDHDjrcMO8ti2 IrITZpLfAoMoltQpyqdkSeW7WP35tVwKq4yXaSV/WZs5l7SjtmNzkeuOgYupq/elAgatiPLApkJ3 qFHWLDh7ocFIWSfgMIB5vUVWy94HFvRtpgfujbTIVv9pWtqjJH6WL6IblJJQD3AlByJ8yGX5GmZi knSajyQ8rqqZ3lKMArUiWErq7OM2aLR9XaMNUExAFdg/Fyhw6iQomaTRsvM1DZqjEs44Xb9KcH0G extCll13oA2olsHnpc7+SPqfQTT2sATR78aVF8fzE7Tj04rKbkF/QTTH0N8u1G/rTddIQRirrNlH VPEiboGu3oBrbiVEt3od70DV5B2unjWgvvJqy1TDSVTbt2O6WEFqxLAH1AcxqkZtUX6PrCfr6hZa GEU/KmAUpeZJ6NcUiufMYCfFgwoEmuP6uAsE4VebivP0fL3hDVVE5W+KkxPsMCenqOuFGgxs/j2w BWw6BoSN+x0IdxTexKi6QXciYPbf18Z6mJJ69aWndWn8Z0vxpgFRQqz+uuaN5orT7LmfekwXTUdV MI5RXyN3j+r0rmRB7wNjqLF7qUwZFfjXrVEB6uZD1RkwQLCNbbNtlQh28cN6I5q2s4pzlPz1fyQR N4dPqQFQrXNUhPddo3MDXMxToMmIUzK056AD0jDmGBddY+qAg19FdYG+pG6bYmHNX09soEeWRMVA j6Q4T2hq1/vCrPdXLq4xsVA0HaKp9f6S3M+ksYLf16Qx6+vjKaMyRCgem5o/ZtykkcQENmYagwSa fmuRhkulo1Uz2z1vCJdtz+VGxUX/IBOb2okwvZuJojS+YP6kM9u/IB0P7ye5XH3R3+a1zc7JtrhX SNOZn4+jwjt3yg2NIfNDaavNkHKrWK5NkGCf+eXx8sXihQnKjWK1S9517fLCyJJ5+byXpZBOtm28 /Hbx0/Jy/1CeCDAmH8vHVzmgUwYnCtgt1GsYR/YxM6u4/xCQnhh0kx2nGQigfmLs9AyjmTG0+dY2 NauoaWbF49EvQIiMLChteCvJ6ns/Ha3BZ+izSSB/gTtFP6Q7ayBe83QiiFT8rTcYU6Ax9N/wABmZ bDB6EHr9giL+pSfFrm1U1wVSHPcN+zdguiNZkyPUKZiiGpVECbIMLCYcjIOSWn4EPgvy42jxmzBY QKm9R6FoLR4qEhxWa0/SxdfTHKrCv0xGBU1tO5ENua7qp4c8QRod9JeAUn+VVg3ozpsU+YwqZxr/ eAgHFAP3iJHc1/SQSA3eLPWReSlhkCcotwOoAK6cj6208QCj+zgW4Ijt8c0QXa4wm6kFtyflhJ1m k+C0nbWsabVNhsmg7QcQqGhJw5mYkVqsMj9Sy91Sy3frjW4Mlqt8Xp2+axZ0Pc/QhkjIdWjmVGRR UyX9l2DidZrRM8RCi4hiOFkIWuSJmD0T0pEkqDYkkeWQb1Y3gUVhTT/WNwn6nkq0H3BZSDmhQFtn solpqILJJiT+J2ectkf+E5hsqiXsyGNhSk+9rfDO/JOV6eKDCG04XxVCQ34+zmjjIGOfYR4ig97J lsUMk3O1gMn0wwcmA5T6CjOZqdQG01qA26RpRVs5E7eNBoeEixgcWjkEhy0jMTj08gzBIVdy/uAw djpncHibDA64xGg0MSNQWgNYeGLbMs6VroIM4K5bgqE9GHl/f3rSVnKOPgHFYFB3iW2A7QdDAyAr JxE2gFOUuRj2WtSdbTiqGDZnblAnEcF6386YMQSwctvtZUq8+6SyMRiYjUcytrcLSkzpmLFycg9K rOtixqqX5wAlMT8kiRsGpBcJkPBdWZCGzvsti1uQxDrQ2opL593V0h+F/iqwYdQzrlA5EgJOz7WU b4Rb8ihqBYv+MaFe6gm4lml/BEXVohbB7yd5HKKNltGzqu0szZd9ipmPu3VrLcHZ/H7GJwmu/KQA uEp6iG8NQu3cg2KsXdRSNm7GWkKm7i1u3Wqd1ccNNHJPczVg37dW0IRQCij2uwY00psYzcGQghYt eCyU9Vq0A34hXC6ZZM7pJUp5+byXBXVOr2vj5UP5hZnwgS45FQ2flWQ4T52+msSp/Zgdj/ZjdnI/ ZtdmnjFbTp19wJZV04Dn3QX6b8QS4BrhhVFovcSOQFCS7MBRHgYeJfgP60P323t45kfLKuA0ytRo 0F2hERyZz5OjfggphT5yUvLpC90oFjeBbiDecU445jnc4PaBc/evkrv/LomBG6InXiQ0/ISgtRdj JWnw6vfJBPHCzwOpaZhAPCjXMqCm24xwEChmKoU3Vg5QTGUKb7w8AxQz81JqbiiOnT7UnMsLfOMZ mH+e7Y97CbVNDLxi/fBKyPuYgkaxsNw7yXM/oU5Ny1ilf9fbqhOz0Ni2aopX/IgAnD4oYBzWVt59 7sf8P4KjlQM4mjAsgqOX5wBHyeHJo5nAMXT6UMHxoP3bmGU4eAcXYlGeI8cw+mVyZpPubUp4gCMa xcjK4Sc8s7U/BHls1I1mMmDj3G52aIzzyVhu4shc1Y3tKlFFX3jQ8i5bKYiNfkQAG0H57K6HkOLl yikkrLcplcpQ8XETPCvN6s5hkqpU1OnkHiZpl4o6e3kOmGRs/n272OlDhclBahjuKIO7FJcJhkBR yta3GN90qiXzShjMnE+ABFCZg4vzbC2ajslWjCQEtjyd8Ia1FKbDkeOoA5gtTsF60vBVnCbS4HG3 DgyvZtw4+NYQJBVQ+ucAsAJbYueY9iStAMr1Bru4JQyYmEhOM5QBeHlqEg/hj7zeSUlKALeVYzmA Y+cWdzxTsgWt3aESpLMdwHp4RhlNed0jsJYk+rRODmAt2ujT9vIcYN2y2aHad/lQgXrMl/rDrqYZ tPFksm3RoK4HlFiiwfZ4hWUIpmf31hBjj7d9SuSE5jYnWbvHbPNS6TB+Zvh7nSY7wOxVq5QIZs+Y AXk2V93wqNnzLpm9lYPZM5nM3sszmD1Vcv5QNnb6WMowuZQBhKpXqK5ix6h/rlgBquJ7ljTsUlJA 7Nk2SnYqKvD7LcIo0aC2Smol7jhlObVqNm2TuHEAb3Dm0oJ03uZGKwvGN3AOrp69i9qC+1VPQClt Qz2Bk/t6AkpaGeoJenmeegKbdZ43Huc8dTqpniCM2RFaP2Yn92N2beYZs/OO5x6wJbc04Dvxa/W2 7fsdC4d33ZaaIWmJ8glGUqC35P9VCmgBasOFGN0HwseJf7wCAFgZTI9/Pocbson5iN0oKzj+u1OW 21Ab46z+1f4PSSvkOVJ+6nlKBFU2BOAg8BT5NWbeo8n/O08nEC1jXOHkHnqJEjGu6OU5oJeK2YHX d/mYTrgf6YTb98xjnqGIXxCc86irjN3zJXJmY+YyqxjP3NqxNlfMBVHcD/WxomAuuOxI9FSdHOBS 6Oip9vIMcEnse80NmLHThwqZj1tlf+KtMi3uw1ZZ1MWZPkRiKF6QrrvX5ybBm5f5zds+t+2/NCKN 9dCpRS4Ir7ktiXtwugXZXaDaqJuBcEBrXyewK58IvupSzUDZNgTJRvX3SmnngUyiQS5S1GDlQIOM p6jBy3PQoGTzVx3HTh8qDT4W1v3ZCutuJLbSRGFkY78hVjlUWRTiPR6qfJiHKqdFU4B24MYHjKZG iKfYBtED4mmJ0TOHojfz+Sw8dQvqR6vlTS4d0jGk4sF9KR9YU1Js/HPS8GNUWz40dLe5FDchrQ5e iFcC/8sz7qMaKPjJi12OZv6Ylh7aJ247KCdjX8vPvi0FuPC7JD5Fs/LP8ejqro6xHF4S4KhSGdtB f4vGfsUByIMq8xZVohdaIXaM5isd4/MNuJHohuY7/eD3t+Afdsb9gkPjVYZ9OXMLxwX9LWs7jSpP KveqfvrusNrO2yrxoh3bnQPDMuruUOxThmjs4YcbocBH7HvEvpvGvj4of7H4HyJbKHdlbmRzdHJl YW0KZW5kb2JqCjE4IDAgb2JqCjMzMDcKZW5kb2JqCjIxIDAgb2JqCjw8L0xlbmd0aCAyMiAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1ZS3PbNhC+81fwFvJAFO/HsW7STjKTTJyq 00Mmh8SWm7aWH6rT/o7mF2cBEsBSAmmNLGWStPZlh8Rjsfy+D7ur25oSxmvq/6Nxtqpuq9vaEuH/ wiNsn63qk0X13SsmapiwuKgocc5SF16ymilRG2qIlvViVb1uvm8p0ZwrbprLtuNECSU0Nq/bDlZQ WjLTnLWCMGWsa94m6y4P/b086wrZf7UdI0ZqYZpHrSPaSC6b2g+QxnJq8XJ4jYkh79GQZXIJBjMY 7YxonraME2G1a574oUxriFPzc9spQiEMvPkpnJ8JKtM0q5uLFmZpY0c+rOPDwRknBUMhue/IKsZH K9ucFx1ftx18GcXAxa0A+1logandsG95jexD+T1++jIHZ53D8GbxrOJSEIAK4GhxDtC5QdteFw+c T3Y+4SL6Euic2TF8tGEN4Qx2Pfk4vHYiIMr72wmqiZCq7pgmtnf6GTgH3mmlmw/9BEO5TYB3Y6hx NIRu28EtN9i2R4blnFAZllGUESlUPCRzMu4ZJr5D9qrtBEBPYA4hnEefpHCIN48zd9G0HJq06LLE 1uVGCB0Vo7O/aDtHINhWDCIRSLJANEKE+aHtJOFW0Glkou+7LtHrMr/HCEF7Y8DdlGcihsyI1Y5c etSj3hiQXhdRvwPBYlAe5wg+bQEWkmrWPIf3nBjO2UiS8LL/5CMX9edPRAR0jKuwszMA7d8AI1Rz YBVyJz8sxv/DRHSxZ8NukskYSm8u2w74payNiONGRArG6P1PwT0oiFiVl7zJnzk/xAdBkCgzo8yC 5T23xS9lImJlLxItrzu68SMqyxwKxNOSUC4j8UZsirf6c78P4MHxGTaleXNs2gwdFoJd6AROqH35 tPFRlpvwUcwmPg1BQXx60X8Yx9L+gSB/I/seQgW/xoRSlPr9nizq0+oUEk7GpKmV0qZegW1tb18O toSs8nIY09vvq1/rqwekqSKkqFoZwkOmCkdY/JHd2X9hiVd9fRyN8GEewK7HTz+bXiR4l3OwMfCA TUqpMTS/yRsdu4Eu4qwnJ/nUWK16OaKEKhPl6K68G94BDZkvVEBNtgoVYa2ZLlTSHrhSidcCKlS4 or1sKEao8NewiLKxR+XiMThVuUQ87lsZYhzPFC74vVObK3BKFDMGRRMPmKjqUs2VyLcvvPK8Cei/ yvD6sZXESSt5ZBrnPIq8hmU41fMiH7KdY4i8AN2MIu/tKPLM2STyvX0gked6aEccVOTTqkcSeZ8I /ptgf1xhP2kVMUJTtUGNIY0eKco9hXxRvstNnh20fE5EPaA/lnom89IZAvsg6Zzv8ZSks9d3AyDi Ud+P1+3xxZJmkC2mLY7S7GFQbG4N0BRCEwvF8QVh/eWBL4ghrpbjyvIi4XM7mfZPpzV0x3tgS0M3 E6tBQxl8+V5Dgcz7aujREmWfKEQN9fagoRK+RNTQwT6MhiqnoeQ9tIbmVb8BDZ0qpgvIe5fx/mUW 05D57KGsD09KZ5U1JsmwXBTRz9xHP6KyBuGcaaOH97FGh2RbYiV9mQmzLurnA1vpAd+IlXcl9hRa 6Rs4y77F931DbUpPUSNva5td1DTYrKCsQx9P63CPff19vP92K91/zY9DK91BCS1KrfQvLycsC1bc 4MC/+2G5ClKC2uuo6X6dMrdhJ2u1wFkcU8QJjrVnrpb2Ud36ETAg9qtSrPzjX1mwICbaB2OUGp1W nwCBvHEAZW5kc3RyZWFtCmVuZG9iagoyMiAwIG9iagoxMjg4CmVuZG9iago3IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNCAwIFIKL0ZvbnQgMTUg MCBSCj4+Ci9Db250ZW50cyA4IDAgUgo+PgplbmRvYmoKMTYgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAxOSAwIFIKPj4KL0NvbnRlbnRzIDE3IDAgUgo+Pgpl bmRvYmoKMjAgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0 ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAy MyAwIFIKPj4KL0NvbnRlbnRzIDIxIDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFn ZXMgL0tpZHMgWwo3IDAgUgoxNiAwIFIKMjAgMCBSCl0gL0NvdW50IDMKL1JvdGF0ZSAwPj4KZW5k b2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKPj4KZW5kb2JqCjYgMCBv YmoKPDwvVHlwZS9FeHRHU3RhdGUvTmFtZS9SNi9UUi9JZGVudGl0eS9CRyA0IDAgUi9VQ1IgNSAw IFIvT1BNIDEvU00gMC4wMj4+CmVuZG9iagoxNCAwIG9iago8PC9SNgo2IDAgUj4+CmVuZG9iagox NSAwIG9iago8PC9SMTEKMTEgMCBSL1IxMwoxMyAwIFI+PgplbmRvYmoKNSAwIG9iago8PC9GaWx0 ZXIvRmxhdGVEZWNvZGUKL0Z1bmN0aW9uVHlwZSAwCi9Eb21haW5bMAoxXQovUmFuZ2VbLTEKMV0K L0JpdHNQZXJTYW1wbGUgOAovU2l6ZVsyNTZdL0xlbmd0aCAxMj4+c3RyZWFtCnica2gY2QAARMCA AQplbmRzdHJlYW0KZW5kb2JqCjQgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9GdW5jdGlv blR5cGUgMAovRG9tYWluWzAKMV0KL1JhbmdlWzAKMV0KL0JpdHNQZXJTYW1wbGUgOAovU2l6ZVsy NTZdL0xlbmd0aCAxMj4+c3RyZWFtCnicY2AY2QAAAQAAAQplbmRzdHJlYW0KZW5kb2JqCjE5IDAg b2JqCjw8L1IxMQoxMSAwIFIvUjEzCjEzIDAgUj4+CmVuZG9iagoyMyAwIG9iago8PC9SMTMKMTMg MCBSPj4KZW5kb2JqCjI0IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggMjUgMCBSPj5zdHJlYW0KeJydV3tYU1e2PxHNOUXKtKS5QsHktNNSvHrR3lYtvfVa rU+qgI+KFQLkcQKJIYnnhJeEJAQC6JY3BEiUQBLIFAOCvFGLfVgH9fM6Wjv9Ou3MtQ91aqfTGTt3 H7r54+5AO53vm/8mf51z1m+vtddav/WIgFi8iBAIBOGbUjbh38pta0Jv/87HCvi4RfzyMIAUP2hm k5fwkggCRISBiMXeuEf/EjWb+DgPf8F/8tjC8VpBr2BCwCe8sTd9xcqVq14zGEtYTW6eiX4+KSmJ VpTQP0roLQynydXT8fihkNEZjPmM3pRI72MY2pTH0GqNjqHT3ti8a+drdMImnVyl0ujpbSyWphUo dBolvUujZPQcs4JWG1hat/BCKw16lcakMei5RHoTR8tpzsgoNXIdzRQrGWNIsIo2Mmy+huPwM63h 6FxWrjcxKtpkoDV6pa5AFTKPv6sNehNtZA1Yno8lWFWagTNxSlZjNNHYYtqWbQt3NOXJTSG7nAaL aYMaI1UGZUHIm7/LTHKNnqNNTLEpZEfB0CoNZ9TJS7BdrMrIauavUMBp9Lk/W19Fs0yunFXpGG5e bygqP/tH/4PXcqNRVzJ/1jCP+rt9jYljdOrEFE2+ooCj9xry5Xo6xZBE76J3MypNQf4/C35O17+W QIIgYvXK3QaVkdmi3srmcttNmoLDOnlxfnrCCvplgkglthCJRBqxldhDbCOeJbYT8cQ+Ygexn0gg 3iCSiQPELmI3sZl4k0ghXiIeIcIJARFLxGFmEYuJEuLXgrUCs+Bvi0oXfRqWHNa/OH6xfcmrSy4K NwvLhR+S68hh8i5V+kj0IzPh+8Ld4V+E310aC+si+YvAx0ddz/VF3YZSKIHSZaIJmMfLxWgfJxyv bCkHcgpNkUBeYc+yUxx0+Eh1g9UFBinoIUF9U2trCyX62Nvta/PGDpw07pOiKhKoLaWaagy2+khV XXkbGKVgPXnnwLtJqTJDmloSyaeVXedj+gR++FQYvwYKxGr5kTIFoF7c/zmM++vpK9NuV4WtUdpg BwDITxw6ZRoE1GiP7+zMjnMvoLjnnkLPIMlXCfCxj9/ru31JGvnDFuCfFfoF34/yAbg6bPZl/m/i uUYS7CuzvlpJsfB//eSG1nInuEnxKSS45XJ92ED5UQOJMud0KJPXLUGNrPBDh9sC0qk5AwlSLdYN FficxU8mNRZ3gtsUryVhw9zdJb3CSL6mrI/fELr7c/B5+FwYrOfzxUiU8DSKQ7/8+hm4DIofPMSh pFc+RGLpCZ34Uud+9BJKLErfk1b0NoyHW05Nz0hx3MveK/Dy4e/B7b4oP0yA60OhN8N7FvFku79h pmmmOdpLyuos7Th6/C10mCOvV7VUAhmFXidzJvPdMkChRUk0elYqCqK43yZ8fzHovjAlqbksBo7y o1ZLkanQVgCoA+xlKILi3g8uBfs4piNkGMm7Cn0clFve5cPfx4n/CN92HUxYJtr+D4lvDSV+7hgJ FBX2jApK9EsO9pAidxeZUnfUA65T8CnyXGaPZRxQcPHvHuL7S1/9GoWl5Zr26KSi2FqZGDS1uNva Pd3etm5ATftS0TL0mCFtr1bvHTJLQwy4BVMH4Yt9Aj4ePi5WHtKV5AAV0J8qHCg5XRGsvkHBBqHj D+apw0PaszLPfuzt4+sTUDyK/2wlfOzT86fvX5MiF9woroMRp4bPgwDoLG3WNRTXGmoPUmYyclYN /OwA/7Cf9Ud9g91rhZuXiU58c1cMstmiPccokY6FN0iog89g0iuhAtHwcVQqRZeEojiWvOroNONQ i3RwnVfs9bSdvfW2dlu/pPdAx2awHqwqWns4SyPLMCUDKsvSPiGNhHdwFS0fhxl9gptQGnaTXytG d0iQY7PKqnAd9PnIrbXWNnCNgtc/H38RRpLvuroHTjkrrdU1lY5yid1cbQPllK6H6x/0+wc/SBtZ vyOdyzZKCvIqFWAttTdbGDm7GjvUx8OQQw/humWiBP6r2ZfEc7eFonaWvFHdWQoOUnPFJEgvs23C Cctj+c/IYahaYhDqdhQZcvUy9f7SjYB6vbh9TAqrSCgAI6o2RFE98O4RoRkJVbmIOEFBMznU3jIN 15/XoBi/xI8Jn4Z9e95X4Yn6fYiiN6A+RJI9nHDM4bQA5Xx3UJTbsiuwo50+MqXe2g5mKLiHnA6M BZtbKkudkk6jy94DqMGewFmpaM2EJpj5JmPckYkbQQ1SnIaRMOLzXqi7aO+LCnzxClwOo2Gs+pNl oiiCL+SfFl9E/0aKvibc2YZGZSxaun7nKk271muQdnOdlqmiV4xKBqQDxamSqyZK9I1tl13LKp7c 85EGRsGXv5j+9uPdk89KkoX/VdQUeCvQPSydOD4F/I39nhjRb4iJHu/IxSfBsPUtQ4D677kDYtGH tnd6jmpl+48kvCDzjnc1OQNeqWgl8SVvF091MomJxbmZGSVn7v+xc3AKkzimrJ9/KSjo/TOUPAiD 9+EnYvhsAekwO6qswAHKa0sbtE5TPa7CNTt3r985IvsuR/o/+QEWHKZU+UeytsomPi+UGFCSX+js amxqAQ2g+Vhrda/1oi0AqLtXZr66qRpLGJVu/5XBD/qpYMA/1NNrK+yWdBU5S1zZVORsZ3FwNjoo GIRb4TRcEzZbDYfF6AErvFPlsoE3qKfJg/qCHbvknWNaSfZ7hXcAjKAgcwWGwUcnx0qYcckY49UM bKT80GIUluXZbMXADsz1Ba1pvgxnBq64DLQCJSIFUsB49AxU/xUKfENXpVCEm6iz7aNmCvPeehP+ MC64hUkPL2Fe/AfcwApT1iqzkvdTxmn0MZk8prxxffitz0YkrLOIKS0rBDEG28lhKXznj2Qk7Jun 1kdwddRluBrFh/h1H6pC/NqPm5C9xQ4UC/yqrJDZML8qfGReg7UDDFGi77by/yfOycuTZwW14+P9 wfExzUDOfF+9pvPyEl/UtZ/mWTF8YBGPuXz115pmmnBTza7FDB2j4BySceSF6jYryKHQGVI0odUW 2gyxCrPnbSm8h9I4cqSi2R6afw3kCxfSfz894L5wSTI/MWcpn+A32Ge+NXRXrUnoPNZ6vO64r8ZZ CSzAXl5is6En0BPR/GsolSP7azqOAoaaayKBylyirVlwJLOpqhFMUVBIen1foydPsk1WUBEDrGUO w3GMsPhIG6iqs7ehA7Ar+s/f95y6Egp434Lx66GAK3D9o72ccKDGXQLU8/rVR4s0P+rXnijtBMNU aGB5+O2n8ZCJx5UmQcvhclzFfP5VcXl5TU3N8SoQU1bZ4pbCDvIPGy+iSLRk48FXFT52ZDjg6+9w tFvdEntrTSNopLoC7gGJ6P6lHmOKdDOJluYeKlKzOfmFGhzAlKmsq+9Pei68K3Ee7C4+D8ZAn3to BKcJpb8vNuqKrByg8gt7hy+Njv6uC6epBnj4JI+AL/aJSxsq6yudKAEWR38Hozq9HmdfQ4wPvcKR Lcebj9cB7/FmBzADc/lRw2GHw1xsLnQ0VTfW1B8ePTIG2kFbR2PwBOVDdRzZU91Y5cmHT6A3o/Vq o9Zetm9T0VH1MRyPDT4yt7asCbiAq2d0aLK2rqm5qaVTf5JttHu1rcXAGoq7LoR04Nlx+6ed6OYC hxZ4dB4qfxqPDqf1J2baFjpfZYiZthAzQ3tRo7uzvZUSferuOtl0Mvasy5Q6vxcpbBZ1zUJu8+rx ErUAbgiBu09iJKCGXFzaPFRuszIhqB2vULW2thBfF1aovYzp9XRJ/pU83y6wC8iMTCoV+YPZ7OF3 euABjwD/DcGkSGaF79S4yoEOWI6Zq8rQYvQgGhHwy/LT1S7QEgN8rpbxulrccBpP4E3oGkuOHPPY ndzAymgUjn6NIniiyn2sOYT8VVvLdD3GTLHkqKPVfvIQzJv7NjoghCn8Ebhx7gheiWAm/237sLcr WBeDG8LsOo9gEi4Jgx/MJot3aw2FKsW61TK0FCAxWOP/z3MbJ18bU/4pjQqQe8+wPYUT+TNl9wBc DqCk47vA5a5xX8/lYepHPXAzVtSLXhHPBANdQyN37k3CpQA+Ae6xX2b8VnYrZ3jFB5SBfF/tZ7uy 3trdkQhQHECSsnhDalE2eyRVifXUYVUWuAEvaxsE8GW4RixjVFkZZ9RT54YGJ6eYs5lSeGOxjGGy Dp1Rn5saGsLfhjKlkUUeXu6B6R5hMBzSS4PBiAhIeyMeJYj/B5WLhnEKZW5kc3RyZWFtCmVuZG9i agoyNSAwIG9iagozMTUyCmVuZG9iagoyNiAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDI3IDAgUj4+c3RyZWFtCnicnXh5XJNX1v8TA3me1rWkKYnaJG21 7tatFdTWDa2tqICILCJrgEAggQRIICskbBcCJARCgIRFdmQVEPcNl47V1lar3dSZ7jttZ+7DXOZ9 fzc47/T9/Gb+evnkD5K7nHvP+Z7v+Z7LIDxmEAwG42m//dvx34rda93fltMLGPTCGfTzzDyU9nef ya2eNH8WAWYxwSyPxoXPn/eadD4z+fxc+pN5T5aXMdoZY4zJpYeCDi9bsWLlTqlMlSFOTFII1/r6 +gpjVcJ/jgj9RHJxYprwZfxPlkgilaWK0hSrhQdFIqEiSSRMEEtEwoBDO/zf2ilcul0SEx8vThPu zsCjAZmxEnGc0F8cJ0qTi5YJE6QZQsmTL8I4aVq8WCGWpslXC7fLhTFCuUwUJ46RCEXKOJHMPbBS KBNlpIrlcvy/UCwXJmbEpClE8UKFVChOi5NkxrvN498TpGkKoSxDisdT8QjeKkAqV8jjMsQyhRBb DPDb/eSMiqQYhduuXIyHhdIEPDNeGpfpvs2/xhQx4jS5UCFSKtx2YkXCeLFcJolRYbt4K1mGePoI mXJxWuIf1lcKM0SJMRnxEpF8el+3V/64n/B/3TpGJpOoptdKp2f9y75YIRdJElbvF6fGZsqFQdLU mDThfqmv0F8YJErMlMRk/PvIH/H6v0WQIIht21VpcaH7duRI48P275SJDvilJwTsykgM3C1PCnpT IT64JzP4rayUQ29nS2L2KlNjD69dss6ydNlrwpWrfFdveqVyDUG8SIQTBwg/wpdYTbxERBABxC5i E/EKsYgIJHYTa4jFRBDxJrGWeJk4SOwh1hFLiGDiLWI9sZQ4RLxNbCCWESHEq8Ry4jDhT7xGrCBC iX3EDmIlEUbsJ3YSPoQXkUSwCYp4inia8CYYxGxiDjGfmEssIOYR24lniO0YyYQHISK+ZBxm9M3Y M2OYGcasZ37jkejxiefbnhdYO1hN5PNkDTWXklBfPCV96tbTrTNfm3ls1uZZA7M3z35nzqo5YO7K uc3z2POi59XNm3rG6sX02uv1mM1nX3j2wLMPOMWcL5+TPXf6uc+9N3ineg96Q24CV8zt5J7lLeft 4uXwKnm35r8CzXMmE4ALhp6gX3AxJkOcnKNmgy3pLiqjb3KzWSh+SrcXvazLjSjmKWG4k4zItrfX mGsr7IIx+JQndLBOrKiRWdKBhgcycvJDSigltJJTWmjjQBK2Qwq1e86hi1DaQ/q6i0FL6RAOWqBm ddfl5RaWmIqMguWoA5Gw0lRbaAfVPNDgsIyUUQ4UqyFbC+v11hzIQiVcc74jtT2sLhGoeUCt8M9J 1aRnKjXABPLKDBVKS055DqAU2dny5O6M4VunL8NFFwVwNb3S3l1tazHzsH3goOdfYnzyEPo9ZNbR L3IqzbbSakC1V6nDBaiUBEF6TWghpYZJDjK0XF0D+ih4nDx9sqmmB1BnWiRvCZCIBP7anDD3pHgH GV6hqwFnKKgiv426vD1SkrP3Tf7HpLEsXCXWB+diiwGGD2jPDsax+0z6RbiGE7ErUR4EqDV7P4Hk r5fufNpn1yfYBJWZVmmDqhHwWpuczZd3ndoYHpqdGCsIi5K+CbZQ6LmPV0PmyaG6rj5+W4uzrfMq NR2qyRk4Tv6TyzkoT8m6WFxnBAqg1qvSEpEn4nNjru5/JB8BTTzgclh7SttLuU50SUneLGpQ/4gE kIE2cNFadGjdCwWFoYU4pBonGViusoJm4HAc6x+DM+FS7ndI2BPeIHZ7W5VrEJcUAn2Jzh3Zs04y pFJtix5HwbCNC1+Gb9984Kr5Uzlvzt9nA+ekh5MBGaN0wwRz8jX6fc5UGAl8dNotBXhlj5PcUaGp BXcoOoAEd+z2u5WUE0WQKH2qDOXSZZ4oXMn6rMCuAzuoqeUkWKRR+pjwOp2TfKM8pxn8QtFLSFg+ dcqzljVn8hXgVPbTj/qVTi/oOQELJjZB0pu9vB47he1Qkg8LavRgOzWFLW3Xan2KKHayEv6ZfADu NPYf7+t2nQSnwahqSNKR2iarebvuvL3R1tJIsSXHmhz9J+ZDj3XjaDvfF33B+QGMFfSp8fIr8rY4 //ngUFZ8nCJFFZv/FqDCNVXdAnjCA2Og0VLl4I+y2BJIXo9Y93pI1CoBRgDopOd3MujX4AKOqtwQ ZsrV5vA0OeK8UEAhPgs20cs8Hehnsgg97dnAqvrQ4bgGKMhnIefUMk81PZvEsDW00+vaGR1fwtov mdBMR3PQc2tWID5a8M3L0At6ff9XyIfer3yHnhVopZyHV1eg55Hn0Te3xSe0DGUJpOdz38f+/u7U jTt8917nQR39dDuj7THMfsiEPxg4cMl5zzpSVVIMigCVmF89JqD/RBaUReQkGfbm8HJJa2klsAKq v8oQK0BrSFG3rDoOn51cjYH2Inr23gY44/KA69RxwV4SMjyA0agz6FXZGYY0QPkEfwLnQs8zdz+6 cOZIiMCNW+ck08WAtzE2DrqxK1WyzpfU5wM5MBTo8tToJZTFRUthhr7OVD9NBLVV3WXlwAaqSzFQ epTk6eJazc/oBeiNgrloBwk2GAxrCjFCrjrJdWWaGvARBUNIuBRmXf9La9M5DMnJBL0rzw1KLzco 1496s0/StJ5DN5Pgmq3faa+11ZYPlOPNdUpyoKi20JHn0lQlgn0U+pKc4tBKT7RVyRoBtflDR6ip fSQ79D+BciHJttP7MSwxKDWj9K9DDMx5zEkC81wezPLMYpmycnXZIA+ozerK8Low6xHgC3wk+4J3 7ROtBmgGWN356rmga29/LfoJQE/w09j1TylVw3a/t1J9AM8fHHRFDwSfkXwJIJOCb30Dn4KLr5zP ihvid6c4pM63KTe1ptbnNKhgqqGbnnPN695DmPnYm11QRT/PqSq1gCpAHbcYjgimkkhwWK8PMFHs l3NgAck+2kBuK9VWg3couJbsTW4xDGP0Pf019ICL4bxdXyw/GJVxKEpwnzSVHcpK0gbn8ODybZzO y31jd89sRRRihm/beSSor5Pvprr3YFo3JPsY9Erow4nYGp22FwSB6I60K6oBY0/xdQpeZ+XfNHRk dKf2RTYeBmHgiEokPhIr8wO+OBU+eBWS3927ColhPnoAV3KqHxzvvw6ugxapfYOb8TR99H/1MY5D Fv0GZDHhPyZ9OOggWogWochV3WsuBgrG/b+I/ws+fRhcCIUw8qe0R8HXBP7vbexbgWHtMQbGVH0p F8O7VgE0EwRod2cfzsvIyVAokpKOqkJAJDjakNR1eCz5F+xjMNH+w/ApanDkTNMlMM22/+KZ3yZo FmR4s0t/gwwO2KnTbi3AjKGE/SSkwO89Ny7fvNr/BfgBfJn6IPjSm+8hRh96HidLM4u9UEl+bKzK w4TElkz0cLqqrSce38wVn+Y/OHTiVYAIgJ6O3bjpSGhaoG4DoOJ0mFamw1qrqYdB12mvdq+WxzD3 oTdbDafo1zmRbalV8XjnZ1YgD+wDr3fXfTt+qfX0qABhujuoUvvhc53JgfpaMrgm3wqGKfo7PbkD fc4B8kKtIT9TmayTAAmQ2bJdKR1ZN8G7OOwX7j660ZW8hz8HPsaVckk3jGln/IpJ4oa7XM+FFGvc 2TXQWGtIa+DXpdcY6gHV7Gxo7otqPbAvRBaZLkiPyk8s2Uz5pnyGbrHADr1up7tO2h2kr1lfDe5R 8Bacg/nsAnDCpiF41u3PnydgrtufEngUjnJai+tLWsEDcNE20nKtu+86eBcMawZkHXGjG9pX4cvW s9j1SvJuvs0AdlJTu0iwMd+w1fikrmwxq2vBh9i5dJZHm8XSBhfcOLJoeUAYIrM1pWUKjFDoDiMc OQGrBrDlnya82Qr6W/g6R8oKQ0S0HL0EKBkrHMRUGC0F5uJqUE9BAFeTnwGH1u5DNUO1gmWMLVTr Ndocaf4RfJzVMIPVXlnZxocLWDhrm9T1a6ljrCL4kudUO4tdik9qsmvArukKtEuj3oFD4qek+8kn /n3dxfjoIdNCz+fUmqtKawB1rCo3SoDMJAgzGvfqsOeMDvJNc44DXKFgJtk9cratsqrAUM2v01Sb 7IBqcdS392S5xLip8AsXfI0pOyQzURug5E0LrStwvQt6H4PJgxXtjPb3Ye79tnYmnUxzOYNvkNmY h7ItmVauzCarSAfU6u071/i3id5NFihVqhxTQXKaNhtkg6wa3Ylsv8OyZJBAhTyI+u7eg9bh8/yB rvpuMABuHBnebkacSm5IWUYVqAOunt42a1WJpcQMnMX2kkrQD4YcXW097Y5ecBZ0FDRruilknJrP 6TF+YjoDqK96tImBW+OR5/rAjtFmi334rKACfsO52t471tWak1rHb0iqiQTx1MG0pMgDMTe/5+M8 nHz2DwaYDETrOYhl3jy66ffb9r76saG77w58Nc2QkWghXITJ4Qk9RC3r9L26lz8Y0519R34qmHt7 C5wdDdcDB2ZFXFUqWejLyXHOCBhT9kouRnSvAMgTLE1bHBeZEHtYEQwiQFR9YnfIqZSfAXwKfN/x 44mxE6OnGscxMUwj+fr/wlMSLYe5HAwUUrdZpd6MIbLYDZEKN0QW/geI3P8DIhjMPno3m0yD+Y1y LJI+oGAaXEx+CurVNZuwNZ6hSeeiV7u0TV7nbkDf973ZK+FteItTCBd66lnFxXnGEqzReCZgKNNX UOx6a2ZmefqCLUGhOw92xz2KEIwn92bXy4GEF5UiDRVL7E1KftaxvGbtFSoXrbGzLLbyMoxCtn8V qC1uxhWi3tTeVtiw4P6fxt8/K+850CdAxJ+kdepjoI031NU+dqVTvK6Z/0RVL7jI+PAh3I+5Yi38 njM81lk/CKizxxJ3CVA4Cd40aANNT2T1IZvJCt6jYAT5e8zFTQEx8gORfHiFLDCLdRn5B3N5snzP XLK81AwqADVizY8WTKXg3DHlBebj9RIHGVhpqMHrp7Uf/aubQSYmoNbNIPcnlzg5InO2Le04ioWV 3Fv2zpqetu5W5zA4BUa0/ekdohM+rW4W6WCxTyrJe/k2PfB74niDbpu7oHdix1do7W7Hh5GXy2Ae uu4JX2WxQ6ci6Mec9mrrEHxmPHpVWFZMopIfmZ5kWlE8XZmG6L8NMboxLoU/MCfD4N84yKpijRTV FNXkO/IqFSCaQq+RKftlO9HGJZAF93/b/tXoGf7omRttt8FlcEY5mNgprZMd2081s/Jhomcmy6RU abKAAeSaVZajjkjrUXzqI1gbLUHRy9q2XQ4Q3Nr9vQjOAI8BfKZ3qJeCUSS4WmMfr6DmwC7DeXpW t5cdFqB9uFo8glbM3uz3Xsb0bSsxm/jGPFOe0SAKjo7ILaTYj/RGk7FgPigqLTYXU+z3LqCLrI2d 0VfPDLSc7+Frq7MycgyZgJegbntHAAdJ9qNfWNgEjvhMR68Lzp7wejDxGrbyO9zplqWvBHuqsV6s KbOXVgFeyzSfqUmw06Df7a4EBgf5VkW+ze1fSLLpUJjFkSkUUmmTor2juamjXdGchmveBU1fpotG J8QurzuPoeYXb/ZC+iCu9lmsQoVen4Pdghs9K8XuqU1IsKYsiAZROclpSRJVDDgMNo8ehB4BH4jO xx4TVWkrsoCc2hMWuWOd/yU4J4yvYHWiJM8mFtvfWVpT61iAKb7QacQ7qQeG8ocWQPKLj3/9LPgm 4t4RvDgeMwouUpeGB26cHFYm9vK7UmrT6wJw7k7LAXhmFPY7GX+bgJcnmFAEEQerTvBBdfV9C1aS XUryvrFa/z81yqB73Z3WXU5yWyVG1x0KxsLL6PB/GnF3Rf++CwqZ7gLGg1z0pnpNrdedh3D3Q7db 5Gc5BaxIPZbs8Hu0jmT35JA3imoMIIxCOhJICzQavSxToksFVHzK8WEBux5+jF7WkKeLatUgkkIV 5JbToR/2D9a1tfFHRjx9SLZ/efFZV1/1uVredLmkfxxmQAu+oWWS4EwVkeA1vd7HfeKTTtK3XGPH 9Za2XiQhCzSpmtEMqoVlgm94Tl1nmdAbni2sFshodkIPzJS44D3pC0m8GemWTtu0uo1FT3pJX3Ou u3K77/5hrf2hW4ufVZKPnnRv+OIaF73FxaDT3SpEoGZ1FzkMQAkMxYZCw1JUw10Mq0y1RbWgCncL 1ZZeM+VAoWpyoNhiGFsEZ6EhbpnJbDTnV6oq8ytBJbDYHf3wWXiX23G70tJppp4QmI+D8RkuxpNM DoZuqQ1QPTZthGAqC8vloqKd7mKsdZDZpXFlWGT08qA/CYXogLmwrKisyFzEsxrMJlBA5eWZdHyl GqY5WFFmiTPmHFoFQ7gdbXfevTHWYeU5ymvLsGayOlC0hjVYUl0INCA/T6PR4X5tDpf2IQvLRLq0 /MBcXmq+p5tXRulJJ+O3CfiPUSYN6RoOmKip+8yG3aNWkg9MdZlgCVaWmF6NotxUWcReyTbgB8Jb ZKdU3cZ+t6L/cBpMn7jB1IfVpwmDaQeFbpJo+6e+8A3IuNd7e5DfMlw1Bu67y4tmgP5vHCI/HKIu +iwHfFhd/am7PR9Skp89WTsVRx7VZaVrTNZjRr6hN7cOawdZpkIWcyJ1HBLXP4DPuHu8f8brNo6X mjxutBlBDlCb5HrZWpTB3QgVOWMAADsPNFVbTllwtKLUZH9hjd51yKK0KCtVa1AEdymsLbQV24CN BxprrMfL8aw9arK52GpoCoUL0HfcmlSrphIXCau9phU3K0buV0hfm1BuqgQ8C6ioqhvCLfFP3IZh c4ULmyCnOYvx40Mmbj85lazq0ppS3NJ22zS4JUonwSGN1r8Ax1jvIP3LdTZwiaK/xdE4nCMy7M6Z fsa5EjROc1u8Ln8Ol37q7iD3v8vJ0egK1IBSGGtHBRBn8/mCDnVLZl+0MwBQq7aH+ytc2c0tja6m 8pKKEouguKrECixUW3fT0Jm2tEP8/SRavS8nP1qUma0Rg2SKHeo/GnV99ETj+et8tv1wRUPWiQXH 8eV7B/AQegXrdklBXpZOrpHmZQEqSXp8RFCOSf9EH5w9+qRFmc6veRNMeu2kN6emxAbKQWdxTT7W cZmK1OBQtAu9yoUx5L/C2u8GUY32f2qg/skLTa+TfN39qvUhBQ+QrY1/ffGjbRf9gJwHNBqjtKQA 6MH0E9C4kzxcqrGt+QFpoJkLg2DA7Zt11tsVPCdyuMkKuOj1Dgbseg5GOlgSkF0nGUXPwlDu53CW s62zrruU50Dr1GRnsc2Es0Cny8yQFJh0Km22xsWVDquOAzuotVs6S3Hg49RVZCeo03Yd+RYt4iIW 8k2NNRiTi3hquNhBSnUV9kqLw+4SfAznfoWE5aYyEzDxgMpYmOyuzk6c3M+fZzx+CP3dH6aTfpFj N1vdz36tVbkRAlTpDr/6YAkOf4aDDClTV4NBCvaSoMxqs1iONY/U9wJqtCkJS5lU3Fnp9UHuUqZw kEGl6npwg4IVZOdIT8MYoK40yHwEKJEEQfn5gUY8Seog08tSy7QNYJAHY0n4dPy1NwJD0wMP8VVX xG2HQBSQanz8qXuksSxUKdYHq93SHTfwM99hvPcQZv+FCVdNvs4pKItRy/KPaHlpbm1UWVoOLIAa qsqLEUzVkZJHyZ9A7gScAV+Cc7d+u2R/YGJ4Nj/EY/BU3/kHZ19HcxAzYq/v4aPNx/hz/u6nd03O djH+7uN+eQlXss4VNOiBDGSZ0g1S9Az6mou48NviirymEjMvr9HkBNWgpdl20f3y4lKSV0psecc3 9/hyhagXLaJnGRsKp59ommot58x4SrGSPFfgUPWvgoemjnMdLLia3gw3TG32dLAewVpbO2TAU87z 1VUXbP/k3Au1d1wMKH7MhKPuZn7PGk8NWVNRXV5e1mCpL8cc3FilThG4nw+T8xW5eeo8TVGMO0wd DnJLaa4NnKboH3Bm76F3wmLGL/ROjmWo7qOqa6CD16RsUMiVKkWuY1n92mmJ+hHdfJcBv3rMpKXw eY62IiFIm3cU8FA+C26Bfl98M/gReMD7edP9l4IPZ8Yl8FPE6pQcv8YC7tCPfd3vAerhlaCNr0eu 3rhOgHajQE8dPd/dxNHv/caAbw4y/0rv4tzqOXkdXKPOJg0eTZIrxCnNyr5KS2lpJd9SBkApZv1K U36yNPFQggAvnFzkYpzG9z6N7709IjU9IdJvQ9ISgJ4CiN2/7C+LT0S0Zp5Pqanjbn5H2iu7J7+l /wj8DH63f9Z2o/1GZ98H49Q/N4ERj5kDaBfn7unO1v6xO3/unW5S4LMJP6yfiD2d3nS4W5fL/cS/ Lal9W8ue6q1gCXhJ6yPbL/VPTdwZOF1b22mPMcbxb2D5l0w6aHIb7qgMgcodoYh4IwCxAJoPNrSt HwkbiLoovwEoOO/xd5hYn93xKSKjsowif0EbXIHpl4BrWykUiwY5j8/uxEiaEb9/1/pD38JXzlnb XQ5BY11XVa9bBZjxx+TK/c0Lrhn0Zkd/jl74//3GZzf+4Tp2dJkFO2+B23cp0oQnvoMh7zAGYQlz ENo4/rDkHTfbQMMI7dHO6PyaeTWTAz3sl5y3z/z20XU4D8AFFPR9BT6FOGjmupfRAjTng02QuDRc d+ICPxZtREwhWplOwatwkgOyC/P0eVJ5gjYRUFsj7sGZV+quNbYK6l3HqjsA9eeTr6It+ABmPXb7 Mz9zUjPSJWnHMjq6Wo91dKW3puKhLj1kwlLIZMCFdNS/T0DI4z8t0rgm+XjLIYyFPSyk+sduz9ss N7h2/QZn4t/JQSbMdo8lH90PDlChvaKTvS3Nx7sUrkQTbviwoC8GoARQ+aZKa09738V+97ORpnXS q5XR8j20f+8Wbz6cYBCTk5AUeFCEyGmYMXrQU6cO9kedk4+Dc2Ckvq93/NIApACcTcGYNfAF5M0v Suc8PIk8kQiJooSvvhr1NxgPk05C5mPBnGwXHeKCwS5W59OPZnZaZ8161DBrNkH8Px3JRp0KZW5k c3RyZWFtCmVuZG9iagoyNyAwIG9iago2Njg4CmVuZG9iagoxMSAwIG9iago8PC9CYXNlRm9udC9B TkFBQUErRjAvRm9udERlc2NyaXB0b3IgMTAgMCBSL1R5cGUvRm9udC9OYW1lL1IxMQovRmlyc3RD aGFyIDAvTGFzdENoYXIgMTIwL1dpZHRoc1sKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjI1MCAwIDAgMCAwIDAgMCAwIDMzMyAz MzMgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMCAwIDAgMCAwCjAgMCAwIDAg NzIyIDY2NyAwIDc3OCAwIDAgMCAwIDAgOTQ0IDAgMAowIDAgMCAwIDAgMCAwIDEwMDAgMCAwIDAg MCAwIDAgMCAwCjAgNTAwIDAgNDQ0IDU1NiA0NDQgMzMzIDUwMCAwIDI3OCAwIDU1NiAyNzggODMz IDU1NiA1MDAKNTU2IDAgNDQ0IDM4OSAzMzMgNTU2IDAgMCA1MDBdCi9FbmNvZGluZy9XaW5BbnNp RW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxMyAwIG9iago8PC9CYXNlRm9udC9ETkFB QUErRjEvRm9udERlc2NyaXB0b3IgMTIgMCBSL1R5cGUvRm9udC9OYW1lL1IxMwovRmlyc3RDaGFy IDAvTGFzdENoYXIgMTQ2L1dpZHRoc1sKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAow IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjI1MCAwIDAgMCAwIDAgMCAxODAgMzMzIDMz MyAwIDAgMjUwIDMzMyAyNTAgMjc4CjUwMCA1MDAgNTAwIDAgMCAwIDUwMCAwIDAgNTAwIDI3OCAw IDAgMCAwIDAKMCA3MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDAg ODg5IDcyMiA3MjIKNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIgMCA5NDQgNzIyIDcyMiAwIDAgMCAw IDAgMAowIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDAgNTAwIDI3OCA3Nzgg NTAwIDUwMAo1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDAgMCAw IDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMzMzIDMzM10KL0VuY29kaW5n L1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjEwIDAgb2JqCjw8L1R5cGUv Rm9udERlc2NyaXB0b3IvRm9udE5hbWUvQU5BQUFBK0YwL0ZvbnRCQm94WzAgLTIwNiA5ODEgNjk0 XS9GbGFncyA0Ci9Bc2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjk0Ci9EZXNjZW50IC0yMDYKL0l0YWxp Y0FuZ2xlIDAKL1N0ZW1WIDE0NwovTWlzc2luZ1dpZHRoIDI1MAovQ2hhclNldCgvbi9jL00vby9k L3AvZS9EL2YvRS9yL2cvcy9HL3QvaS91L2svbC9hL3gvbS9XL3BhcmVubGVmdC9wYXJlbnJpZ2h0 L3NwYWNlL2NvbG9uKS9Gb250RmlsZTMgMjQgMCBSPj4KZW5kb2JqCjEyIDAgb2JqCjw8L1R5cGUv Rm9udERlc2NyaXB0b3IvRm9udE5hbWUvRE5BQUFBK0YxL0ZvbnRCQm94Wy05IC0yMTggOTMyIDY4 M10vRmxhZ3MgNAovQXNjZW50IDY4MwovQ2FwSGVpZ2h0IDY4MwovRGVzY2VudCAtMjE4Ci9JdGFs aWNBbmdsZSAwCi9TdGVtViAxMzkKL01pc3NpbmdXaWR0aCAyNTAKL0NoYXJTZXQoL0EveS9uL2Mv WC9NL0Ivei9vL2QvWS9OL0MvcC9lL08vRC9xL2YvUC9FL3IvZy9RL0Yvcy9oL1IvRy90L2kvUy9I L3UvVC9JL3Yvay9VL0ovdy9sL2EvSy94L20vYi9XL29uZS9xdW90ZXNpbmdsZS90d28vcXVvdGVy aWdodC9wYXJlbmxlZnQvcGFyZW5yaWdodC9zaXgvc3BhY2UvY29tbWEvaHlwaGVuL25pbmUvcGVy aW9kL2NvbG9uL3NsYXNoL3F1b3RlbGVmdC96ZXJvKS9Gb250RmlsZTMgMjYgMCBSPj4KZW5kb2Jq CjIgMCBvYmoKPDwvUHJvZHVjZXIoQUZQTCBHaG9zdHNjcmlwdCA4LjApCi9DcmVhdGlvbkRhdGUo RDoyMDA5MDYwMzE0MTIyMykKL01vZERhdGUoRDoyMDA5MDYwMzE0MTIyMykKL1RpdGxlKE1pY3Jv c29mdCBXb3JkIC0gZGltZS1yZWNoYXJ0ZXIuZG9jKQovQ3JlYXRvcihQU2NyaXB0NS5kbGwgVmVy c2lvbiA1LjIuMikKL0F1dGhvcihERU1TSk4xOCk+PmVuZG9iagp4cmVmCjAgMjgKMDAwMDAwMDAw MCA2NTUzNSBmIAowMDAwMDA5MTI0IDAwMDAwIG4gCjAwMDAwMjE0OTAgMDAwMDAgbiAKMDAwMDAw OTA0MiAwMDAwMCBuIAowMDAwMDA5NDgxIDAwMDAwIG4gCjAwMDAwMDkzMzMgMDAwMDAgbiAKMDAw MDAwOTE3MiAwMDAwMCBuIAowMDAwMDA4NTk0IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAK MDAwMDAwMzc5MyAwMDAwMCBuIAowMDAwMDIwNzg4IDAwMDAwIG4gCjAwMDAwMTk3NTcgMDAwMDAg biAKMDAwMDAyMTA3MyAwMDAwMCBuIAowMDAwMDIwMjEwIDAwMDAwIG4gCjAwMDAwMDkyNjAgMDAw MDAgbiAKMDAwMDAwOTI5MCAwMDAwMCBuIAowMDAwMDA4NzU0IDAwMDAwIG4gCjAwMDAwMDM4MTMg MDAwMDAgbiAKMDAwMDAwNzE5MiAwMDAwMCBuIAowMDAwMDA5NjI4IDAwMDAwIG4gCjAwMDAwMDg4 OTggMDAwMDAgbiAKMDAwMDAwNzIxMyAwMDAwMCBuIAowMDAwMDA4NTczIDAwMDAwIG4gCjAwMDAw MDk2NzEgMDAwMDAgbiAKMDAwMDAwOTcwMyAwMDAwMCBuIAowMDAwMDEyOTQxIDAwMDAwIG4gCjAw MDAwMTI5NjIgMDAwMDAgbiAKMDAwMDAxOTczNiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDI4 IC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCj4+CnN0YXJ0eHJlZgoyMTY5OAolJUVPRgo= ------_=_NextPart_001_01C9E43C.09C3D5A4-- From hannes.tschofenig@nsn.com Wed Jun 3 04:12:44 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523AB3A6ACA for ; Wed, 3 Jun 2009 04:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.909 X-Spam-Level: X-Spam-Status: No, score=-4.909 tagged_above=-999 required=5 tests=[AWL=1.689, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKKaYPrwNPrY for ; Wed, 3 Jun 2009 04:12:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 58C613A6C2D for ; Wed, 3 Jun 2009 04:12:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n53BChuU014887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Jun 2009 13:12:43 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n53BCgcC013135 for ; Wed, 3 Jun 2009 13:12:43 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 13:12:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E43C.369EA944" Date: Wed, 3 Jun 2009 14:14:34 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501684A6D@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for Virtual Interim Meeting Thread-Index: AcnkPHmCW016TAtoQ96mzSPDEUGzJA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 03 Jun 2009 11:12:42.0819 (UTC) FILETIME=[36F86930:01C9E43C] Subject: [Dime] Slides for Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:12:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E43C.369EA944 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In case you have some slides you want to show please send them to me.=20 They will be uploaded to http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim Thanks.=20 Ciao Hannes ------_=_NextPart_001_01C9E43C.369EA944 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Slides for Virtual Interim Meeting

In case you have some slides you want = to show please send them to me.
They will be uploaded to http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim=

Thanks.

Ciao
Hannes

------_=_NextPart_001_01C9E43C.369EA944-- From dromasca@avaya.com Wed Jun 3 04:19:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD63B3A6AAD for ; Wed, 3 Jun 2009 04:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOE4e8HUmeLc for ; Wed, 3 Jun 2009 04:19:58 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 415C03A6D3F for ; Wed, 3 Jun 2009 04:19:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,298,1241409600"; d="scan'208";a="163182226" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 03 Jun 2009 07:19:34 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Jun 2009 07:19:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 13:19:24 +0200 Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501684A47@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Recharter proposal Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQACOYOgAABwDEAAAE498AAAjNNAAASpgZA= References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net><00e601c9e425$ac168650$044392f0$@net><3D3C75174CB95F42AD6BCC56E5555B4501684886@FIESEXC015.nsn-intra.net><00f001c9e428$c498e8f0$4dcabad0$@net> <3D3C75174CB95F42AD6BCC56E5555B4501684A47@FIESEXC015.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Glen Zorn" Cc: dime@ietf.org Subject: Re: [Dime] Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:19:58 -0000 > * Leave room for further work without the need to re-charter=20 > every 6 months. >=20 > The last item is, however, a slippery slope. If we make it=20 > too open then Dan and the IESG will call us crazy.=20 The way to keep the sanity level within reasonable limits is to list in the charter the category of problems that need to be solved by future work so that new milestones can be added without bothering the whole IESG with too many new charters, but yet be clear enough with this list so that the WG does not enter completely new fields of applications that were not originally discussed and approved by the IESG.=20 Dan From gwz@net-zen.net Wed Jun 3 04:31:22 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627A33A6A94 for ; Wed, 3 Jun 2009 04:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzuDXiKu2DxB for ; Wed, 3 Jun 2009 04:31:21 -0700 (PDT) Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by core3.amsl.com (Postfix) with SMTP id 893C43A6842 for ; Wed, 3 Jun 2009 04:31:21 -0700 (PDT) Received: (qmail 8045 invoked from network); 3 Jun 2009 11:31:18 -0000 Received: from unknown (124.122.162.36) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 03 Jun 2009 11:31:17 -0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B450168478E@FIESEXC015.nsn-intra.net><00e601c9e425$ac168650$044392f0$@net><3D3C75174CB95F42AD6BCC56E5555B4501684886@FIESEXC015.nsn-intra.net> <00f001c9e428$c498e8f0$4dcabad0$@net> <021101c9e43c$163d5a20$0301a8c0@nsnintra.net> In-Reply-To: <021101c9e43c$163d5a20$0301a8c0@nsnintra.net> Date: Wed, 3 Jun 2009 18:28:08 +0700 Organization: Network Zen Message-ID: <003001c9e43e$6159f340$240dd9c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkG91g0dMtOKt/Ql6kLUST/wbLfQACOYOgAABwDEAAAE498AAE8KVgAACm47A= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] ERP Milestone -- Was RE: Recharter proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:31:22 -0000 Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] writes: > Hi Glen, > > >BTW, there may be more than one document involved in Diameter > >extensions for hokey & I'd move the completion date for the > >'Diameter Support for EAP Re-authentication Protocol' out a > >bit further than September if I were you ;-). > > You are right. This is a bit ambitious. > > We have 2 options here: > > 1) We move the publication date to something like Jan 2010. That's more reasonable. > > 2) We turn the document type into an Experimental RFC and get it > finished > asap. Then, we hope that someone implements it (mabye even someone from > the > HOKEY/DIME group). This implementation feedback will then be used to > advance > the document to Proposed Standard with a much better quality. Although this may be theoretically possible, I've never heard of it actually happening... > > I personally would like to see more documents that follow approach #2. > Implementing a spec that is has not been published as an RFC yet is > difficult since the documents may change at any time (but that's > another > story...). > > Ciao > Hannes > From hannes.tschofenig@nsn.com Wed Jun 3 04:32:32 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD433A6A94; Wed, 3 Jun 2009 04:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IXSrEQjMEgw; Wed, 3 Jun 2009 04:32:31 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EB3DC3A6842; Wed, 3 Jun 2009 04:32:30 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n53BWKIb000755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2009 13:32:21 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n53BWKtd005270; Wed, 3 Jun 2009 13:32:20 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 13:32:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 14:34:11 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501684AA0@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO writeup for draft-ietf-dime-pmip6-02 Thread-Index: AcnkPzdFz7fLKWnUSv63DOHfb9ZMuw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 03 Jun 2009 11:32:20.0616 (UTC) FILETIME=[F4FDF880:01C9E43E] Cc: dime@ietf.org Subject: [Dime] PROTO writeup for draft-ietf-dime-pmip6-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:32:32 -0000 PROTO Writeup for draft-ietf-dime-pmip6=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://tools.ietf.org/html/draft-ietf-dime-pmip6-02 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Hannes Tschofenig is the document shepherd.=20 The document is ready for publication.=20 Dan Romascanu is the responsible AD.=20 (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was reviewed within the DIME working group and also by members of the NETLMM group.=20 (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? There are no concerns regarding the amount of review.=20 The document will be reviewed by the AAA doctors group in a later publication phase.=20 (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns with the document. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There is consensus within the DIME WG to publish the document.=20 This document is also of interest to the 3GPP to use this specification (i.e., it is listed on the dependency list). (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody stated discontent. =20 (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The ABNF has been checked.=20 The nits have been checked.=20 (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references in the document have been split into normative and informative.=20 (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? IANA considerations exist within the document and are consistent with=20 the body of the document.=20 The document defines 4 new AVPs, registers 3 values in a registry established=20 with RFC 5447 and one value for the Result-Code AVP.=20 (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF in the document is OK. Note that it uses the ABNF defined in RFC 3588 and hence the ABNF checking tools typically produce errors.=20 (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This specification defines the Diameter support for the Proxy Mobile IPv6 and the corresponding mobility service session setup. The policy information needed by the Proxy Mobile IPv6 is defined in mobile node's policy profile, which could be downloaded from the Diameter server to the Mobile Access Gateway once the mobile node attaches to a Proxy Mobile IPv6 Domain and performs access authentication. During the binding update exchange between the Mobile Access Gateway and the Local Mobility Anchor, the Local Mobility Anchor can interact with the Diameter server in order to update the remote policy store with the mobility session related information. Working Group Summary This document was progressed through the DIME working group without=20 delays or problems.=20 Document Quality This document is the product of the DIME working group. We would like=20 to thank the NETLMM working group for their help. It is anticipated that vendors interested in Proxy Mobile IP are also going to implement the client side part of this protocol. The current implementation status=20 of this specification is, however, unknown.=20 Personnel Hannes Tschofenig is the document shepherd for this document.=20 Dan Romascanu is the responsible AD.=20 From hannes.tschofenig@nsn.com Wed Jun 3 04:32:40 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D833A6A89; Wed, 3 Jun 2009 04:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.035 X-Spam-Level: X-Spam-Status: No, score=-5.035 tagged_above=-999 required=5 tests=[AWL=1.564, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYw0tz9wgMN5; Wed, 3 Jun 2009 04:32:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id BC24E3A6842; Wed, 3 Jun 2009 04:32:38 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n53BWUSp000324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jun 2009 13:32:30 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n53BWPMv010117; Wed, 3 Jun 2009 13:32:30 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 13:32:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 14:34:16 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501684AA1@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO writeup for draft-ietf-dime-nai-routing-02 Thread-Index: AcnkPzoEYOU0uRbxQUyKC+dxQtHUaw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 03 Jun 2009 11:32:25.0756 (UTC) FILETIME=[F80E45C0:01C9E43E] Cc: dime@ietf.org Subject: [Dime] PROTO writeup for draft-ietf-dime-nai-routing-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:32:40 -0000 PROTO Writeup for draft-ietf-dime-nai-routing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://tools.ietf.org/html/draft-ietf-dime-nai-routing-02 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Hannes Tschofenig is the document shepherd.=20 The document is ready for publication.=20 Dan Romascanu is the responsible AD.=20 (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was reviewed within the DIME working group.=20 (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? There are no concerns regarding the amount of review.=20 The document will also be reviewed by the AAA doctors group in a later=20 publication phase.=20 (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns with the document. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There is consensus within the DIME WG to publish the document.=20 The members of the group had some discussions regarding procedural aspects, namely whether to progress this document independently or=20 as part of RFC3588bis. The decision was made to progress it independently.=20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody stated extreme discontent. =20 (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The nits have been checked.=20 (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references in the document have been split into normative and informative.=20 (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? This document does not require actions by IANA.=20 (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There is no formal language in the document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm or "Decorated" Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. Working Group Summary The document fixes a small technical aspect and hence it sailed=20 smoothly through the DIME group. Document Quality This document is the product of the DIME working group.=20 The current implementation status of this specification is, however,=20 unknown. We expect implementations to arrive when larger Diameter=20 deployments utilize the RFC 4282 based NAI format.=20 Personnel Hannes Tschofenig is the document shepherd for this document.=20 Dan Romascanu is the responsible AD.=20 From gwz@net-zen.net Wed Jun 3 04:37:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B373A6DFC for ; Wed, 3 Jun 2009 04:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlIPGt8HAvY3 for ; Wed, 3 Jun 2009 04:37:39 -0700 (PDT) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by core3.amsl.com (Postfix) with SMTP id 5DC2C3A6B4C for ; Wed, 3 Jun 2009 04:37:39 -0700 (PDT) Received: (qmail 17409 invoked from network); 3 Jun 2009 11:37:40 -0000 Received: from unknown (124.122.162.36) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 03 Jun 2009 11:37:39 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> Date: Wed, 3 Jun 2009 18:34:30 +0700 Organization: Network Zen Message-ID: <003101c9e43f$450f6840$cf2e38c0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C9E479.F16E4040" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkPEyeIQTIrxvVTr6NCdU2gH1kMQAAl6cA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:37:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C9E479.F16E4040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Maybe I'm just dense, but I'm still not getting this "Submit X as a WG work item" & "Submit X to the IESG" stuff. At very best it is redundant; at worst it introduces circular dependencies into the charter. What if 'X' is not approved by as a work item? It can hardly be submitted for publication, so another milestone update? Just seems more than a little silly to me. ~ gwz Half a loaf is better than no loafing at all. --T-Bone Slim ------=_NextPart_000_0032_01C9E479.F16E4040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME Rechartering (Update)

Maybe I'm just dense, but I'm still not getting this "Submit X as a WG work item" & "Submit X to the = IESG" stuff.  At very best it is redundant; at worst it introduces = circular dependencies into the charter.  What if 'X' is not approved by as a = work item?  It can hardly be submitted for publication, so another = milestone update?  Just seems more than a little silly to = me…

 

~ gwz

 

Half a loaf is better than no loafing at = all.

  --T-Bone Slim

------=_NextPart_000_0032_01C9E479.F16E4040-- From dromasca@avaya.com Wed Jun 3 04:50:20 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BEB28C0F6 for ; Wed, 3 Jun 2009 04:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VrffbnfKLi6 for ; Wed, 3 Jun 2009 04:50:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 0C59B28C0E1 for ; Wed, 3 Jun 2009 04:50:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,298,1241409600"; d="scan'208,217";a="147520730" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Jun 2009 07:49:59 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jun 2009 07:49:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E441.69E71FD1" Date: Wed, 3 Jun 2009 13:49:55 +0200 Message-ID: In-Reply-To: <003101c9e43f$450f6840$cf2e38c0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DIME Rechartering (Update) Thread-Index: AcnkPEyeIQTIrxvVTr6NCdU2gH1kMQAAl6cAAACGJmA= References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> <003101c9e43f$450f6840$cf2e38c0$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "Tschofenig, Hannes (NSN - FI/Espoo)" Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:50:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E441.69E71FD1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is not redundant. One marks that an individual submission draft-author-dime-whatever is good enough to become draft-ietf-dime-whatever-00.txt (WG work item) and the second signal that after the last WGLC was completed the WG agreed that draft-ietf-dime-whatever-xy is now ready to be submitted to the IESG.=20 =20 Dan =20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, June 03, 2009 2:35 PM To: 'Tschofenig, Hannes (NSN - FI/Espoo)' Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) =09 =09 Maybe I'm just dense, but I'm still not getting this "Submit X as a WG work item" & "Submit X to the IESG" stuff. At very best it is redundant; at worst it introduces circular dependencies into the charter. What if 'X' is not approved by as a work item? It can hardly be submitted for publication, so another milestone update? Just seems more than a little silly to me... =20 ~ gwz =20 Half a loaf is better than no loafing at all. --T-Bone Slim ------_=_NextPart_001_01C9E441.69E71FD1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME = Rechartering (Update)
It is=20 not redundant. One marks that an individual=20 submission draft-author-dime-whatever is good enough to=20 become draft-ietf-dime-whatever-00.txt (WG work item) and the = second signal=20 that after the last WGLC was completed the WG agreed that=20 draft-ietf-dime-whatever-xy is now ready to be submitted to the IESG.=20
 
Dan
 

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Glen = Zorn
Sent:=20 Wednesday, June 03, 2009 2:35 PM
To: 'Tschofenig, Hannes = (NSN -=20 FI/Espoo)'
Cc: dime@ietf.org
Subject: Re: [Dime] = DIME=20 Rechartering (Update)

Maybe=20 I'm just dense, but I'm still not getting this "Submit X as a WG work = item"=20 & "Submit X to the IESG" stuff.  At very best it is = redundant; at=20 worst it introduces circular dependencies into the charter.  What = if 'X'=20 is not approved by as a work item?  It can hardly be submitted = for=20 publication, so another milestone update?  Just seems more than a = little=20 silly to me…

 

~=20 gwz

 

Half=20 a loaf is better than no loafing at all.

 =20 --T-Bone = Slim

------_=_NextPart_001_01C9E441.69E71FD1-- From gwz@net-zen.net Wed Jun 3 04:57:03 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F713A6B2F for ; Wed, 3 Jun 2009 04:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op1DGIOLqDeU for ; Wed, 3 Jun 2009 04:57:01 -0700 (PDT) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by core3.amsl.com (Postfix) with SMTP id 3CC863A6A16 for ; Wed, 3 Jun 2009 04:57:01 -0700 (PDT) Received: (qmail 29724 invoked from network); 3 Jun 2009 11:56:39 -0000 Received: from unknown (124.122.162.36) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 03 Jun 2009 11:56:38 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> <003101c9e43f$450f6840$cf2e38c0$@net> In-Reply-To: Date: Wed, 3 Jun 2009 18:53:29 +0700 Organization: Network Zen Message-ID: <004001c9e441$eb8d6850$c2a838f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C9E47C.97EC4050" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkPEyeIQTIrxvVTr6NCdU2gH1kMQAAl6cAAACGJmAAADRFcA== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:57:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C9E47C.97EC4050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It is not redundant. One marks that an individual submission draft-author-dime-whatever is good enough to become draft-ietf-dime-whatever-00.txt (WG work item) and the second signal that after the last WGLC was completed the WG agreed that draft-ietf-dime-whatever-xy is now ready to be submitted to the IESG. I see. Silly me, I had thought that the latter implied the former. ------=_NextPart_000_0041_01C9E47C.97EC4050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME Rechartering (Update)

It is not redundant. One marks that an individual submission draft-author-dime-whatever is good enough to become draft-ietf-dime-whatever-00.txt (WG work item) and the = second signal that after the last WGLC was completed the WG agreed that draft-ietf-dime-whatever-xy is now ready to be submitted to the IESG. =

 

I see.  Silly me, I had thought that the latter = implied the former…

 

------=_NextPart_000_0041_01C9E47C.97EC4050-- From hannes.tschofenig@nsn.com Wed Jun 3 05:00:54 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A82E3A6895 for ; Wed, 3 Jun 2009 05:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PdOBRaUKyrO for ; Wed, 3 Jun 2009 05:00:51 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F19953A6B2F for ; Wed, 3 Jun 2009 05:00:50 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n53C0oxl007825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Jun 2009 14:00:50 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n53C0oqW014313 for ; Wed, 3 Jun 2009 14:00:50 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 14:00:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E442.EF9B115C" Date: Wed, 3 Jun 2009 15:02:41 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501684AF2@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conference Call Details Thread-Index: AcnkQzJqYRWrqsGfSSeupofsFKacgg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 03 Jun 2009 12:00:50.0078 (UTC) FILETIME=[EFE92BE0:01C9E442] Subject: [Dime] Conference Call Details X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 12:00:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E442.EF9B115C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just in case: the conference call details are on the Wiki page:=20 http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim ------_=_NextPart_001_01C9E442.EF9B115C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Conference Call Details

Just in case: the conference call = details are on the Wiki page:
http://trac.tools.ietf.org/wg/dime/trac/wiki/SecondInterim=

------_=_NextPart_001_01C9E442.EF9B115C-- From dromasca@avaya.com Wed Jun 3 05:47:26 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3443A6F5B for ; Wed, 3 Jun 2009 05:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, MANGLED_PENIS=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQfHWuDa58Vv for ; Wed, 3 Jun 2009 05:47:22 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3C7A23A6D5D for ; Wed, 3 Jun 2009 05:47:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,298,1241409600"; d="scan'208";a="147526193" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Jun 2009 08:47:21 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Jun 2009 08:47:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 14:47:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-qos-attributes-11.txt Thread-Index: AcneCjORJ9rC1V8fTg6MsLb7F0ex4wFqccCQACU5djA= References: From: "Romascanu, Dan (Dan)" To: "Mark Jones" , Subject: Re: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 12:47:26 -0000 Thanks, these are fine. Excepting T4 all other edits seem pretty straight forward. I would suggest to revise the ID as soon as possible and then send it to IETF Last Call.=20 Regards, Dan =20 > -----Original Message----- > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com]=20 > Sent: Tuesday, June 02, 2009 10:51 PM > To: Romascanu, Dan (Dan); dime@ietf.org > Subject: RE: AD review of draft-ietf-dime-qos-attributes-11.txt >=20 > Hi Dan >=20 > Thanks for the detailed review. Comments inline.=20 >=20 > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20 > On Behalf=20 > > Of Romascanu, Dan (Dan) > > Sent: May 26, 2009 10:00 AM > > To: dime@ietf.org > > Subject: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt > >=20 > > Please find below my AD review of > > draft-ietf-dime-qos-attributes-11.txt > >=20 > > T are Technical comments, E are editorial.=20 > >=20 > > I believe that the document is in reasonable shape. Function of the=20 > > responses to the review we may decide to do a revised ID or=20 > send it to=20 > > IETF Last Call and consider the comments below as IETF LC comments. > > =20 > > Thanks and Regards, > >=20 > > Dan > >=20 > >=20 > >=20 > >=20 > > T1. IP-Address in 4.15 and 4.16 should not include also a type AVP? > > (IPv4 and IPv6) As written the specification and examples=20 > seem to deal=20 > > with IPv4 only. SO I miss something? > >=20 >=20 > The draft is indeed intended to deal with IPv4 and IPv6. The=20 > IP-Address AVPs in the draft are of Diameter type Address and=20 > so already contain an Address-Type indicator. >=20 > > T2. Was this specification sent for review to IEEE 802.1? I believe=20 > > that it should - maybe during the IETF Last Call,=20 > especially because=20 > > of the VLAN and priority AVPs semantics. For example one of the=20 > > questions to ask is about the usage of the values 0 and 4095 for=20 > > VLAN-IDs. These usually have special semantics in IEEE=20 > 802.1 headers=20 > > and I would suggest that we get expert assessment about=20 > their usage in=20 > > filters. > >=20 >=20 > We sought out an IEEE 802.1 expert contributor (Max Reigel)=20 > and he wrote the VLAN sections in the draft. The VLAN=20 > sections have also been reviewed by the WiMAX folks who are=20 > reusing the Classifier. However, we did not formally request=20 > a review by IEEE 802.1. >=20 > > T3. In Section 5.1 > >=20 > > 0: drop > > 1: shape > > 2: police > > 2: mark > >=20 > > Should be 3: mark I guess > >=20 >=20 > Agreed. This will be resolved in the next revision. >=20 > > T4. Why is not the list of actions in 5.7 (Excess-Traffic-Action)=20 > > consistent with the list of actions in 5.1? > >=20 >=20 > The coauthors are validating an approach to simplify the=20 > Action AVPs and improve consistency/readability. We will=20 > communicate a proposal shortly but do not expect these to=20 > impact any other sections of the draft. >=20 > >=20 > > E1. In section 3.3 the last sentence in the paragraph ('The=20 > lower the=20 > > numerical value of Rule-Precedence AVP, the higher the rule > > precedence.') should come second in the paragraph.=20 > >=20 >=20 > Agreed. This will be resolved in the next revision. >=20 > > E2. Under fig.1 the text speaks about one Unmanaged Terminal, while=20 > > the figure represents multiple Unmanaged Terminals. > >=20 >=20 > Agreed. This will be resolved in the next revision. >=20 > > E3. Section 4.1.4 s/both direction/both directions/ > >=20 >=20 > Agreed. This will be resolved in the next revision. >=20 > > E4. The term ETH priority in 4.1.8.23, 4.1.8.24, and 4.1.8.25 is=20 > > slightly mis-leading. There is no such thing as Ethernet=20 > Priority, on=20 > > an Ethernet there is no priority, and tagged packets are=20 > prioritized=20 > > in the routers or switches. I suggest to drop ETH from the=20 > names and=20 > > to use either 8021 or nothing. > >=20 >=20 > Agreed. We will drop the ETH- prefix in the next revision. >=20 > > E5. in Section 5.3 - Private Enterprise Number (PEN) is a preferred=20 > > term to SMI Network Management Private Enterprise Code > >=20 >=20 > "SMI Network Management Private Enterprise Code" was the term=20 > used in the Diameter Base RFC3588 (and bis) so we used it=20 > here for consistency. We can replace it in the next revision=20 > if the current preference is "Private Enterprise Number (PEN)". >=20 > > E6. The registry policies in the IANA considerations=20 > section should be=20 > > expressed in terms and with reference to RFC 5226. > >=20 >=20 > Agreed. The next version of the draft will add RFC5226 as a=20 > reference and replace: > "A specification is required to add a new value to the registry." > With: > "The definition of new values is subject to the=20 > Specification Required policy [RFC5226]." >=20 >=20 > Thanks > Mark >=20 From dromasca@avaya.com Wed Jun 3 05:52:12 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907023A6F27 for ; Wed, 3 Jun 2009 05:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GehQIcRLiLB5 for ; Wed, 3 Jun 2009 05:52:09 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 41A203A6A04 for ; Wed, 3 Jun 2009 05:52:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,298,1241409600"; d="scan'208,217";a="163192568" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 03 Jun 2009 08:52:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jun 2009 08:52:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E44A.173BEFE7" Date: Wed, 3 Jun 2009 14:52:01 +0200 Message-ID: In-Reply-To: <004001c9e441$eb8d6850$c2a838f0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DIME Rechartering (Update) Thread-Index: AcnkPEyeIQTIrxvVTr6NCdU2gH1kMQAAl6cAAACGJmAAADRFcAACFGUQ References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> <003101c9e43f$450f6840$cf2e38c0$@net> <004001c9e441$eb8d6850$c2a838f0$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "Tschofenig, Hannes (NSN - FI/Espoo)" Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 12:52:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E44A.173BEFE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It does. But they are still two distinct milestones, separated in time by months, and each requiring WG consensus.=20 =20 Dan =20 ________________________________ From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Wednesday, June 03, 2009 2:53 PM To: Romascanu, Dan (Dan); 'Tschofenig, Hannes (NSN - FI/Espoo)' Cc: dime@ietf.org Subject: RE: [Dime] DIME Rechartering (Update) =09 =09 It is not redundant. One marks that an individual submission draft-author-dime-whatever is good enough to become draft-ietf-dime-whatever-00.txt (WG work item) and the second signal that after the last WGLC was completed the WG agreed that draft-ietf-dime-whatever-xy is now ready to be submitted to the IESG.=20 =20 I see. Silly me, I had thought that the latter implied the former... =20 ------_=_NextPart_001_01C9E44A.173BEFE7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME = Rechartering (Update)
It=20 does. But they are still two distinct milestones, separated in time by = months,=20 and each requiring WG consensus.
 
Dan
 

From: Glen Zorn = [mailto:gwz@net-zen.net]=20
Sent: Wednesday, June 03, 2009 2:53 PM
To: = Romascanu, Dan=20 (Dan); 'Tschofenig, Hannes (NSN - FI/Espoo)'
Cc:=20 dime@ietf.org
Subject: RE: [Dime] DIME Rechartering=20 (Update)

It is=20 not redundant. One marks that an individual=20 submission draft-author-dime-whatever is good enough to=20 become draft-ietf-dime-whatever-00.txt (WG work item) and the = second=20 signal that after the last WGLC was completed the WG agreed that=20 draft-ietf-dime-whatever-xy is now ready to be submitted to the IESG.=20

 

I=20 see.  Silly me, I had thought that the latter implied the=20 former…

 

------_=_NextPart_001_01C9E44A.173BEFE7-- From root@core3.amsl.com Wed Jun 3 06:45:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5C18B3A6953; Wed, 3 Jun 2009 06:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090603134501.5C18B3A6953@core3.amsl.com> Date: Wed, 3 Jun 2009 06:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-cmd-iana-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 13:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Updated IANA Considerations for Diameter Command Code Allocations Author(s) : D. Romascanu, H. Tschofenig Filename : draft-ietf-dime-diameter-cmd-iana-00.txt Pages : 10 Date : 2009-06-03 The Diameter Base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands, i.e. messages used by Diameter applications, and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has lead to questionable design decisions by other Standards Development Organizations which chose to define new applications on existing commands rather than asking for assignment of new command codes for the pure purpose of avoiding bringing their specifications to the IETF. In some cases interoperability problems were causes as an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of Diameter application with the Diameter commands offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-diameter-cmd-iana-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-03063839.I-D@ietf.org> --NextPart-- From hannes.tschofenig@nsn.com Wed Jun 3 06:54:49 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758AF3A6CEE for ; Wed, 3 Jun 2009 06:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.121 X-Spam-Level: X-Spam-Status: No, score=-5.121 tagged_above=-999 required=5 tests=[AWL=1.478, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2PpYiFZ1pTa for ; Wed, 3 Jun 2009 06:54:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B65B03A6B97 for ; Wed, 3 Jun 2009 06:54:45 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n53DsjSc005169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Jun 2009 15:54:45 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n53Dsheu031543 for ; Wed, 3 Jun 2009 15:54:45 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 15:54:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 16:56:35 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501684C1B@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Virtual Interim Meeting, 3rd June -- Meeting Minutes Thread-Index: AcnkUxvCgj9y806XQguHwpqL471WKA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 03 Jun 2009 13:54:44.0678 (UTC) FILETIME=[D9A65E60:01C9E452] Subject: [Dime] DIME Virtual Interim Meeting, 3rd June -- Meeting Minutes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 13:54:49 -0000 DIME Virtual Interim Meeting, 3rd June Meeting Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Participants: - Jouni Korhonen - Mark Jones - Dan Romascanu - Glen Zorn - Hannes Tschofenig - Victor Fajardo - Avi Lior Notes:=20 draft-ietf-dime-diameter-api - Dan will put the document on the next telechat=20 (June 18th) after checking the resolved comments.=20 =20 draft-ietf-dime-rfc3588bis - Victor updated the document to reflect discussion during the IETF=20 meeting on Diameter versioning.=20 =20 Discussion about when to finish the document and what the open=20 issues are.=20 Hannes will start working group last call for 4 weeks immediately.=20 The document will be sent for review to Paul Hoffmann (regarding=20 potential problems in the area of internationalization).=20 The group thought it would be useful to have a backup strategy in case the work on RFC3588bis takes too long to progress=20 draft-romascanu-diameter-cmd-iana-00 at the same time.=20 Hannes will re-submit draft-romascanu-diameter-cmd-iana-00 as=20 draft-ietf-dime-diameter-cmd-iana-00 and initiate a WGLC.=20 =20 draft-ietf-dime-qos-attributes - Document is in AD Evaluation. Dan provided a punch of comments. Mark responded to them. =20 Hannes wants to check back with Elwyn regarding the alignment=20 of the Action AVP and the Excess-Treatment AVP.=20 =20 Mark wants to submit the updated document tomorrow.=20 =20 draft-ietf-dime-diameter-qos - Victor did a PROTO shepherd review and posted review comments.=20 Comments have been addressed with recent draft update.=20 Document is in publication requested status. Dan will do his=20 review.=20 draft-ietf-dime-qos-parameters - Document is in RFC Editor Queue.=20 =20 draft-ietf-dime-app-design-guide - Still pending a draft update by Hannes.=20 draft-ietf-dime-erp - Waiting for HOKEY todo their re-chartering to pick up a document regarding the HOKEY/AAA architecture.=20 =20 draft-ietf-dime-pmip6 - PROTO submitted.=20 draft-ietf-dime-mip6-split - Document in RFC Editor Queue draft-ietf-dime-nai-routing - PROTO submitted.=20 Recently, two new documents were added to the DIME milestone list:=20 1) draft-ietf-dime-diameter-base-protocol-mib-00 2) draft-ietf-dime-diameter-cc-appl-mib-00 Glen believes that these documents are ready for WGLC.=20 Dan suggested to start the WGLC immediately and then let the MIB doctors go through them. Dan will also send Hannes some pointers regarding MIB checking tools so that he=20 can do the PROTO writeup properly.=20 New charter proposal update sent out to the mailing list.=20 The conference call participants agreed to review the=20 charter text today. Hannes will submit the updated=20 charter tomorrow. Avi indicated that they have observed congestion problems in=20 Diameter deployments, as described in: http://tools.ietf.org/html/draft-asveren-dime-cong-03 He suggests to re-consider this document for work within=20 the DIME group.=20 --- Let me know if something is missing. From gwz@net-zen.net Wed Jun 3 07:17:21 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F273A6A2A for ; Wed, 3 Jun 2009 07:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPEs4KfI3Ygd for ; Wed, 3 Jun 2009 07:17:21 -0700 (PDT) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id 08A4E3A6B97 for ; Wed, 3 Jun 2009 07:17:20 -0700 (PDT) Received: (qmail 16877 invoked from network); 3 Jun 2009 14:16:58 -0000 Received: from unknown (124.122.162.36) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 03 Jun 2009 14:16:57 -0000 From: "Glen Zorn" To: Date: Wed, 3 Jun 2009 21:13:47 +0700 Organization: Network Zen Message-ID: <006901c9e455$856d84b0$90488e10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkVYKqM1/+y7e7T6eBSoo4nqClZg== Content-Language: en-us Subject: [Dime] comments on http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 14:17:21 -0000 Last sentence of the Abstract, s/causes/caused. Last sentence of Section 1 says: This document has as a goal providing in advance the change in the command codes allocation policy, so that interoperability problems as the ones described above are avoided as soon as possible. Suggest changing to: This document has as a goal providing in advance the change in the command codes allocation policy made in {reference to rfc3588bis}, so that interoperability problems such as those mentioned above may be avoided as much as possible. Reason: no description is given of any interoperability problems. Question: section 4, paragraph 2 says "The values 0-255 (0x00-0xff) are reserved for RADIUS backward compatibility" ; strictly speaking, for backwards compatibility, shouldn't only those command codes that mapped directly to RADIUS messages at the time RFC3588 was published be reserved? Otherwise, it's forward compatibility, too... Section 4, paragraph 3 says "The request to IANA for a Vendor-Specific Command Code SHOULD include a reference to a publicly available specification which documents the command in sufficient detail to aid in interoperability between independent implementations." The word "aid" seems a little weak to me; how about "provide for"? The body of the RADTYPE reference appears to be poorly formatted. ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From Hannes.Tschofenig@gmx.net Wed Jun 3 12:21:01 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781033A6FCE for ; Wed, 3 Jun 2009 12:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4nN5o66MPmo for ; Wed, 3 Jun 2009 12:20:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BA4A63A6D8A for ; Wed, 3 Jun 2009 12:20:52 -0700 (PDT) Received: (qmail invoked by alias); 03 Jun 2009 19:20:48 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp037) with SMTP; 03 Jun 2009 21:20:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/aBwV2L+Taswk6/+NSKc47QJxLj/er1eQwk77xxY gysrdMHsuqsyFu From: "Hannes Tschofenig" To: Date: Wed, 3 Jun 2009 22:22:38 +0300 Message-ID: <02fc01c9e480$a9addb60$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnkgJog2N4hT3bnSIykigJbzmW+hQ== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Subject: [Dime] WGLC: draft-ietf-dime-rfc3588bis-17.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:21:01 -0000 Hi all, This is a Last Call for comments on "Diameter Base Protocol": http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-17.txt Please have comments to the list by Sunday, 5 July. (Note the extended length of the WGLC given the size of the document.) Ciao Hannes From Hannes.Tschofenig@gmx.net Wed Jun 3 12:21:03 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDD63A703D for ; Wed, 3 Jun 2009 12:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Tl7BwPMI-9O for ; Wed, 3 Jun 2009 12:21:03 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7EF943A6929 for ; Wed, 3 Jun 2009 12:21:01 -0700 (PDT) Received: (qmail invoked by alias); 03 Jun 2009 19:21:01 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 03 Jun 2009 21:21:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX189Di5nYHk9OnFOqQnJrqafNAMYkmNWBpnsbUVhmm s0LsyY5qXx0FFn From: "Hannes Tschofenig" To: Date: Wed, 3 Jun 2009 22:22:53 +0300 Message-ID: <02fd01c9e480$b19d4270$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnkgLC9F2Nx9VvvTHCsm07RYfDZxw== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.72 Subject: [Dime] WGLC: draft-ietf-dime-diameter-cmd-iana-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:21:03 -0000 Hi all, This is a Last Call for comments on "Updated IANA Considerations for Diameter Command Code Allocations": http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-00.txt Please have comments to the list by Wednesday, 17 June. Ciao Hannes From Hannes.Tschofenig@gmx.net Wed Jun 3 12:21:23 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0113B28C1C5 for ; Wed, 3 Jun 2009 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pU4CPTlueER for ; Wed, 3 Jun 2009 12:21:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 964AA28C1B0 for ; Wed, 3 Jun 2009 12:21:20 -0700 (PDT) Received: (qmail invoked by alias); 03 Jun 2009 19:21:17 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp041) with SMTP; 03 Jun 2009 21:21:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ZtnYtsEQZQjG+IeOGffgtXZKpyYAOjo8ssoJPnA GgfI6vzfaSgrlg From: "Hannes Tschofenig" To: Date: Wed, 3 Jun 2009 22:23:09 +0300 Message-ID: <02fe01c9e480$baf958e0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FF_01C9E499.E04690E0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnkgLozfVjYN/KjRhCgVkw5Oh9Jjw== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71,0.71 Subject: [Dime] WGLC: draft-ietf-dime-diameter-base-protocol-mib-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:21:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02FF_01C9E499.E04690E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, This is a Last Call for comments on "Diameter Base Protocol MIB": http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-base-protocol-m ib-00.txt Please have comments to the list by Sunday, 21 June. Ciao Hannes ------=_NextPart_000_02FF_01C9E499.E04690E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC: draft-ietf-dime-diameter-base-protocol-mib-00.txt

Hi all,

This is a Last Call for comments = on "Diameter Base Protocol MIB":
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-base-pr= otocol-mib-00.txt

Please have comments to the list = by Sunday, 21 June.

Ciao
Hannes


------=_NextPart_000_02FF_01C9E499.E04690E0-- From Hannes.Tschofenig@gmx.net Wed Jun 3 12:21:39 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A489F28C1A4 for ; Wed, 3 Jun 2009 12:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg2iRhSmzzty for ; Wed, 3 Jun 2009 12:21:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7C7E03A6D8A for ; Wed, 3 Jun 2009 12:21:38 -0700 (PDT) Received: (qmail invoked by alias); 03 Jun 2009 19:21:37 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp011) with SMTP; 03 Jun 2009 21:21:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/sh1ll1ALsS8QLmkFsHHjOxAHN2cm46gkBK8eVQd 0r1/VXRcHC/4Wm From: "Hannes Tschofenig" To: Date: Wed, 3 Jun 2009 22:23:29 +0300 Message-ID: <030301c9e480$c72ef520$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnkgMYYWVNNQhfBT1urFxpESXTNlw== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.72 Subject: [Dime] WGLC: draft-ietf-dime-diameter-cc-appl-mib-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:21:39 -0000 Hi all, This is a Last Call for comments on "Diameter Credit Control Application MIB": http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cc-appl-mib-00. txt Please have comments to the list by Sunday, 21 June. Ciao Hannes From gwz@net-zen.net Thu Jun 4 01:49:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D2D3A69F3 for ; Thu, 4 Jun 2009 01:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zcopB2MgDC7 for ; Thu, 4 Jun 2009 01:49:53 -0700 (PDT) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by core3.amsl.com (Postfix) with SMTP id 9F71E3A6B0E for ; Thu, 4 Jun 2009 01:49:53 -0700 (PDT) Received: (qmail 25391 invoked from network); 4 Jun 2009 08:49:51 -0000 Received: from unknown (124.122.161.219) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 04 Jun 2009 08:49:50 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> Date: Thu, 4 Jun 2009 15:46:39 +0700 Organization: Network Zen Message-ID: <009d01c9e4f0$fc3c6430$f4b52c90$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01C9E52B.A89B3C30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkPEyeIQTIrxvVTr6NCdU2gH1kMQAtHduA Content-Language: en-us Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 08:49:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_009E_01C9E52B.A89B3C30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Looks pretty much OK, I guess, though I'm not sure why the adoption of the Capabilities Update draft as a WG item is put off until July. ------=_NextPart_000_009E_01C9E52B.A89B3C30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME Rechartering (Update)

Looks pretty much OK, I guess, though I'm not sure why = the adoption of the Capabilities Update draft as a WG item is put off until = July…

------=_NextPart_000_009E_01C9E52B.A89B3C30-- From hannes.tschofenig@nsn.com Thu Jun 4 02:53:03 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264073A6B0F for ; Thu, 4 Jun 2009 02:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.227 X-Spam-Level: X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[AWL=1.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6pY638luV-9 for ; Thu, 4 Jun 2009 02:53:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 301C93A6E3A for ; Thu, 4 Jun 2009 02:52:59 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n549qxR6032620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Jun 2009 11:53:00 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n549qvnQ013578; Thu, 4 Jun 2009 11:52:59 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 11:52:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 12:54:48 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501685057@FIESEXC015.nsn-intra.net> In-Reply-To: <009d01c9e4f0$fc3c6430$f4b52c90$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DIME Rechartering (Update) Thread-Index: AcnkPEyeIQTIrxvVTr6NCdU2gH1kMQAtHduAAAJoiZA= References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> <009d01c9e4f0$fc3c6430$f4b52c90$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" , X-OriginalArrivalTime: 04 Jun 2009 09:52:57.0361 (UTC) FILETIME=[3D073810:01C9E4FA] Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 09:53:03 -0000 It takes some time for the rechartering to be finished typically. The IESG is involved etc.=20 Then, it will be July already ... ________________________________ From: ext Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: 04 June, 2009 11:47 To: Tschofenig, Hannes (NSN - FI/Espoo); dime@ietf.org Subject: RE: [Dime] DIME Rechartering (Update) =09 =09 Looks pretty much OK, I guess, though I'm not sure why the adoption of the Capabilities Update draft as a WG item is put off until July... From hannes.tschofenig@nsn.com Thu Jun 4 03:00:47 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F0E3A6C17; Thu, 4 Jun 2009 03:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoSJxI7Wu83T; Thu, 4 Jun 2009 03:00:46 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 99DC728C273; Thu, 4 Jun 2009 03:00:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n54A0igc021710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Jun 2009 12:00:44 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n54A0f0i007143; Thu, 4 Jun 2009 12:00:44 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 12:00:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 13:02:33 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450168506E@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Charter Update Thread-Index: Acnk+5SVr3qWni1CT0KwQ5btQ1CFWQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 04 Jun 2009 10:00:41.0730 (UTC) FILETIME=[51D04E20:01C9E4FB] Cc: dime@ietf.org Subject: [Dime] DIME Charter Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 10:00:47 -0000 Diameter Maintenance and Extensions (dime) Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for=20 authentication, authorization, accounting and provisioning in network access as well as for other applications environments=20 (e.g., IP telephony, mobility).=20 The IETF has completed work on the Diameter Base protocol and is=20 working on revising the base protocol specification. There is on-going=20 work on defining RADIUS extensions and the DIME WG will ensure=20 that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes=20 extensions to Diameter Base protocol that can be considered as enhanced=20 features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide=20 guidelines for design of Diameter extensions. It will detail when to=20 consider reusing an existing application and when to develop a new=20 application. - Diameter QoS extensions. This work focuses on extensions to=20 Diameter to support QoS information to be authorized and provisioned=20 in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs)=20 to configure Diameter entities (such as the Diameter Base protocol or=20 Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and=20 Proxy Mobile IPv6. Diameter extensions to support handover keying=20 developed in the HOKEY WG are part of this effort.=20 - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with=20 a Diameter application for configuring NATs as the first item.=20 Additionally, AAA systems require interoperability in order to work.=20 The working group, along with the AD, will need to evaluate=20 any potential extensions and require verification that the proposed=20 extension is needed. Coordination with other IETF working groups=20 and other SDOs will used to ensure this. Goals and Milestones: Done Submit 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter API' to the IESG for consideration as an Informational RFC=20 Done Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard.=20 Nov 2009 Submit 'Revision of Diameter Base Protocol' to the IESG for consideration as a Proposed Standard=20 Done Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard=20 Done Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item=20 Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item=20 Done Submit 'Diameter Proxy Mobile IPv6' as DIME working group item=20 Done Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard=20 Aug 2009 Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document=20 Done Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard=20 Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard=20 Jan 2010 Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard=20 Jun 2009 Submit new DIME charter to the IESG Jun 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME working group item Nov 2009 Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard From dromasca@avaya.com Thu Jun 4 05:04:39 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B843A6F2C for ; Thu, 4 Jun 2009 05:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ISSEg8hov2W for ; Thu, 4 Jun 2009 05:04:39 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 843653A7079 for ; Thu, 4 Jun 2009 05:04:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,305,1241409600"; d="scan'208";a="172907085" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Jun 2009 08:04:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jun 2009 08:04:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 14:04:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Change of Guard Thread-Index: AcnlDJBcAiuMv/wLSW+zsvrxSRdw/A== From: "Romascanu, Dan (Dan)" To: Cc: Ron Bonica Subject: [Dime] Change of Guard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 12:04:40 -0000 After a couple of years as co-chair of the DIME WG David Frascone changed employers and assignments and had to resign from this position. Allow me to thank David for his work and guidance as WG chair and hope that he will be able to continue to work as an active participant.=20 Victor Fajardo accepted the proposal to become co-chair of the WG. We all know Victor from his important contributions and from his activity as WG Secretary. I would like to thank Victor for assuming this responsibility and wish him, Hannes, and the whole WG success in the activities ahead.=20 Regards, Dan From gwz@net-zen.net Thu Jun 4 06:31:19 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908E23A6E7B for ; Thu, 4 Jun 2009 06:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW+RvJ1v-Hzu for ; Thu, 4 Jun 2009 06:31:18 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id DEFEA3A6BDB for ; Thu, 4 Jun 2009 06:31:18 -0700 (PDT) Received: (qmail 16639 invoked from network); 4 Jun 2009 13:30:39 -0000 Received: from unknown (124.122.161.219) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 04 Jun 2009 13:30:38 -0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" References: <02fc01c9e480$a9addb60$0301a8c0@nsnintra.net> In-Reply-To: <02fc01c9e480$a9addb60$0301a8c0@nsnintra.net> Date: Thu, 4 Jun 2009 20:27:25 +0700 Organization: Network Zen Message-ID: <00f801c9e518$35a6a7e0$a0f3f7a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkgJog2N4hT3bnSIykigJbzmW+hQAl1z4Q Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WGLC: draft-ietf-dime-rfc3588bis-17.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 13:31:19 -0000 My contact information is incorrect. The right stuff is: Glen Zorn Network Zen 1310 East Thomas Street Seattle, WA US Email: gwz@net-zen.net From gwz@net-zen.net Thu Jun 4 06:40:10 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA573A6B5B for ; Thu, 4 Jun 2009 06:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EhWY32urbuw for ; Thu, 4 Jun 2009 06:40:09 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id BA3353A6AF1 for ; Thu, 4 Jun 2009 06:40:09 -0700 (PDT) Received: (qmail 22669 invoked from network); 4 Jun 2009 13:39:44 -0000 Received: from unknown (124.122.161.219) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 04 Jun 2009 13:39:43 -0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" , References: <02fc01c9e480$a9addb60$0301a8c0@nsnintra.net> In-Reply-To: <02fc01c9e480$a9addb60$0301a8c0@nsnintra.net> Date: Thu, 4 Jun 2009 20:36:29 +0700 Organization: Network Zen Message-ID: <00f901c9e519$7a4eaf90$6eec0eb0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkgJog2N4hT3bnSIykigJbzmW+hQAl7tYQ Content-Language: en-us Subject: Re: [Dime] WGLC: draft-ietf-dime-rfc3588bis-17.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 13:40:10 -0000 I think that it might be a good idea to make the Session-Id AVP optional in accounting messages. I'm looking at an application right now, for example, that can only be characterized as an accounting application (in that usage data are sent by a client to a server) but had nothing to do with users (& therefore user sessions). From Hannes.Tschofenig@gmx.net Thu Jun 4 06:54:18 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC303A6A38 for ; Thu, 4 Jun 2009 06:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n8BtPSp1IuH for ; Thu, 4 Jun 2009 06:54:17 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2EEDE3A7091 for ; Thu, 4 Jun 2009 06:53:47 -0700 (PDT) Received: (qmail invoked by alias); 04 Jun 2009 13:52:32 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp007) with SMTP; 04 Jun 2009 15:52:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX188LjZp/908rtHkPNPJmjEZ4PnxXLNfTG1tx608Yc oLyw2tYU3iYVtD From: "Hannes Tschofenig" To: "'Romascanu, Dan \(Dan\)'" , References: Date: Thu, 4 Jun 2009 16:54:23 +0300 Message-ID: <04bc01c9e51b$f8b26b90$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcnlDJBcAiuMv/wLSW+zsvrxSRdw/AADkJLA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Cc: 'Ron Bonica' Subject: Re: [Dime] Change of Guard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 13:54:18 -0000 I would like to thank you Dave for your work of chairing the DIME group with me. It was a pleasure to work with you. I still hope that you have a chance to contribute to the work in the group in the future. It is great to see that Dan and Ron have chosen Victor. Victor has already done an amazing amount of work in the group in his position as the working group secretary, as a Diameter implementer, and as an expert in the Diameter internals. >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Romascanu, Dan (Dan) >Sent: 04 June, 2009 15:04 >To: dime@ietf.org >Cc: Ron Bonica >Subject: [Dime] Change of Guard > >After a couple of years as co-chair of the DIME WG David >Frascone changed employers and assignments and had to resign >from this position. >Allow me to thank David for his work and guidance as WG chair >and hope that he will be able to continue to work as an active >participant. > >Victor Fajardo accepted the proposal to become co-chair of the >WG. We all know Victor from his important contributions and >from his activity as WG Secretary. I would like to thank >Victor for assuming this responsibility and wish him, Hannes, >and the whole WG success in the activities ahead. > >Regards, > >Dan > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From hannes.tschofenig@nsn.com Thu Jun 4 06:56:20 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CDC3A6A38 for ; Thu, 4 Jun 2009 06:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.351 X-Spam-Level: X-Spam-Status: No, score=-5.351 tagged_above=-999 required=5 tests=[AWL=1.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwiR5HXEJiTn for ; Thu, 4 Jun 2009 06:56:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B9EB03A68D7 for ; Thu, 4 Jun 2009 06:56:19 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n54DuANA030825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 4 Jun 2009 15:56:10 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n54Du8Bs014753 for ; Thu, 4 Jun 2009 15:56:10 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 15:56:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 16:57:57 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45016B00DD@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME WG Secretary Job Available Thread-Index: AcnlHHay2cWJJ2KuRgy9aPdKR7ncwg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 04 Jun 2009 13:56:05.0449 (UTC) FILETIME=[3434CB90:01C9E51C] Subject: [Dime] DIME WG Secretary Job Available X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 13:56:21 -0000 Hi all,=20 with Victor becoming the new DIME working group co-chair we unfortunately loose him as the WG secretary. This position is now available. Please drop us a mail if you are interested! Ciao Hannes From gwz@net-zen.net Thu Jun 4 20:07:27 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0223A6A70 for ; Thu, 4 Jun 2009 20:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a29yfXVlJuGL for ; Thu, 4 Jun 2009 20:07:26 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 88EC03A6813 for ; Thu, 4 Jun 2009 20:07:26 -0700 (PDT) Received: (qmail 16899 invoked from network); 5 Jun 2009 03:07:27 -0000 Received: from unknown (124.120.224.45) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 05 Jun 2009 03:07:27 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> <009d01c9e4f0$fc3c6430$f4b52c90$@net> <3D3C75174CB95F42AD6BCC56E5555B4501685057@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501685057@FIESEXC015.nsn-intra.net> Date: Fri, 5 Jun 2009 10:04:13 +0700 Organization: Network Zen Message-ID: <00cf01c9e58a$512c11e0$f38435a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnkPEyeIQTIrxvVTr6NCdU2gH1kMQAtHduAAAJoiZAAI84rgA== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 03:07:27 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] writes: > It takes some time for the rechartering to be finished typically. The > IESG is involved etc. > Then, it will be July already ... Sure, but the problem is that the cut-off for initial version approval for new WG docs is 29 June, so that means that there will be no WG doc until after the Stockholm meeting. It is a soft deadline but nevertheless... ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From tena@huawei.com Fri Jun 5 01:59:12 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A5F3A6812 for ; Fri, 5 Jun 2009 01:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSFvuijs1Vod for ; Fri, 5 Jun 2009 01:59:06 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1E7323A68CD for ; Fri, 5 Jun 2009 01:59:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKR00KQQCUTYC@szxga03-in.huawei.com> for dime@ietf.org; Fri, 05 Jun 2009 16:56:54 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKR009Z3CUTXG@szxga03-in.huawei.com> for dime@ietf.org; Fri, 05 Jun 2009 16:56:53 +0800 (CST) Received: from [192.168.5.105] ([121.34.107.10]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKR00KL2CURU0@szxml01-in.huawei.com>; Fri, 05 Jun 2009 16:56:53 +0800 (CST) Date: Fri, 05 Jun 2009 16:56:50 +0800 From: Tina TSOU In-reply-to: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: multipart/alternative; boundary="Boundary_(ID_ztBVj+Oqb3Kk1tKeveZMcw)" References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 08:59:12 -0000 --Boundary_(ID_ztBVj+Oqb3Kk1tKeveZMcw) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Could the redirect at realm level be included? B. R. Tina http://tinatsou.weebly.com/contact.html On Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Based on the feedback I have updated the text. > <> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_ztBVj+Oqb3Kk1tKeveZMcw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Could the redirect at realm level be included?

On Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

Based on the feedback I have updated the text.
<<dime-recharter.pdf>>

<dime-recharter.pdf>_______________________________________________
DiME mailing list
DiME@ietf.org
https://w ww.ietf.

--Boundary_(ID_ztBVj+Oqb3Kk1tKeveZMcw)-- From Hannes.Tschofenig@gmx.net Fri Jun 5 02:04:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2DB3A685E for ; Fri, 5 Jun 2009 02:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjQOl0KCAOnL for ; Fri, 5 Jun 2009 02:04:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 436D33A691C for ; Fri, 5 Jun 2009 02:03:41 -0700 (PDT) Received: (qmail invoked by alias); 05 Jun 2009 09:03:43 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp053) with SMTP; 05 Jun 2009 11:03:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yG11lWqUysxkOXwZkRCBEee2WI8hHiohLEkPiOB d0f/7cX29SqodE From: "Hannes Tschofenig" To: "'Tina TSOU'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> Date: Fri, 5 Jun 2009 12:05:36 +0300 Message-ID: <01b901c9e5bc$cab965d0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BA_01C9E5D5.F0069DD0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acnlu+iNRVuOsTcoR2OaiZMyTlvBmgAANGbQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6,0.6 Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:04:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01BA_01C9E5D5.F0069DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Could you send the link to the draft around? _____ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tina TSOU Sent: 05 June, 2009 11:57 To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) Could the redirect at realm level be included? http://tinatsou.weebly.com/contact.html On Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Based on the feedback I have updated the text. <> _______________________________________________ DiME mailing list DiME@ietf.org https://w ww.ietf. ------=_NextPart_000_01BA_01C9E5D5.F0069DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Could you send the link to the draft around?=20
 
 

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Tina = TSOU
Sent:=20 05 June, 2009 11:57
To: Tschofenig, Hannes (NSN -=20 FI/Espoo)
Cc: dime@ietf.org
Subject: Re: [Dime] = DIME=20 Rechartering (Update)

Could the redirect at realm level be included?

http://tinatsou.weebly.c= om/contact.html

=


=


On Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo)=20 wrote:

Based on the feedback I have updated = the text.=20
<<dime-recharter.pdf>>=20 =

<dime-recharter.pdf>_________________= ______________________________
DiME=20 mailing list
DiME@ietf.org
https://w = ww.ietf.=20

------=_NextPart_000_01BA_01C9E5D5.F0069DD0-- From tena@huawei.com Fri Jun 5 02:11:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21C13A68CE for ; Fri, 5 Jun 2009 02:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNiJZM-I5lsr for ; Fri, 5 Jun 2009 02:10:59 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 80D563A6B9B for ; Fri, 5 Jun 2009 02:10:58 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKR00K2LDF4YC@szxga03-in.huawei.com> for dime@ietf.org; Fri, 05 Jun 2009 17:09:05 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKR0081RDF3J7@szxga03-in.huawei.com> for dime@ietf.org; Fri, 05 Jun 2009 17:09:04 +0800 (CST) Received: from [192.168.5.105] ([121.34.107.10]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKR0004CDF13Y@szxml01-in.huawei.com>; Fri, 05 Jun 2009 17:09:03 +0800 (CST) Date: Fri, 05 Jun 2009 17:09:01 +0800 From: Tina TSOU In-reply-to: <0074F19FF6F8534E8F74C56BB84397BB04B06792@esealmw118.eemea.ericsson.se> To: Raymond Forbes , "Hannes (NSN - FI/Espoo) Tschofenig" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: multipart/alternative; boundary="Boundary_(ID_bxpLJuFxYZVMdpTqGy5/SA)" References: <0074F19FF6F8534E8F74C56BB84397BB04B06792@esealmw118.eemea.ericsson.se> Cc: dime@ietf.org Subject: Re: [Dime] Any news on the allocation of this Diameter code X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:11:05 -0000 --Boundary_(ID_bxpLJuFxYZVMdpTqGy5/SA) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hannes, Any news? B. R. Tina http://tinatsou.weebly.com/contact.html On Jun 4, 2009, at 6:38 PM, Raymond Forbes wrote: > (183 059-1 R2) DTS/TISPAN-03117-1-NGN- > R2 Tsou > (zou) Frozen 1 > Item 0.5.3 > 10/06/2009 > a2 intf - DIAMETER based > See 21PTD040 (was 21WTD) > > Is there any news on the allocateion of this Diamterer AVP Code by > DIME in the IETF. > > regards, > Ray --Boundary_(ID_bxpLJuFxYZVMdpTqGy5/SA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hannes, 
Any news?



On Jun 4, 2009, at 6:38 PM, Raymond Forbes wrote:

(183 059-1 R2) DTS/TISPAN-03117-1-NGN-R2    &nb sp;                          Tsou (zou)                        Frozen 1 Item                               0.5.3                          10/06/2009

a2 intf - DIAMETER based

See 21PTD040                  &n bsp;&nbs ;          (was 21WTD)

 

Is there any news on the allocateion of this Diamterer AVP Code by DIME in the IETF.

 

regards,

Ray


--Boundary_(ID_bxpLJuFxYZVMdpTqGy5/SA)-- From hannes.tschofenig@nsn.com Fri Jun 5 03:01:01 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B063A6940 for ; Fri, 5 Jun 2009 03:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PJ1sp5+KqtA for ; Fri, 5 Jun 2009 03:01:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C4AF53A68DA for ; Fri, 5 Jun 2009 03:00:59 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n55A0aJx011956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Jun 2009 12:00:36 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n55A0a79001050; Fri, 5 Jun 2009 12:00:36 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 12:00:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jun 2009 13:02:28 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45016B04CC@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Any news on the allocation of this Diameter code Thread-Index: AcnlvY8yEqN0yTaGRVutQmAwDuxODgABwojw References: <0074F19FF6F8534E8F74C56BB84397BB04B06792@esealmw118.eemea.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Tina TSOU" , "Raymond Forbes" X-OriginalArrivalTime: 05 Jun 2009 10:00:35.0655 (UTC) FILETIME=[789B1570:01C9E5C4] Cc: dime@ietf.org Subject: Re: [Dime] Any news on the allocation of this Diameter code X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 10:01:01 -0000 Hi Tina,=20 =20 I have justed dropped a message to Ralph to figure out whether he can clear his DISCUSS. I have addressed his review feedback some time ago already. Then, we are done.=20 =20 Ciao Hannes =20 ________________________________ From: ext Tina TSOU [mailto:tena@huawei.com]=20 Sent: 05 June, 2009 12:09 To: Raymond Forbes; Tschofenig, Hannes (NSN - FI/Espoo) Cc: Fortune HUANG; dime@ietf.org Subject: Re: Any news on the allocation of this Diameter code =09 =09 Hannes,=20 Any news? =09 http://tinatsou.weebly.com/contact.html =09 =09 =09 =09 =09 On Jun 4, 2009, at 6:38 PM, Raymond Forbes wrote: (183 059-1 R2) DTS/TISPAN-03117-1-NGN-R2 Tsou (zou) Frozen 1 Item 0.5.3 10/06/2009 a2 intf - DIAMETER based See 21PTD040 &nbs ; (was 21WTD) =20 Is there any news on the allocateion of this Diamterer AVP Code by DIME in the IETF. =20 regards, Ray =09 From gwz@net-zen.net Fri Jun 5 03:33:27 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA963A6B87 for ; Fri, 5 Jun 2009 03:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9assMqGw0DC for ; Fri, 5 Jun 2009 03:33:26 -0700 (PDT) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id B95CC3A6B16 for ; Fri, 5 Jun 2009 03:33:26 -0700 (PDT) Received: (qmail 23572 invoked from network); 5 Jun 2009 10:33:28 -0000 Received: from unknown (124.121.211.165) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 05 Jun 2009 10:33:27 -0000 From: "Glen Zorn" To: Date: Fri, 5 Jun 2009 17:30:13 +0700 Organization: Network Zen Message-ID: <016501c9e5c8$9e730dd0$db592970$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnlyJskTT2sNOD7QD6P032mKsI+IQ== Content-Language: en-us Subject: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 7-13 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 10:33:27 -0000 EDITORIAL Section 1 Change "Over time, AAA was needed on many new access technologies," to "Over time, AAA support was needed for many new access technologies," Under "Server-initiated messages", change "Support for server-initiated messages is mandatory in" to "Support for server-initiated messages is mandatory in Diameter." Under "Transition support", suggest changing removing the reference to RFC 4005 by changing "This capability, described in [RFC4005], enables Diameter support" to "This capability enables Diameter support"; the translation mechanism in 4005 is broken & will hopefully soon be replaced. Under "Capability negotiation", change "attribute-value pairs" to "Attribute-Value Pairs (AVPs)". Section 1.1 Change "Attribute Value Pairs (AVPs)" to "AVPs". Change "All data delivered by the protocol is in the form of an AVPs." to "All data delivered by the protocol is in the form of AVPs." Suggest changing "AVPs may be added arbitrarily to Diameter messages, so long as the requirements of the message's ABNF (Section 3.2) are met." to "AVPs may be arbitrarily added to Diameter messages, the only restriction being that the Augmented Backus-Naur Form (ABNF, [RFC5234]) Command Code syntax specification (Section 3.2) is satisfied." and deleted the (incorrect) ABNF definition in section 1.2 Change "service specific" to "service-specific" Change "The Diameter base protocol provides the minimum requirements needed for a AAA protocol, as required by [RFC2989]." to "The Diameter base protocol satisfies the minimum requirements for a AAA protocol, as specified by [RFC2989]." Section 1.1.1 The subject of this subsection is, by definition, a moving target; the list of applications is likely to be obsolete almost as soon as the document is published. It would be really nice if we could just point to a stable reference (maybe a BCP?) that would be up-to-date (almost) all the time and just consist of a slightly modified version of this section + references. Change "Note that this document obsoletes [RFC3588]" to "Note that this document obsoletes RFC 3588"; I doubt that it obsoletes the _reference to_ RFC 3588 ;-). Section 1.1.3 In the first sentence, is "deprecates" really the word we want to use? How about "obsoletes" instead? Change "introduced in this document focuses" to "introduced in this document focus" Change "An overview of some the major changes are shown below" to "An overview of some the major changes is given below" Change "Inband-Security AVP exposes certain security risk" to "Inband-Security AVP creates certain security risks" Change "for vendor-specific uses. The new specification relaxes the allocation of command codes for vendor specific uses. See Section 11.2.1 for details." to "for vendor-specific uses (see Section 11.2.1 for details). Change "widely used discovery schemes. The rest has been deprecated. (See Section 5.2 for details)." to "widely used discovery schemes; the rest have been deprecated (see Section 5.2 for details)." Change "clarification on election process" to "clarification of the election process" Change "Result-Code AVP values etc." to "Result-Code AVP values, etc." Section 1.2 Is the definition of AAA really necessary? Seems like the acronym was already defined... If my rewrite suggestion regarding section 1.1 (above) is not accepted, change "Abstracted Backus-Naur Form [RFC5234]" to "Augmented Backus-Naur Form [RFC5234]". Maybe we could use a second-order BNF but we don't have one ;-) ~ gwz Half a loaf is better than no loafing at all. --T-Bone Slim From vfajardo@tari.toshiba.com Fri Jun 5 05:44:09 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442F73A682E for ; Fri, 5 Jun 2009 05:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK4Gw4XVAsQL for ; Fri, 5 Jun 2009 05:44:03 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 4457F3A687C for ; Fri, 5 Jun 2009 05:43:44 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n55ChkI3025415; Fri, 5 Jun 2009 21:43:46 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n55ChkGB018279; Fri, 5 Jun 2009 21:43:46 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id XAA18277; Fri, 5 Jun 2009 21:43:46 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n55ChjLd026989; Fri, 5 Jun 2009 21:43:45 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n55Chjhk000377; Fri, 5 Jun 2009 21:43:45 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n55ChiiH027154; Fri, 5 Jun 2009 21:43:45 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n55ChhvB002577; Fri, 5 Jun 2009 21:43:44 +0900 (JST) 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 n55CirQY008172; Fri, 5 Jun 2009 08:44:53 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4A2912FE.70407@tari.toshiba.com> Date: Fri, 05 Jun 2009 08:43:42 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Glen Zorn References: <016501c9e5c8$9e730dd0$db592970$@net> In-Reply-To: <016501c9e5c8$9e730dd0$db592970$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 7-13 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 12:44:09 -0000 Thanks. I'll incorporate the changes. > EDITORIAL > > Section 1 > Change "Over time, AAA was needed on many new access technologies," to "Over > time, AAA support was needed for many new access technologies," > > Under "Server-initiated messages", change "Support for server-initiated > messages is mandatory in" to "Support for server-initiated messages is > mandatory in Diameter." > > Under "Transition support", suggest changing removing the reference to RFC > 4005 by changing "This capability, described in [RFC4005], enables Diameter > support" to "This capability enables Diameter support"; the translation > mechanism in 4005 is broken & will hopefully soon be replaced. > > Under "Capability negotiation", change "attribute-value pairs" to > "Attribute-Value Pairs (AVPs)". > > > Section 1.1 > Change "Attribute Value Pairs (AVPs)" to "AVPs". > > Change "All data delivered by the protocol is in the form of an AVPs." to > "All data delivered by the protocol is in the form of AVPs." > > Suggest changing "AVPs may be added arbitrarily to Diameter messages, so > long as the requirements of the message's ABNF (Section 3.2) are met." to > "AVPs may be arbitrarily added to Diameter messages, the only restriction > being that the Augmented Backus-Naur Form (ABNF, [RFC5234]) Command Code > syntax specification (Section 3.2) is satisfied." and deleted the > (incorrect) ABNF definition in section 1.2 > > Change "service specific" to "service-specific" > > Change "The Diameter base protocol provides the minimum requirements needed > for a AAA protocol, as required by [RFC2989]." to "The Diameter base > protocol satisfies the minimum requirements for a AAA protocol, as specified > by [RFC2989]." > > > Section 1.1.1 > > The subject of this subsection is, by definition, a moving target; the list > of applications is likely to be obsolete almost as soon as the document is > published. It would be really nice if we could just point to a stable > reference (maybe a BCP?) that would be up-to-date (almost) all the time and > just consist of a slightly modified version of this section + references. > > Change "Note that this document obsoletes [RFC3588]" to "Note that this > document obsoletes RFC 3588"; I doubt that it obsoletes the _reference to_ > RFC 3588 ;-). > > > Section 1.1.3 > > In the first sentence, is "deprecates" really the word we want to use? How > about "obsoletes" instead? > > Change "introduced in this document focuses" to "introduced in this document > focus" > > Change "An overview of some the major changes are shown below" to "An > overview of some the major changes is given below" > > Change "Inband-Security AVP exposes certain security risk" to > "Inband-Security AVP creates certain security risks" > > Change "for vendor-specific uses. The new specification relaxes the > allocation of command codes for vendor specific uses. See Section 11.2.1 > for details." to "for vendor-specific uses (see Section 11.2.1 for details). > > Change "widely used discovery schemes. The rest has been deprecated. (See > Section 5.2 for details)." to "widely used discovery schemes; the rest have > been deprecated (see Section 5.2 for details)." > > Change "clarification on election process" to "clarification of the election > process" > > Change "Result-Code AVP values etc." to "Result-Code AVP values, etc." > > > Section 1.2 > > Is the definition of AAA really necessary? Seems like the acronym was > already defined... > > If my rewrite suggestion regarding section 1.1 (above) is not accepted, > change "Abstracted Backus-Naur Form [RFC5234]" to "Augmented Backus-Naur > Form [RFC5234]". Maybe we could use a second-order BNF but we don't have > one ;-) > > ~ gwz > > Half a loaf is better than no loafing at all. > --T-Bone Slim > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > From gwz@net-zen.net Fri Jun 5 06:46:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84AB63A6B69 for ; Fri, 5 Jun 2009 06:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eeiu+iDIHaQA for ; Fri, 5 Jun 2009 06:46:01 -0700 (PDT) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id BD0083A682B for ; Fri, 5 Jun 2009 06:46:01 -0700 (PDT) Received: (qmail 3738 invoked from network); 5 Jun 2009 13:46:04 -0000 Received: from unknown (124.121.211.165) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 05 Jun 2009 13:46:03 -0000 From: "Glen Zorn" To: "'Victor Fajardo'" References: <016501c9e5c8$9e730dd0$db592970$@net> <4A2912FE.70407@tari.toshiba.com> In-Reply-To: <4A2912FE.70407@tari.toshiba.com> Date: Fri, 5 Jun 2009 20:42:47 +0700 Organization: Network Zen Message-ID: <001001c9e5e3$85c3d330$914b7990$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnl20Xky87yupV8TpmAS+rELiozegAB/6Lg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 7-13 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 13:46:02 -0000 ... > > Section 1.1.1 > > > > The subject of this subsection is, by definition, a moving target; > the list > > of applications is likely to be obsolete almost as soon as the > document is > > published. It would be really nice if we could just point to a > stable > > reference (maybe a BCP?) that would be up-to-date (almost) all the > time and > > just consists of a slightly modified version of this section + > references. > > Any thoughts on this idea? From vfajardo@tari.toshiba.com Fri Jun 5 07:04:40 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09C63A6878 for ; Fri, 5 Jun 2009 07:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki29qAaK1BFK for ; Fri, 5 Jun 2009 07:04:40 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id CED6A3A682B for ; Fri, 5 Jun 2009 07:04:39 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id n55E4fSR010279; Fri, 5 Jun 2009 23:04:41 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id n55E4fFe022685; Fri, 5 Jun 2009 23:04:41 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA22682; Fri, 5 Jun 2009 23:04:41 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id n55E4fAC027506; Fri, 5 Jun 2009 23:04:41 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n55E4fNh009002; Fri, 5 Jun 2009 23:04:41 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n55E4eeM026444; Fri, 5 Jun 2009 23:04:40 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n55E4dsI014420; Fri, 5 Jun 2009 23:04:40 +0900 (JST) Received: from [127.0.0.1] (home.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n55E5nxu008767; Fri, 5 Jun 2009 10:05:49 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4A2925F6.6060800@tari.toshiba.com> Date: Fri, 05 Jun 2009 10:04:38 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Glen Zorn References: <016501c9e5c8$9e730dd0$db592970$@net> <4A2912FE.70407@tari.toshiba.com> <001001c9e5e3$85c3d330$914b7990$@net> In-Reply-To: <001001c9e5e3$85c3d330$914b7990$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 7-13 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 14:04:40 -0000 I tend to agree with you specially since majority of this text refers to diameter applications. I guess the original assumption when this section was first written was that there will be very few diameter applications and its worthwhile referencing them in the base to show their association. Since this is no longer the case, this section does not seem useful other than the reference for the transport profile. > ... > > >>> Section 1.1.1 >>> >>> The subject of this subsection is, by definition, a moving target; >>> >> the list >> >>> of applications is likely to be obsolete almost as soon as the >>> >> document is >> >>> published. It would be really nice if we could just point to a >>> >> stable >> >>> reference (maybe a BCP?) that would be up-to-date (almost) all the >>> >> time and >> >>> just consists of a slightly modified version of this section + >>> >> references. >> > > Any thoughts on this idea? > > > > From frascone@gmail.com Fri Jun 5 07:37:34 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3CB3A6A8B for ; Fri, 5 Jun 2009 07:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kHbGCY44Uo9 for ; Fri, 5 Jun 2009 07:37:33 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 7D37B3A6808 for ; Fri, 5 Jun 2009 07:37:33 -0700 (PDT) Received: by ewy6 with SMTP id 6so2173090ewy.37 for ; Fri, 05 Jun 2009 07:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ECTJJ7IRNQLMT7j0U4VAfWCMGNx/ag3NwpUaafydTeg=; b=O4buAq/SEfko0/5vAup0RGDyc6qtSyEYWZNEfAJUk2ohaLlhqVlX+xQxT2DSJTytAV kJSvXVaR0LAaArmku6H9a9TQsW06zj11v7TXuwI0ZtPIhOaCoP6bZX9i8Nky+H4WTsIv l2Or3uAuA9SiYtBx1FS5eDHikgx2zY8O4tPmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wEKDb7u8CnI0q+Bw/z6EjO49UTqKg9BBWYTvCN3Jnl3KdWq+ecmnJXUzfYLIeJeVbT y2n6VfBWCVRzrnzI7l2mpG7NyTQRsExnWUSclk5haXGBZ36pSmzr4wJRfM8lzPkDzji0 POb8kzc4XJlWkZeC8DD8q5sd+jvl9yzcnqLq4= MIME-Version: 1.0 Sender: frascone@gmail.com Received: by 10.216.36.79 with SMTP id v57mr1250667wea.19.1244212652755; Fri, 05 Jun 2009 07:37:32 -0700 (PDT) In-Reply-To: <04bc01c9e51b$f8b26b90$0301a8c0@nsnintra.net> References: <04bc01c9e51b$f8b26b90$0301a8c0@nsnintra.net> Date: Fri, 5 Jun 2009 10:37:32 -0400 X-Google-Sender-Auth: d3a64296de3b3bda Message-ID: <9cf5ced20906050737i7308d724of63bc498a64fd014@mail.gmail.com> From: David Frascone To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, Ron Bonica Subject: Re: [Dime] Change of Guard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 14:37:34 -0000 Thanks all for the kind words. I will try to continue to be active in the WG, and hope to now be able to focus more time on authoring! -Dave On Thu, Jun 4, 2009 at 9:54 AM, Hannes Tschofenig wrote: > I would like to thank you Dave for your work of chairing the DIME group with > me. It was a pleasure to work with you. I still hope that you have a chance > to contribute to the work in the group in the future. > > It is great to see that Dan and Ron have chosen Victor. Victor has already > done an amazing amount of work in the group in his position as the working > group secretary, as a Diameter implementer, and as an expert in the Diameter > internals. > >>-----Original Message----- >>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >>Behalf Of Romascanu, Dan (Dan) >>Sent: 04 June, 2009 15:04 >>To: dime@ietf.org >>Cc: Ron Bonica >>Subject: [Dime] Change of Guard >> >>After a couple of years as co-chair of the DIME WG David >>Frascone changed employers and assignments and had to resign >>from this position. >>Allow me to thank David for his work and guidance as WG chair >>and hope that he will be able to continue to work as an active >>participant. >> >>Victor Fajardo accepted the proposal to become co-chair of the >>WG. We all know Victor from his important contributions and >>from his activity as WG Secretary. I would like to thank >>Victor for assuming this responsibility and wish him, Hannes, >>and the whole WG success in the activities ahead. >> >>Regards, >> >>Dan >> >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From Mark.Jones@bridgewatersystems.com Fri Jun 5 12:06:19 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F943A68CB for ; Fri, 5 Jun 2009 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_PENIS=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI3-YzHV25jE for ; Fri, 5 Jun 2009 12:06:19 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id B7D253A689C for ; Fri, 5 Jun 2009 12:06:18 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Fri, 5 Jun 2009 15:06:21 -0400 From: Mark Jones To: "Romascanu, Dan (Dan)" , "dime@ietf.org" Date: Fri, 5 Jun 2009 15:06:19 -0400 Thread-Topic: AD review of draft-ietf-dime-qos-attributes-11.txt Thread-Index: AcneCjORJ9rC1V8fTg6MsLb7F0ex4wFqccCQACU5djAAcdfokA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 19:06:20 -0000 Hi Dan, The I-D has been revised and uploaded as draft-ietf-dime-qos-attributes-12.= Comment T4 has been resolved as you suggested (Action and Excess-Treatment= -Action AVPs have been combined in the QoS-Action AVP). Regards Mark > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: June 3, 2009 8:47 AM > To: Mark Jones; dime@ietf.org > Subject: RE: AD review of draft-ietf-dime-qos-attributes-11.txt >=20 > Thanks, these are fine. Excepting T4 all other edits seem pretty > straight forward. I would suggest to revise the ID as soon as possible > and then send it to IETF Last Call.=20 >=20 > Regards, >=20 > Dan > =20 >=20 > > -----Original Message----- > > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com]=20 > > Sent: Tuesday, June 02, 2009 10:51 PM > > To: Romascanu, Dan (Dan); dime@ietf.org > > Subject: RE: AD review of draft-ietf-dime-qos-attributes-11.txt > >=20 > > Hi Dan > >=20 > > Thanks for the detailed review. Comments inline.=20 > >=20 > > > -----Original Message----- > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20 > > On Behalf=20 > > > Of Romascanu, Dan (Dan) > > > Sent: May 26, 2009 10:00 AM > > > To: dime@ietf.org > > > Subject: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt > > >=20 > > > Please find below my AD review of > > > draft-ietf-dime-qos-attributes-11.txt > > >=20 > > > T are Technical comments, E are editorial.=20 > > >=20 > > > I believe that the document is in reasonable shape.=20 > Function of the=20 > > > responses to the review we may decide to do a revised ID or=20 > > send it to=20 > > > IETF Last Call and consider the comments below as IETF LC=20 > comments. > > > =20 > > > Thanks and Regards, > > >=20 > > > Dan > > >=20 > > >=20 > > >=20 > > >=20 > > > T1. IP-Address in 4.15 and 4.16 should not include also a=20 > type AVP? > > > (IPv4 and IPv6) As written the specification and examples=20 > > seem to deal=20 > > > with IPv4 only. SO I miss something? > > >=20 > >=20 > > The draft is indeed intended to deal with IPv4 and IPv6. The=20 > > IP-Address AVPs in the draft are of Diameter type Address and=20 > > so already contain an Address-Type indicator. > >=20 > > > T2. Was this specification sent for review to IEEE 802.1?=20 > I believe=20 > > > that it should - maybe during the IETF Last Call,=20 > > especially because=20 > > > of the VLAN and priority AVPs semantics. For example one of the=20 > > > questions to ask is about the usage of the values 0 and 4095 for=20 > > > VLAN-IDs. These usually have special semantics in IEEE=20 > > 802.1 headers=20 > > > and I would suggest that we get expert assessment about=20 > > their usage in=20 > > > filters. > > >=20 > >=20 > > We sought out an IEEE 802.1 expert contributor (Max Reigel)=20 > > and he wrote the VLAN sections in the draft. The VLAN=20 > > sections have also been reviewed by the WiMAX folks who are=20 > > reusing the Classifier. However, we did not formally request=20 > > a review by IEEE 802.1. > >=20 > > > T3. In Section 5.1 > > >=20 > > > 0: drop > > > 1: shape > > > 2: police > > > 2: mark > > >=20 > > > Should be 3: mark I guess > > >=20 > >=20 > > Agreed. This will be resolved in the next revision. > >=20 > > > T4. Why is not the list of actions in 5.7 (Excess-Traffic-Action)=20 > > > consistent with the list of actions in 5.1? > > >=20 > >=20 > > The coauthors are validating an approach to simplify the=20 > > Action AVPs and improve consistency/readability. We will=20 > > communicate a proposal shortly but do not expect these to=20 > > impact any other sections of the draft. > >=20 > > >=20 > > > E1. In section 3.3 the last sentence in the paragraph ('The=20 > > lower the=20 > > > numerical value of Rule-Precedence AVP, the higher the rule > > > precedence.') should come second in the paragraph.=20 > > >=20 > >=20 > > Agreed. This will be resolved in the next revision. > >=20 > > > E2. Under fig.1 the text speaks about one Unmanaged=20 > Terminal, while=20 > > > the figure represents multiple Unmanaged Terminals. > > >=20 > >=20 > > Agreed. This will be resolved in the next revision. > >=20 > > > E3. Section 4.1.4 s/both direction/both directions/ > > >=20 > >=20 > > Agreed. This will be resolved in the next revision. > >=20 > > > E4. The term ETH priority in 4.1.8.23, 4.1.8.24, and 4.1.8.25 is=20 > > > slightly mis-leading. There is no such thing as Ethernet=20 > > Priority, on=20 > > > an Ethernet there is no priority, and tagged packets are=20 > > prioritized=20 > > > in the routers or switches. I suggest to drop ETH from the=20 > > names and=20 > > > to use either 8021 or nothing. > > >=20 > >=20 > > Agreed. We will drop the ETH- prefix in the next revision. > >=20 > > > E5. in Section 5.3 - Private Enterprise Number (PEN) is a=20 > preferred=20 > > > term to SMI Network Management Private Enterprise Code > > >=20 > >=20 > > "SMI Network Management Private Enterprise Code" was the term=20 > > used in the Diameter Base RFC3588 (and bis) so we used it=20 > > here for consistency. We can replace it in the next revision=20 > > if the current preference is "Private Enterprise Number (PEN)". > >=20 > > > E6. The registry policies in the IANA considerations=20 > > section should be=20 > > > expressed in terms and with reference to RFC 5226. > > >=20 > >=20 > > Agreed. The next version of the draft will add RFC5226 as a=20 > > reference and replace: > > "A specification is required to add a new value to the=20 > registry." > > With: > > "The definition of new values is subject to the=20 > > Specification Required policy [RFC5226]." > >=20 > >=20 > > Thanks > > Mark > >=20 > = From root@core3.amsl.com Fri Jun 5 12:15:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 48B813A6898; Fri, 5 Jun 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090605191501.48B813A6898@core3.amsl.com> Date: Fri, 5 Jun 2009 12:15:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 19:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Attributes for Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-12.txt Pages : 42 Date : 2009-06-05 This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-05120147.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Sun Jun 7 06:04:15 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F9A3A6BEA; Sun, 7 Jun 2009 06:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQkDbHooZKko; Sun, 7 Jun 2009 06:04:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 77A473A6BE0; Sun, 7 Jun 2009 06:04:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,319,1241409600"; d="scan'208";a="173169130" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Jun 2009 09:04:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jun 2009 09:04:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Jun 2009 15:04:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard Thread-Index: AcnmFRUp5Uq3IbPsR8KuYhAOimg0XABW0k8g From: "Romascanu, Dan (Dan)" To: , "radext mailing list" , Subject: [Dime] FW: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 13:04:15 -0000 =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 05, 2009 10:37 PM To: IETF-Announce Cc: geopriv mailing list; geopriv chair; Internet Architecture Board; RFC Editor Subject: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard=20 The IESG has approved the following document: - 'Carrying Location Objects in RADIUS and Diameter ' as a Proposed Standard This document is the product of the Geographic Location/Privacy Working Group.=20 The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-24.txt Technical Summary This document specifies RADIUS attributes for conveying access network location information, in both civic and geospatial location formats, along with access network ownership. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed throughout, for various scenarios of location information function within AAA. WG Summary The WG reached solid consensus to advance this document after a number of iterations. The WG had initial hesitation about taking on the work, because the RFC 4119 pidf_lo object could not be used within RADIUS attribute size constraints. The WG concerns were met with an eventual functional compromise, providing a mandated attribute with the pidf_lo policy markers, and opaque attributes pointing to the geopriv location formats developed for DHCP which had constraints similar to RADIUS. =20 This document is a Critical Requirement for 3GPP. Both the GSM Association and the ITU have specified Operator Namespace Tokens for use in this protocol. (The document has customers). Document Quality The protocol was reviewed in depth by both the GEOPRIV and RADEXT Working Groups. RADEXT's formal issues list was cleared. GEOPRIV and RADEXT had some overlapping issues, especially location information design, and scenario evaluation. The conclusion that location- aware AAA systems need to be able to implement the formats and processing found in the GEOPRIV documents was very useful, because it meant that GEOPRIV did not have to intercept or anticipate any enhancements of the RADIUS data model.=20 The document is especially careful in projecting GEOPRIV's paranoia towards exposing location information. Section 8.3 contains a detailed review against the previously defined requirements related to this, and the Security Considerations details the use of security services RADIUS provides as the using protocol to meet requirements. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Sun Jun 7 06:13:33 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE313A6BF2 for ; Sun, 7 Jun 2009 06:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_00=-2.599, MANGLED_PENIS=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xxi-DoIwITFn for ; Sun, 7 Jun 2009 06:13:32 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 8919E3A69C0 for ; Sun, 7 Jun 2009 06:13:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,319,1241409600"; d="scan'208";a="163558763" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 07 Jun 2009 09:13:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 07 Jun 2009 09:13:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Jun 2009 15:13:28 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-qos-attributes-11.txt Thread-Index: AcneCjORJ9rC1V8fTg6MsLb7F0ex4wFqccCQACU5djAAcdfokABYWxzQ References: From: "Romascanu, Dan (Dan)" To: "Mark Jones" , Subject: Re: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 13:13:33 -0000 Thanks, Mark. I am sending this to IETF Last Call.=20 Dan =20 > -----Original Message----- > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com]=20 > Sent: Friday, June 05, 2009 10:06 PM > To: Romascanu, Dan (Dan); dime@ietf.org > Subject: RE: AD review of draft-ietf-dime-qos-attributes-11.txt >=20 > Hi Dan, >=20 > The I-D has been revised and uploaded as=20 > draft-ietf-dime-qos-attributes-12. Comment T4 has been=20 > resolved as you suggested (Action and Excess-Treatment-Action=20 > AVPs have been combined in the QoS-Action AVP). >=20 > Regards > Mark >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: June 3, 2009 8:47 AM > > To: Mark Jones; dime@ietf.org > > Subject: RE: AD review of draft-ietf-dime-qos-attributes-11.txt > >=20 > > Thanks, these are fine. Excepting T4 all other edits seem pretty=20 > > straight forward. I would suggest to revise the ID as soon=20 > as possible=20 > > and then send it to IETF Last Call. > >=20 > > Regards, > >=20 > > Dan > > =20 > >=20 > > > -----Original Message----- > > > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] > > > Sent: Tuesday, June 02, 2009 10:51 PM > > > To: Romascanu, Dan (Dan); dime@ietf.org > > > Subject: RE: AD review of draft-ietf-dime-qos-attributes-11.txt > > >=20 > > > Hi Dan > > >=20 > > > Thanks for the detailed review. Comments inline.=20 > > >=20 > > > > -----Original Message----- > > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > > > On Behalf > > > > Of Romascanu, Dan (Dan) > > > > Sent: May 26, 2009 10:00 AM > > > > To: dime@ietf.org > > > > Subject: [Dime] AD review of=20 > draft-ietf-dime-qos-attributes-11.txt > > > >=20 > > > > Please find below my AD review of > > > > draft-ietf-dime-qos-attributes-11.txt > > > >=20 > > > > T are Technical comments, E are editorial.=20 > > > >=20 > > > > I believe that the document is in reasonable shape.=20 > > Function of the > > > > responses to the review we may decide to do a revised ID or > > > send it to > > > > IETF Last Call and consider the comments below as IETF LC > > comments. > > > > =20 > > > > Thanks and Regards, > > > >=20 > > > > Dan > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > T1. IP-Address in 4.15 and 4.16 should not include also a > > type AVP? > > > > (IPv4 and IPv6) As written the specification and examples > > > seem to deal > > > > with IPv4 only. SO I miss something? > > > >=20 > > >=20 > > > The draft is indeed intended to deal with IPv4 and IPv6. The=20 > > > IP-Address AVPs in the draft are of Diameter type Address and so=20 > > > already contain an Address-Type indicator. > > >=20 > > > > T2. Was this specification sent for review to IEEE 802.1?=20 > > I believe > > > > that it should - maybe during the IETF Last Call, > > > especially because > > > > of the VLAN and priority AVPs semantics. For example one of the=20 > > > > questions to ask is about the usage of the values 0 and=20 > 4095 for=20 > > > > VLAN-IDs. These usually have special semantics in IEEE > > > 802.1 headers > > > > and I would suggest that we get expert assessment about > > > their usage in > > > > filters. > > > >=20 > > >=20 > > > We sought out an IEEE 802.1 expert contributor (Max=20 > Reigel) and he=20 > > > wrote the VLAN sections in the draft. The VLAN sections have also=20 > > > been reviewed by the WiMAX folks who are reusing the Classifier.=20 > > > However, we did not formally request a review by IEEE 802.1. > > >=20 > > > > T3. In Section 5.1 > > > >=20 > > > > 0: drop > > > > 1: shape > > > > 2: police > > > > 2: mark > > > >=20 > > > > Should be 3: mark I guess > > > >=20 > > >=20 > > > Agreed. This will be resolved in the next revision. > > >=20 > > > > T4. Why is not the list of actions in 5.7=20 > (Excess-Traffic-Action)=20 > > > > consistent with the list of actions in 5.1? > > > >=20 > > >=20 > > > The coauthors are validating an approach to simplify the=20 > Action AVPs=20 > > > and improve consistency/readability. We will communicate=20 > a proposal=20 > > > shortly but do not expect these to impact any other=20 > sections of the=20 > > > draft. > > >=20 > > > >=20 > > > > E1. In section 3.3 the last sentence in the paragraph ('The > > > lower the > > > > numerical value of Rule-Precedence AVP, the higher the rule > > > > precedence.') should come second in the paragraph.=20 > > > >=20 > > >=20 > > > Agreed. This will be resolved in the next revision. > > >=20 > > > > E2. Under fig.1 the text speaks about one Unmanaged > > Terminal, while > > > > the figure represents multiple Unmanaged Terminals. > > > >=20 > > >=20 > > > Agreed. This will be resolved in the next revision. > > >=20 > > > > E3. Section 4.1.4 s/both direction/both directions/ > > > >=20 > > >=20 > > > Agreed. This will be resolved in the next revision. > > >=20 > > > > E4. The term ETH priority in 4.1.8.23, 4.1.8.24, and=20 > 4.1.8.25 is=20 > > > > slightly mis-leading. There is no such thing as Ethernet > > > Priority, on > > > > an Ethernet there is no priority, and tagged packets are > > > prioritized > > > > in the routers or switches. I suggest to drop ETH from the > > > names and > > > > to use either 8021 or nothing. > > > >=20 > > >=20 > > > Agreed. We will drop the ETH- prefix in the next revision. > > >=20 > > > > E5. in Section 5.3 - Private Enterprise Number (PEN) is a > > preferred > > > > term to SMI Network Management Private Enterprise Code > > > >=20 > > >=20 > > > "SMI Network Management Private Enterprise Code" was the=20 > term used=20 > > > in the Diameter Base RFC3588 (and bis) so we used it here for=20 > > > consistency. We can replace it in the next revision if=20 > the current=20 > > > preference is "Private Enterprise Number (PEN)". > > >=20 > > > > E6. The registry policies in the IANA considerations > > > section should be > > > > expressed in terms and with reference to RFC 5226. > > > >=20 > > >=20 > > > Agreed. The next version of the draft will add RFC5226 as a=20 > > > reference and replace: > > > "A specification is required to add a new value to the > > registry." > > > With: > > > "The definition of new values is subject to the Specification=20 > > > Required policy [RFC5226]." > > >=20 > > >=20 > > > Thanks > > > Mark > > >=20 > >=20 >=20 From sdecugis@nict.go.jp Sun Jun 7 20:57:20 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9319B3A6863; Sun, 7 Jun 2009 20:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j1V13q2D+Kn; Sun, 7 Jun 2009 20:57:19 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 280813A67A8; Sun, 7 Jun 2009 20:57:18 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n583vMZ8004888; Mon, 8 Jun 2009 12:57:22 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n583vMIT016666; Mon, 8 Jun 2009 12:57:22 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n583vMxt016663; Mon, 8 Jun 2009 12:57:22 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 08B6816AE6; Mon, 8 Jun 2009 12:57:22 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 0344516ADE; Mon, 8 Jun 2009 12:57:22 +0900 (JST) Message-ID: <4A2C8C10.1010507@nict.go.jp> Date: Mon, 08 Jun 2009 12:57:04 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hokey@ietf.org Subject: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 03:57:20 -0000 Hi all DIME and HOKEY members, I have gone forward on the Diameter ERP topic and created a new draft [1] with the same content (re-organized, hopefully for clarity) as I presented during last DIME meeting in IETF#74. The main change with current draft-ietf-dime-erp-00 is the use of a new separate Diameter application for messages exchanged between the NAS and the ER server. I would like to poll the people interested in this topic about the adoption of this new document for Diameter ERP (in which case it would become draft-ietf-dime-erp-01). I don't know if this can be done before the next IETF meeting, or at least during the meeting in Stockholm? Thank you for reading, and eventually providing your comments. Sebastien. [1] http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01.txt -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Sun Jun 7 21:51:57 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2683A6A2B for ; Sun, 7 Jun 2009 21:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh+nZPHwrWKo for ; Sun, 7 Jun 2009 21:51:56 -0700 (PDT) Received: from smtpout07.prod.mesa1.secureserver.net (smtpout07-01.prod.mesa1.secureserver.net [64.202.165.230]) by core3.amsl.com (Postfix) with SMTP id C2EB23A695D for ; Sun, 7 Jun 2009 21:51:56 -0700 (PDT) Received: (qmail 21361 invoked from network); 8 Jun 2009 04:52:01 -0000 Received: from unknown (124.120.218.16) by smtpout07.prod.mesa1.secureserver.net (64.202.165.230) with ESMTP; 08 Jun 2009 04:52:01 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4A2C8C10.1010507@nict.go.jp> In-Reply-To: <4A2C8C10.1010507@nict.go.jp> Date: Mon, 8 Jun 2009 11:48:44 +0700 Organization: Network Zen Message-ID: <001301c9e7f4$6a2b9f50$3e82ddf0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnn7T1kE4xpG74uSaGCX88O4LTy4wABaL/w Content-Language: en-us Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 04:51:57 -0000 > Hi all DIME and HOKEY members, > > I have gone forward on the Diameter ERP topic and created a new draft > [1] with the same content (re-organized, hopefully for clarity) as I > presented during last DIME meeting in IETF#74. The main change with > current draft-ietf-dime-erp-00 is the use of a new separate Diameter > application for messages exchanged between the NAS and the ER server. > > I would like to poll the people interested in this topic about the > adoption of this new document for Diameter ERP (in which case it would > become draft-ietf-dime-erp-01). Isn't this the job of the WG Chairs? > I don't know if this can be done before > the next IETF meeting, or at least during the meeting in Stockholm? I am strongly opposed to the adoption of this draft as a WG item, if for no other reason than that it is clearly derived from other work (as is admitted in section 1.1), the authors of which are not recognized. Add Wu, Bournelle, Morand & Dondeti to the author list (provided that they agree, of course). BTW, "disappearing" co-authors is one good way to ensure that no one agrees to collaborate with you in the future... > > Thank you for reading, and eventually providing your comments. > Sebastien. > > [1] > http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp- > 01.txt > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Sun Jun 7 22:13:55 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2A73A6868; Sun, 7 Jun 2009 22:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, FRT_SOMA2=2.199, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnM8QqboV35T; Sun, 7 Jun 2009 22:13:54 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 382123A67F3; Sun, 7 Jun 2009 22:13:53 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n585DvAm006880; Mon, 8 Jun 2009 14:13:57 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n585Dvcn008706; Mon, 8 Jun 2009 14:13:57 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n585DvuW008703; Mon, 8 Jun 2009 14:13:57 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 51ADA169BC; Mon, 8 Jun 2009 14:13:57 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 4C8C8169BB; Mon, 8 Jun 2009 14:13:57 +0900 (JST) Message-ID: <4A2C9E02.3000807@nict.go.jp> Date: Mon, 08 Jun 2009 14:13:38 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glen Zorn References: <4A2C8C10.1010507@nict.go.jp> <001301c9e7f4$6a2b9f50$3e82ddf0$@net> In-Reply-To: <001301c9e7f4$6a2b9f50$3e82ddf0$@net> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] [SPAM] RE: New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 05:13:55 -0000 Hello, Thank you for quick answer. Glen Zorn a écrit : >> I would like to poll the people interested in this topic about the >> adoption of this new document for Diameter ERP (in which case it would >> become draft-ietf-dime-erp-01). >> > Isn't this the job of the WG Chairs? > Ok, I did not know. My intent is just to provide this new idea for workgroup consideration, within the scope of the Diameter ERP topic that is already a workgroup item. >> I don't know if this can be done before >> the next IETF meeting, or at least during the meeting in Stockholm? >> > > I am strongly opposed to the adoption of this draft as a WG item, if for no > other reason than that it is clearly derived from other work (as is admitted > in section 1.1), the authors of which are not recognized. Add Wu, > Bournelle, Morand & Dondeti to the author list (provided that they agree, of > course). BTW, "disappearing" co-authors is one good way to ensure that no > one agrees to collaborate with you in the future... > The authors of the previous draft are listed in contributors section. As you mention, I don't know if they agree with the content of this new draft, hence they are not listed as authors for this submission. Anyway, in case the document is accepted (for its ideas, not its form...) the authors list would be restored of course. I am not doing this to steal the work of other people, just trying to push a new different idea to move the document forward. And I already tried to involve in this new direction the other co-authors of the previous draft, but got no answer, hence my separate submission. Sorry for the apparently tactless process, I hope my intent is now clarified. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From glenzorn@comcast.net Sun Jun 7 23:23:47 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3AAC3A6955 for ; Sun, 7 Jun 2009 23:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVG2hE3AWrSM for ; Sun, 7 Jun 2009 23:23:47 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id D1DA73A6A8C for ; Sun, 7 Jun 2009 23:23:45 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 1JPd1c0031GhbT854JPq30; Mon, 08 Jun 2009 06:23:50 +0000 Received: from gwzPC ([124.121.211.14]) by OMTA07.westchester.pa.mail.comcast.net with comcast id 1JPF1c0030KBaWL3TJPP7f; Mon, 08 Jun 2009 06:23:45 +0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4A2C8C10.1010507@nict.go.jp> <001301c9e7f4$6a2b9f50$3e82ddf0$@net> <4A2C9E02.3000807@nict.go.jp> In-Reply-To: <4A2C9E02.3000807@nict.go.jp> Date: Mon, 8 Jun 2009 13:20:01 +0700 Message-ID: <002601c9e801$3a018800$ae049800$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnn9/M0eKB8pisfSMKjUbKJAFMLngAB1K6A Content-Language: en-us Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] [HOKEY] [SPAM] RE: New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 06:23:47 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: ... > > I am strongly opposed to the adoption of this draft as a WG item, if > for no > > other reason than that it is clearly derived from other work (as is > admitted > > in section 1.1), the authors of which are not recognized. Add Wu, > > Bournelle, Morand & Dondeti to the author list (provided that they > agree, of > > course). BTW, "disappearing" co-authors is one good way to ensure > that no > > one agrees to collaborate with you in the future... > > > The authors of the previous draft are listed in contributors section. > As > you mention, I don't know if they agree with the content of this new > draft, hence they are not listed as authors for this submission. > Anyway, > in case the document is accepted (for its ideas, not its form...) the > authors list would be restored of course. I am not doing this to steal > the work of other people, just trying to push a new different idea to > move the document forward. And I already tried to involve in this new > direction the other co-authors of the previous draft, but got no > answer, > hence my separate submission. I see. Maybe they will respond now! > > Sorry for the apparently tactless process, I hope my intent is now > clarified. Re-reading my response above, it appears that I was the one w/o tact! I didn't mean to suggest any nefarious intent on your part, please accept my apology. ... From jouni.nospam@gmail.com Mon Jun 8 00:00:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C703A6C81; Mon, 8 Jun 2009 00:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRnZatdGj3SM; Mon, 8 Jun 2009 00:00:36 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id D1F8D3A6A0D; Mon, 8 Jun 2009 00:00:35 -0700 (PDT) Received: by ewy6 with SMTP id 6so3894285ewy.37 for ; Mon, 08 Jun 2009 00:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=NebxS6r0TQ/nphuJn48XQW0znapjUfDScaXGskJfvfY=; b=BTEWOEJJAoY3PVxTnqT5DMqcD7jUKGgGcTuO0lN8mx17rsfemH+eKirE24vKAkSVdZ dN+YZw1hX2ODNqLUu9SbMSAPsToQwg9C5yJSJ2EPzxiWYJeyJTWG9Hr+HtoIOtoFls8W 93Azk9LQbxbC3uuP5kMWu9lbjsx1AmQnDQxCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Wwef7QTo95EYgW0maS5BAFO01VX3Zko2B8PTwKdygtgaWrGwa+G1BRlsS5Nb1/2qfN FYAl4OJCRVxWPZ/H5C9iLSzv8ipk7zT4P9tvpAeGiSgriPi0dA/OD1X0OyMz+8oI7qBo kBiLDv+rEC6sEubY0E2IfjpVBRJ1H6e23bRNs= Received: by 10.216.18.199 with SMTP id l49mr2155263wel.23.1244444437844; Mon, 08 Jun 2009 00:00:37 -0700 (PDT) Received: from ?10.183.198.57? ([192.100.124.156]) by mx.google.com with ESMTPS id i6sm8705919gve.22.2009.06.08.00.00.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 00:00:36 -0700 (PDT) Message-Id: <4F72CB70-846C-474A-9B3C-C1ED6083766B@gmail.com> From: jouni korhonen To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450168506E@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 8 Jun 2009 10:00:34 +0300 References: <3D3C75174CB95F42AD6BCC56E5555B450168506E@FIESEXC015.nsn-intra.net> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org, iesg-secretary@ietf.org Subject: Re: [Dime] DIME Charter Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 07:00:37 -0000 Hi, Some comments/questions on the proposed charter. On Jun 4, 2009, at 1:02 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Diameter Maintenance and Extensions (dime) > > Description of Working Group: > > The Diameter Maintenance and Extensions WG will focus on maintenance > and extensions to the Diameter protocol required to enable its use for > authentication, authorization, accounting and provisioning in network > access as well as for other applications environments > (e.g., IP telephony, mobility). What does the provisioning here involve? We had a short discussion in SFO about the "desire" of using Diameter for other purposes than just auth, authz and acct, mainly because Diameter would make another nice general purpose transport protocol for a lot of things. I was wondering whether we want to be more strict about the scope of extension where diameter is to be used? > > > The IETF has completed work on the Diameter Base protocol and is > working on revising the base protocol specification. There is on-going > work on defining RADIUS extensions and the DIME WG will ensure > that work done in RADEXT is also available for Diameter. [snip] > > Additionally, AAA systems require interoperability in order to work. > The working group, along with the AD, will need to evaluate > any potential extensions and require verification that the proposed > extension is needed. Coordination with other IETF working groups > and other SDOs will used to ensure this. Regarding the additional work, should we explicitly mention that we could take in new work based on the deployment experiences and needs that we hear from the field? We cannot obviously envision all possible needs in the current charter items so this kind of limited wildcard could be useful.. or can this kind of new work be easily added to the charter without full rechartering process? > > > Goals and Milestones: > [snip] Should we add draft-korhonen-dime-mip6-feature-bits-00.txt to charter (that contains the extracted parts from mip6-split I-D due identified IPRs). Even if this draft is trivial and will be informational, having it as a WG item would be nice.. or? Cheers, JOuni > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sunseawq@huawei.com Mon Jun 8 00:04:43 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700633A6CAD for ; Mon, 8 Jun 2009 00:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XCLaY00Dy-9 for ; Mon, 8 Jun 2009 00:04:42 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7325E3A6A0D for ; Mon, 8 Jun 2009 00:04:42 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKW004VVRIUN9@szxga03-in.huawei.com> for dime@ietf.org; Mon, 08 Jun 2009 15:01:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKW001WPRIUJ3@szxga03-in.huawei.com> for dime@ietf.org; Mon, 08 Jun 2009 15:01:42 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKW007H7RITBF@szxml04-in.huawei.com> for dime@ietf.org; Mon, 08 Jun 2009 15:01:42 +0800 (CST) Date: Mon, 08 Jun 2009 15:01:41 +0800 From: Qin Wu To: Sebastien Decugis , dime@ietf.org Message-id: <029d01c9e806$fa35d6d0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C8C10.1010507@nict.go.jp> Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 07:04:43 -0000 Hi, Sebastien: Thank for creating your new idea based on our new draft on local key draft and providing it to the WG consideration. Considering that the key transport mechanism is not limited to be used in the ERP in the Hokey architecture, local key transport can also be used in the pre-authentication or early authentication. So We write the draft on local key transport(i.e.,draft-wu-dime-local-keytran ) which occurs during the bootstrapping procedure between the local server and home server. Have a quick glance at your draft, I found your draft also discuss key transport which has already been covered in the draft-wu-dime-local-keytran. I am not sure these two drafts are overlapped as regarding key transport mechanism. However I am interested in your new draft, for it is more clear and better as compared to I-D.ietf-dime-erp. May I ask to coauthor this new work and push forward this new draft on Diameter ERP topic? Thanks a lot! Regards Qin ----- Original Message ----- From: "Sebastien Decugis" To: Cc: Sent: Monday, June 08, 2009 11:57 AM Subject: [Dime] New draft for Diameter ERP: poll for adoption > Hi all DIME and HOKEY members, > > I have gone forward on the Diameter ERP topic and created a new draft > [1] with the same content (re-organized, hopefully for clarity) as I > presented during last DIME meeting in IETF#74. The main change with > current draft-ietf-dime-erp-00 is the use of a new separate Diameter > application for messages exchanged between the NAS and the ER server. > > I would like to poll the people interested in this topic about the > adoption of this new document for Diameter ERP (in which case it would > become draft-ietf-dime-erp-01). I don't know if this can be done before > the next IETF meeting, or at least during the meeting in Stockholm? > > Thank you for reading, and eventually providing your comments. > Sebastien. > > [1] > http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01.txt > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Mon Jun 8 00:12:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340963A6889 for ; Mon, 8 Jun 2009 00:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SCjNrBsWEAr for ; Mon, 8 Jun 2009 00:12:41 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 5FBB13A67A1 for ; Mon, 8 Jun 2009 00:12:40 -0700 (PDT) Received: (qmail 22993 invoked from network); 8 Jun 2009 07:12:45 -0000 Received: from unknown (124.121.211.14) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 08 Jun 2009 07:12:44 -0000 From: "Glen Zorn" To: "'jouni korhonen'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <3D3C75174CB95F42AD6BCC56E5555B450168506E@FIESEXC015.nsn-intra.net> <4F72CB70-846C-474A-9B3C-C1ED6083766B@gmail.com> In-Reply-To: <4F72CB70-846C-474A-9B3C-C1ED6083766B@gmail.com> Date: Mon, 8 Jun 2009 14:09:27 +0700 Organization: Network Zen Message-ID: <003c01c9e808$1284b840$378e28c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnoBtlOCedSw0qKQLOkKc2cthucdwAAAGzw Content-Language: en-us Cc: iesg-secretary@ietf.org, dime@ietf.org Subject: Re: [Dime] DIME Charter Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 07:12:42 -0000 jouni korhonen [mailto://jouni.nospam@gmail.com] writes: ... > > The IETF has completed work on the Diameter Base protocol and is > > working on revising the base protocol specification. There is on- > going > > work on defining RADIUS extensions and the DIME WG will ensure > > that work done in RADEXT is also available for Diameter. The mandating of forward as well as backward compatibility with RADIUS is an _extremely_ bad idea, IMHO. It may be harmless currently, since the probability of useful extensions to RADIUS being produced by the RADIUS Extensions WG appears to be close to zero, but it sets a bad precedent. ... > > Goals and Milestones: > > > > [snip] > > Should we add draft-korhonen-dime-mip6-feature-bits-00.txt to charter > (that contains the extracted parts from mip6-split I-D due identified > IPRs). Even if this draft is trivial and will be informational, having > it as a WG item would be nice.. or? Given the history of the IETF, it would be nice only if you really want to slow the progress of the draft; otherwise, if it really is both trivial & informational, why not submit it directly to the RFC Editor & be done w/it? ... From sunseawq@huawei.com Mon Jun 8 00:42:23 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F503A6B9F; Mon, 8 Jun 2009 00:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp81j55YnYt5; Mon, 8 Jun 2009 00:42:22 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8EE5E3A69FE; Mon, 8 Jun 2009 00:42:22 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKW00F8XTEDMJ@szxga02-in.huawei.com>; Mon, 08 Jun 2009 15:42:14 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKW003IPTED5H@szxga02-in.huawei.com>; Mon, 08 Jun 2009 15:42:13 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKW0098HTEDEW@szxml04-in.huawei.com>; Mon, 08 Jun 2009 15:42:13 +0800 (CST) Date: Mon, 08 Jun 2009 15:42:13 +0800 From: Qin Wu To: Glen Zorn , 'Sebastien Decugis' Message-id: <03b401c9e80c$a37671f0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C8C10.1010507@nict.go.jp> <001301c9e7f4$6a2b9f50$3e82ddf0$@net> Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 07:42:23 -0000 >> Hi all DIME and HOKEY members, >> >> I have gone forward on the Diameter ERP topic and created a new draft >> [1] with the same content (re-organized, hopefully for clarity) as I >> presented during last DIME meeting in IETF#74. The main change with >> current draft-ietf-dime-erp-00 is the use of a new separate Diameter >> application for messages exchanged between the NAS and the ER server. >> >> I would like to poll the people interested in this topic about the >> adoption of this new document for Diameter ERP (in which case it would >> become draft-ietf-dime-erp-01). > > Isn't this the job of the WG Chairs? > >> I don't know if this can be done before >> the next IETF meeting, or at least during the meeting in Stockholm? > > I am strongly opposed to the adoption of this draft as a WG item, if for no > other reason than that it is clearly derived from other work (as is admitted > in section 1.1), the authors of which are not recognized. Add Wu, > Bournelle, Morand & Dondeti to the author list (provided that they agree, of [Qin]: I accept being included in the author list. > course). BTW, "disappearing" co-authors is one good way to ensure that no > one agrees to collaborate with you in the future... > >> >> Thank you for reading, and eventually providing your comments. >> Sebastien. >> >> [1] >> http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp- >> 01.txt >> >> -- >> Sebastien Decugis >> Research fellow >> Network Architecture Group >> NICT (nict.go.jp) >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From julien.bournelle@gmail.com Mon Jun 8 01:38:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6605D3A6BDF; Mon, 8 Jun 2009 01:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSdfG6rUjvZY; Mon, 8 Jun 2009 01:38:41 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id E61593A6977; Mon, 8 Jun 2009 01:38:40 -0700 (PDT) Received: by ewy6 with SMTP id 6so3949360ewy.37 for ; Mon, 08 Jun 2009 01:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=f2vA+ohHe6/jHgGh+1OVsUA6QoNIPoZ5hab1LTV60Vw=; b=u0LpDM3Y9m1fvjzBIhufKBlj7exnwM0k2NiuicyqY2FPKGjXEHMx/MyfCwCifLJm6M 8Ip1JWxTbYzLgLkWCi+z/3byn9y6VjEMokQlPtpZObnIvn0gmdZ1xWlsBr/BFNDF/Paf +1SWSCzGS+HOE1ZOxyojs+rEcEoWrSQeIc3QA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aWZoqTPbjmPeBiprtGiMoOBMMmweq4DgJVZaLDfIE3Bty3dvhiNnDjx/jP6Higx2Ca DX0Nsg7uX3yo/J5fUMskA283rkOCfxEC/BLt8/kWtlaLsS3qwnQhDhZh3iXUa/iWUtgq G/145jJ0gv3umMOm+leVDcRj8HVIREbGv64Uo= MIME-Version: 1.0 Received: by 10.216.70.135 with SMTP id p7mr2193296wed.138.1244450322050; Mon, 08 Jun 2009 01:38:42 -0700 (PDT) In-Reply-To: <4A2C9E02.3000807@nict.go.jp> References: <4A2C8C10.1010507@nict.go.jp> <001301c9e7f4$6a2b9f50$3e82ddf0$@net> <4A2C9E02.3000807@nict.go.jp> Date: Mon, 8 Jun 2009 10:38:42 +0200 Message-ID: <5e2406980906080138g6b1f6e66qec3e82ab3277a09f@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=001636d3474062f11d046bd22b75 Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] [SPAM] RE: New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 08:38:42 -0000 --001636d3474062f11d046bd22b75 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi sebastien, all, See below, On Mon, Jun 8, 2009 at 7:13 AM, Sebastien Decugis wrote: > > >> > > > > I am strongly opposed to the adoption of this draft as a WG item, if for > no > > other reason than that it is clearly derived from other work (as is > admitted > > in section 1.1), the authors of which are not recognized. Add Wu, > > Bournelle, Morand & Dondeti to the author list (provided that they agree, > of > > course). BTW, "disappearing" co-authors is one good way to ensure that > no > > one agrees to collaborate with you in the future... > > > The authors of the previous draft are listed in contributors section. As > you mention, I don't know if they agree with the content of this new > draft, hence they are not listed as authors for this submission. Anyway, > in case the document is accepted (for its ideas, not its form...) the > authors list would be restored of course. I am not doing this to steal > the work of other people, just trying to push a new different idea to > move the document forward. And I already tried to involve in this new > direction the other co-authors of the previous draft, but got no answer, > hence my separate submission. I thought the consensus was to wait for HOKEY WG inputs, in particular on architectural aspects before moving forward with what we already did ! I have to admit that I'm a little surpised... Regards, Julien > > > Sorry for the apparently tactless process, I hope my intent is now > clarified. > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --001636d3474062f11d046bd22b75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi sebastien, all,

=A0See below,

O= n Mon, Jun 8, 2009 at 7:13 AM, Sebastien Decugis <sdecugis@nict.go.jp> wrote= :

>>
>
> I am strongly opposed to the adoption of this draft as a WG item, if f= or no
> other reason than that it is clearly derived from other work (as is ad= mitted
> in section 1.1), the authors of which are not recognized. =A0Add Wu, > Bournelle, Morand & Dondeti to the author list (provided that they= agree, of
> course). =A0BTW, "disappearing" co-authors is one good way t= o ensure that no
> one agrees to collaborate with you in the future...
>
The authors of the previous draft are listed in contributors section.= As
you mention, I don't know if they agree with the content of this new draft, hence they are not listed as authors for this submission. Anyway, in case the document is accepted (for its ideas, not its form...) the
authors list would be restored of course. I am not doing this to steal
the work of other people, just trying to push a new different idea to
move the document forward. And I already tried to involve in this new
direction the other co-authors of the previous draft, but got no answer, hence my separate submission.

I thought the consensus = was to wait for HOKEY WG inputs, in particular on architectural aspects bef= ore moving forward with what we already did !

=A0I have to admit th= at I'm a little surpised...

=A0Regards,

=A0Julien

=A0


Sorry for the apparently tactless process, I hope my intent is now
clarified.

Best regards,
Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

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

--001636d3474062f11d046bd22b75-- From sdecugis@nict.go.jp Mon Jun 8 01:39:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A173A6DE2 for ; Mon, 8 Jun 2009 01:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy786Mtaz0oW for ; Mon, 8 Jun 2009 01:39:42 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 6C9BA3A6D80 for ; Mon, 8 Jun 2009 01:39:41 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n588dFc2018589; Mon, 8 Jun 2009 17:39:15 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n588dFnC008898; Mon, 8 Jun 2009 17:39:15 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n588dFdO008895; Mon, 8 Jun 2009 17:39:15 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 392F92C16C; Mon, 8 Jun 2009 17:39:15 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 33E952C16A; Mon, 8 Jun 2009 17:39:15 +0900 (JST) Message-ID: <4A2CCE20.4050802@nict.go.jp> Date: Mon, 08 Jun 2009 17:38:56 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Qin Wu References: <4A2C8C10.1010507@nict.go.jp> <029d01c9e806$fa35d6d0$260ca40a@china.huawei.com> In-Reply-To: <029d01c9e806$fa35d6d0$260ca40a@china.huawei.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 08:39:42 -0000 Hi Qin, Thank you for your positive feedback. Please see my comments bellow. > Considering that the key transport mechanism is not limited to be used in the ERP in the Hokey architecture, local key transport > can also be used in the pre-authentication or early authentication. So We write the draft on local key transport(i.e.,draft-wu-dime-local-keytran ) which occurs during the bootstrapping procedure between the local server and home server. > This is also the intent of the new AVPs I defined in the new draft. They are functionnally equivalent to the ones you define in your document, although the format is slightly different. The same applies also to the AVPs defined in the ietf-dime-erp-00 document. Since they are not mandatory AVPs, they can be used for non-ERP situations without any problem, I think (for example added in a different command than DER / DEA, without any change to the ABNF). > Have a quick glance at your draft, I found your draft also discuss key transport which has already been covered in the draft-wu-dime-local-keytran. I am not sure these two drafts are overlapped as regarding key transport mechanism. However I am interested in your new draft, for it is more clear and better as compared to I-D.ietf-dime-erp. May I ask to coauthor this new work and push forward this new draft on Diameter ERP topic? > Thanks a lot! > You are right, this new draft probably overlaps and superseeds your draft and the previous WG ERP draft (as stated in its introduction). I hope it covers every aspects of ERP with Diameter (hence including key distribution) and that the AVPs are designed in such way that they can be re-used in other context as needed (for example for other applications that would need key distribution.) I have no objection adding you as a co-author (as well as all co-authors of the previous ietf-dime-erp draft, unless they want to be removed) in a future version if this document gets support from the WG. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Mon Jun 8 02:07:00 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356993A6BE6; Mon, 8 Jun 2009 02:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.63 X-Spam-Level: X-Spam-Status: No, score=-0.63 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gucG7W6ffcy; Mon, 8 Jun 2009 02:06:54 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id B61CD3A67B0; Mon, 8 Jun 2009 02:06:53 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n5896uJD004053; Mon, 8 Jun 2009 18:06:56 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n5896uwd021121; Mon, 8 Jun 2009 18:06:56 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n5896uKZ021118; Mon, 8 Jun 2009 18:06:56 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1CB012C15D; Mon, 8 Jun 2009 18:06:56 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 168E42C158; Mon, 8 Jun 2009 18:06:56 +0900 (JST) Message-ID: <4A2CD49D.1060203@nict.go.jp> Date: Mon, 08 Jun 2009 18:06:37 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Julien Bournelle References: <4A2C8C10.1010507@nict.go.jp> <001301c9e7f4$6a2b9f50$3e82ddf0$@net> <4A2C9E02.3000807@nict.go.jp> <5e2406980906080138g6b1f6e66qec3e82ab3277a09f@mail.gmail.com> In-Reply-To: <5e2406980906080138g6b1f6e66qec3e82ab3277a09f@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] [SPAM] RE: New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 09:07:00 -0000 Hi Julien, > I thought the consensus was to wait for HOKEY WG inputs, in particular > on architectural aspects before moving forward with what we already did ! As a matter of fact, this new draft is just a rewritting of a design document I wrote before the previous IETF (and presented at that meeting), before this decision to wait for a (hypothetical) clarification document was taken. > I have to admit that I'm a little surpised... Let me clarify this in private mail (it's easier to do in my native language, and also not of much interest to other people on the lists...) Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From jouni.nospam@gmail.com Mon Jun 8 02:21:48 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7073A6D71; Mon, 8 Jun 2009 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCF-uj2ssz27; Mon, 8 Jun 2009 02:21:46 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 2AD7F3A67B0; Mon, 8 Jun 2009 02:21:46 -0700 (PDT) Received: by ewy6 with SMTP id 6so3977084ewy.37 for ; Mon, 08 Jun 2009 02:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=91WKePUeJ3G/kCNVu5Lqzw4OBoNJN9coXgcs5XEbmJs=; b=LKeWyWh7zWIhZnrixbZXaJc9B4uZJhQl1H6QbTvWseHLsIasCH/gfaXvYAgo2Elh3I ioTcij0zL3tdb13usG4cI8o/p9Sjaqcj4v0cs4fe+SaJBOzodK09VMmHmlQkNNL5vVGs /d42l1wmOFyHIiSXaBvayJwi2do6m3UKs/lhs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=LIiaunp1yY6iADTIJQaDbm+xTLZpPYwRrZ3Gtodp3RC2m/3BcsjXY26z3nH3UnZoLV x1rzbzktjsb9JImLslX5gBg+9iQLMWIp11jHVPzuArEAIwZGikfqtrQkJ5gxoyiiHJ45 wUzXEmU31ZlZ1SbaQGiCOj/c9Ex0qvcEGr5U8= Received: by 10.216.1.77 with SMTP id 55mr2226103wec.111.1244452908557; Mon, 08 Jun 2009 02:21:48 -0700 (PDT) Received: from ?10.183.198.57? ([192.100.124.156]) by mx.google.com with ESMTPS id i35sm1394378gve.11.2009.06.08.02.21.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 02:21:48 -0700 (PDT) Message-Id: <48552EAC-6413-4B4E-8B82-29DF5CDDB899@gmail.com> From: jouni korhonen To: Glen Zorn In-Reply-To: <003c01c9e808$1284b840$378e28c0$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 8 Jun 2009 12:21:46 +0300 References: <3D3C75174CB95F42AD6BCC56E5555B450168506E@FIESEXC015.nsn-intra.net> <4F72CB70-846C-474A-9B3C-C1ED6083766B@gmail.com> <003c01c9e808$1284b840$378e28c0$@net> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org, iesg-secretary@ietf.org Subject: Re: [Dime] DIME Charter Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 09:21:48 -0000 On Jun 8, 2009, at 10:09 AM, Glen Zorn wrote: > jouni korhonen [mailto://jouni.nospam@gmail.com] writes: > > ... > >>> The IETF has completed work on the Diameter Base protocol and is >>> working on revising the base protocol specification. There is on- >> going >>> work on defining RADIUS extensions and the DIME WG will ensure >>> that work done in RADEXT is also available for Diameter. > > The mandating of forward as well as backward compatibility with > RADIUS is an > _extremely_ bad idea, IMHO. It may be harmless currently, since the > probability of useful extensions to RADIUS being produced by the > RADIUS > Extensions WG appears to be close to zero, but it sets a bad > precedent. Seems that I forgot to add my comments after quoting text in my reply ;) Anyway, Glen put my thoughts nicely here. I more or less share the same concern Glen has. Cheers, Jouni > > > ... > >>> Goals and Milestones: >>> >> >> [snip] >> >> Should we add draft-korhonen-dime-mip6-feature-bits-00.txt to charter >> (that contains the extracted parts from mip6-split I-D due identified >> IPRs). Even if this draft is trivial and will be informational, >> having >> it as a WG item would be nice.. or? > > Given the history of the IETF, it would be nice only if you really > want to > slow the progress of the draft; otherwise, if it really is both > trivial & > informational, why not submit it directly to the RFC Editor & be > done w/it? > > ... > From gwz@net-zen.net Mon Jun 8 03:03:14 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D32A3A6922 for ; Mon, 8 Jun 2009 03:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9z4FU0Ey3VC for ; Mon, 8 Jun 2009 03:03:13 -0700 (PDT) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by core3.amsl.com (Postfix) with SMTP id 49B473A68BB for ; Mon, 8 Jun 2009 03:03:13 -0700 (PDT) Received: (qmail 10871 invoked from network); 8 Jun 2009 10:03:17 -0000 Received: from unknown (124.121.211.14) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 08 Jun 2009 10:03:16 -0000 From: "Glen Zorn" To: "'Victor Fajardo'" Date: Mon, 8 Jun 2009 16:59:58 +0700 Organization: Network Zen Message-ID: <005901c9e81f$e49b8f40$add2adc0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnoH+GzXIZ4BVZgQLe/7l0VfwvDAw== Content-Language: en-us Cc: dime@ietf.org Subject: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 10:03:14 -0000 EDITORIAL Section 1.2 ----------- In the definition of "Diameter Agent", s/Diameter node/Diameter Node/ In the definition of "Diameter Node", s/Diameter node/Diameter Node/ The definition of a "Diameter Peer" is relational in nature; I think that the definition might be usefully revised to better express this quality. Maybe something like "If a Diameter Node shares a direct transport connection with another Diameter Node, it is a Diameter Peer to that Diameter Node." In the definition of "Diameter Server", s/one/Diameter Node/ In the definition of "Downstream", s/home server/Home Server/ In the definition of "Interim accounting", s/in the case of a device reboot or other network problem prevents the reception/in case a device reboot or other network problem prevent the delivery/ In the definition of "Real-time Accounting" s/The Diameter Credit Control Application [RFC4006] is the application that/The Diameter Credit Control Application [RFC4006] is an example of an application that/ In the definition of "Upstream", s/home server/Home Server/ In the definition of "User", I find the use of "client device" confusing: I think that the term "client" in this document should only be used to refer to Diameter Clients, but this is not the case here. Suggest changing "client device" to "device". Section 1.3 ----------- s/From the point of extensibility/From the point of view of extensibility/ s/Protocol designer/Protocol designers/ Section 1.3.1 ------------- s/of the documents that defines/of the document that defines/ s/where as values/whereas values/ Section 1.3.2 ------------- s/instead of the base/instead of a base/ Section 1.3.3 ------------- I find this section a little bit confusing; I suggest rewriting it as follows: OLD: A new Command Code MUST be allocated when new required AVPs (those indicated as {AVP}) are added, deleted or are redefined (for example by changing a required AVP into an optional one). Furthermore, when a command is modified with respect to the number of round trips then a new Command Code has to be registered. A change to the ABNF of a command, such as described above, MUST result in the definition of a new Command Code. This subsequently leads to the need to define a new Diameter Application for any application that will use that new Command. The IANA considerations for commands are discussed in Section 11.2.1. NEW: A new Command Code MUST be allocated when required AVPs (those indicated as {AVP} in the ABNF definition) are added to, deleted from or redefined in (for example, by changing a required AVP into an optional one) an existing command. Furthermore, if the transport characteristics of a command are changed (for example, with respect to the number of round trips required) a new Command Code MUST be registered. A change to the ABNF of a command, such as described above, MUST result in the definition of a new Command Code. This subsequently leads to the need to define a new Diameter Application for any application that will use that new Command. The IANA considerations for commands are discussed in Section 11.2.1. Section 1.3.4 ------------- I'm pretty sure that "mandatorily" is not an actual English word ;-). I suggest changing "The M-bit allows the sender to indicate to the receiver whether the semantics of an AVP and it's content has to be understood mandatorily or not." to "The M-bit allows the sender to indicate to the receiver whether or not understanding the semantics of an AVP and its content is mandatory." TECHNICAL Section 1.2 I think that the definition of "Diameter Client" is a bit too restrictive: it's not hard to imagine Diameter clients that are not strictly speaking devices or don't sit at the edge of a network or do not (directly) perform access control functions. I suggest rewriting the definition in terms of Diameter Node, maybe something like: "A Diameter Client is a Diameter Node that supports Diameter client applications as well as the base protocol. Diameter Clients are often implemented in devices situated at the edge of a network and provide access control services for that network. Typical examples of Diameter Clients include the Network Access Server (NAS) and the Mobile IP Foreign Agent (FA)." In the definition of "Downstream", a more general statement might be obtained by replacing "access device" with "Diameter Client" The definition of "Session state" doesn't really make sense to me: it doesn't actually define session state, but does define a stateful agent. In the definition of "Upstream", a more general statement might be obtained by replacing "access device" with "Diameter Client" From wwwrun@core3.amsl.com Mon Jun 8 07:08:51 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1A7EC3A6848; Mon, 8 Jun 2009 07:08:50 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090608140851.1A7EC3A6848@core3.amsl.com> Date: Mon, 8 Jun 2009 07:08:51 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 14:08:51 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Quality of Service Attributes for Diameter ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16192&rfc_flag=0 From sunseawq@huawei.com Mon Jun 8 18:45:03 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DF83A69C5 for ; Mon, 8 Jun 2009 18:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.935 X-Spam-Level: X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[AWL=-1.324, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gz6FwRjNnnl for ; Mon, 8 Jun 2009 18:45:02 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9321A3A6823 for ; Mon, 8 Jun 2009 18:45:02 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY00ED57IXD4@szxga04-in.huawei.com> for dime@ietf.org; Tue, 09 Jun 2009 09:44:57 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY00F4U7IX2T@szxga04-in.huawei.com> for dime@ietf.org; Tue, 09 Jun 2009 09:44:57 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKY00ERM7IWDO@szxml04-in.huawei.com> for dime@ietf.org; Tue, 09 Jun 2009 09:44:57 +0800 (CST) Date: Tue, 09 Jun 2009 09:44:53 +0800 From: Qin Wu To: Sebastien Decugis , Glen Zorn Message-id: <011401c9e8a3$e32c3bd0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C8C10.1010507@nict.go.jp> <029d01c9e806$fa35d6d0$260ca40a@china.huawei.com> <4A2CCE20.4050802@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 01:45:04 -0000 Hi, Sebastien: Thank you for your kind feedback. Please see my reply below. ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: Sent: Monday, June 08, 2009 4:38 PM Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption > Hi Qin, > > Thank you for your positive feedback. Please see my comments bellow. > >> Considering that the key transport mechanism is not limited to be used in the ERP in the Hokey architecture, local key transport >> can also be used in the pre-authentication or early authentication. So We write the draft on local key transport(i.e.,draft-wu-dime-local-keytran ) which occurs during the bootstrapping procedure between the local server and home server. >> > This is also the intent of the new AVPs I defined in the new draft. They > are functionnally equivalent to the ones you define in your document, > although the format is slightly different. The same applies also to the > AVPs defined in the ietf-dime-erp-00 document. [Qin]: As I discussed with Glen before, We recommend to use more generic new AVPs to accommodate all the key materials containing DSRK, MSK,rMSK. The format of this grouped new AVP is: EAP-Key ::= < AVP Header: TBD > { EAP-KEY-TYPE enumerated } { EAP-KEY-NAME } { EAP-KEY-LIFETIME} *[ AVP ] However I have not updated the draft-wu-dime-local-keytran-00 based this idea mentioned above before you posted the new draft for Diameter ERP,:).I think your idea in the draft is probably okay. >Since they are not > mandatory AVPs, they can be used for non-ERP situations without any > problem, [Qin] I agree. I think (for example added in a different command than DER / > DEA, without any change to the ABNF). [Qin]: I am not sure. I think It needs to be further discussion. In my mind, it is not clear whether we extend DER/DEA or define new Command Code to accommodate the two new EAP code,i.e.,EAP Initiate/Finish, as regarding key distribution between local server and home server, is it okay for us to reuse DER/DEA to transport the key to the right local server? We need to think about it. >> Have a quick glance at your draft, I found your draft also discuss key transport which has already been covered in the draft-wu-dime-local-keytran. I am not sure these two drafts are overlapped as regarding key transport mechanism. However I am interested in your new draft, for it is more clear and better as compared to I-D.ietf-dime-erp. May I ask to coauthor this new work and push forward this new draft on Diameter ERP topic? >> Thanks a lot! >> > You are right, this new draft probably overlaps and superseeds your > draft and the previous WG ERP draft (as stated in its introduction). I > hope it covers every aspects of ERP with Diameter (hence including key > distribution) and that the AVPs are designed in such way that they can > be re-used in other context as needed (for example for other > applications that would need key distribution.) > > I have no objection adding you as a co-author (as well as all co-authors > of the previous ietf-dime-erp draft, unless they want to be removed) in > a future version if this document gets support from the WG. [Qin]: I'd be happy to contribute/co-author these drafts and support the work on this topic. > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Mon Jun 8 20:21:03 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1790D3A69C6 for ; Mon, 8 Jun 2009 20:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpRP7xdvIARV for ; Mon, 8 Jun 2009 20:21:02 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 853793A6965 for ; Mon, 8 Jun 2009 20:21:01 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n593L2R3012923; Tue, 9 Jun 2009 12:21:02 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n593L2OK019426; Tue, 9 Jun 2009 12:21:02 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n593L2Ul019423; Tue, 9 Jun 2009 12:21:02 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 62B5E2C21A; Tue, 9 Jun 2009 12:21:02 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 5D3912C20B; Tue, 9 Jun 2009 12:21:02 +0900 (JST) Message-ID: <4A2DD50A.3060707@nict.go.jp> Date: Tue, 09 Jun 2009 12:20:42 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Qin Wu References: <4A2C8C10.1010507@nict.go.jp> <029d01c9e806$fa35d6d0$260ca40a@china.huawei.com> <4A2CCE20.4050802@nict.go.jp> <011401c9e8a3$e32c3bd0$260ca40a@china.huawei.com> In-Reply-To: <011401c9e8a3$e32c3bd0$260ca40a@china.huawei.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 03:21:03 -0000 Hi, Qin Wu a écrit : > [Qin]: As I discussed with Glen before, We recommend to use more generic new AVPs to accommodate all the key materials containing DSRK, MSK,rMSK. > I see. I think we can re-use the EAP-Master-Session-Key existing AVP container for transporting key material. I am not aware of any existing AVP suitable for Lifetime and key name, but there are probably some already (maybe in the RADIUS namespace). Then, creating a grouped AVP including all these elements, plus optional others, for each purpose, seems straightforward to me. Anyway, this can be discussed later, it's not a fundamental design issue, IMHO. > [Qin]: I am not sure. I think It needs to be further discussion. > In my mind, it is not clear whether we extend DER/DEA or define new Command Code to accommodate the two new EAP code,i.e.,EAP Initiate/Finish, as regarding key distribution between local server and home server, is it okay for us to reuse DER/DEA to transport the key to the right local server? We need to think about it. > That is the main concern of this new draft. Diameter routing is based on the application-id and destination-realm, not the command code. So re-using DER/DEA or creating a new command code is not related to the problem of routing the message to the proper server. For this purpose, the draft creates a new application id (Diameter ERP). > [Qin]: I'd be happy to contribute/co-author these drafts and support the work on this topic. > Great, thank you :) Let's see what other people think... Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From tena@huawei.com Mon Jun 8 23:55:44 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8E228C160 for ; Mon, 8 Jun 2009 23:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKYDxYCTpNX0 for ; Mon, 8 Jun 2009 23:55:43 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 309003A69ED for ; Mon, 8 Jun 2009 23:55:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY009UWLWQ1X@szxga03-in.huawei.com> for dime@ietf.org; Tue, 09 Jun 2009 14:55:38 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY00IHRLWQH9@szxga03-in.huawei.com> for dime@ietf.org; Tue, 09 Jun 2009 14:55:38 +0800 (CST) Received: from [192.168.1.3] (122.138.61.58.broad.sz.gd.dynamic.163data.com.cn [58.61.138.122]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKY00GHMLWP9Z@szxml02-in.huawei.com>; Tue, 09 Jun 2009 14:55:38 +0800 (CST) Date: Tue, 09 Jun 2009 14:55:36 +0800 From: Tina TSOU In-reply-to: <01b901c9e5bc$cab965d0$0301a8c0@nsnintra.net> To: Hannes Tschofenig Message-id: <3521BC55-4B72-4AAE-9796-42BA4872BFC3@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: multipart/alternative; boundary="Boundary_(ID_s9nRHWO0yDYye0XBWA7haw)" References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net> <01b901c9e5bc$cab965d0$0301a8c0@nsnintra.net> Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering (Update) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 06:55:44 -0000 --Boundary_(ID_s9nRHWO0yDYye0XBWA7haw) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi Hannes, It was in http://groups.google.com/group/diameter-routing/browse_thread/thread/6750c39d5970aada?hl=en 3. Use Cases ... 3.2. Redirect Indication based on realm Consider an Operator; say Operator_A offering some service to Diameter client in its Realm; say Realm_A. For business/maintenance reasons, the operator wants to discontinue the service. However the operator has asked another Operator; say Operator_B (serving Realm_B) to provide the service to the clients. In this case, all the clients should be configured to contact Realm_B instead of Realm_A for the service. For smooth transition, agents may be employed in Realm_A which could answer with a redirect indication suggesting that the service requests may be sent to another realm; Realm_B in this case, so as to be served ... 4. Problem Statements ... 4.3. Redirect Indication based on realm This is the statement of the problem posed by the case presented in Section 3.2. 1. Existing Diameter message routing behaviour: Redirect indication is provided at host level. It provides a list of servers that may be contacted for the request to be served. 2. Undesirable behaviour in the existing method: Redirect indication is not provided at the realm level. There is no option to provide a (list of) realm(s) that may be contacted for the request to be served. 3. Desired behaviour: Redirect indication could be provided at the realm level also. The indication may specify a (list of) realm(s) which could be contacted for the request to be served. B. R. Tina http://tinatsou.weebly.com/contact.html On Jun 5, 2009, at 5:05 PM, Hannes Tschofenig wrote: > Could you send the link to the draft around? > > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > Of Tina TSOU > Sent: 05 June, 2009 11:57 > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: dime@ietf.org > Subject: Re: [Dime] DIME Rechartering (Update) > > Could the redirect at realm level be included? > > http://tinatsou.weebly.com/contact.html > > > > > > On Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> Based on the feedback I have updated the text. >> <> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://w ww.ietf. > --Boundary_(ID_s9nRHWO0yDYye0XBWA7haw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable
Hi Hannes,
It = was in

<= div>
3.  Use Cases
...
3.2. = Redirect Indication based on realm Consider an Operator; say Operator_A offering some service to Diameter client in its Realm; say Realm_A. For business/maintenance reasons, the operator wants to discontinue the service. However the operator has asked another Operator; say Operator_B (serving Realm_B) to provide the service to the clients. In this case, all the clients should be configured to contact Realm_B instead of Realm_A for the service. For smooth transition, agents may be employed in Realm_A which could answer with a redirect indication suggesting that the service requests may be sent to another realm; Realm_B in this case, so as to be served
...
4.  Problem Statements
...
 
On Jun 5, 2009, at 5:05 PM, Hannes Tschofenig =
wrote:

 
 
Could you send the link to the draft =
around? 
 
 
 
 

 =

  
 =
 
  From: =
dime-bounces@ietf.org   [mailto:dime-bounces@ietf.org] =
On Behalf Of Tina TSOU
Sent:   05 June, 2009 =
11:57
To: Tschofenig, Hannes (NSN -   FI/Espoo)
Cc: =
dime@ietf.org
Subject: =
Re: [Dime] DIME   Rechartering (Update)

  =

Could the redirect at realm level be included?  

  =
  

  

  
  
On =
Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo)   =
wrote:

  
    
Based on the feedback I have updated the text. =
    
<<dime-recharter.pdf>>     =

<dime-recharter.pdf>_____________________=
__________________________
DiME     mailing list
DiME@ietf.org
https://w ww.ietf.   

  =


=

--Boundary_(ID_s9nRHWO0yDYye0XBWA7haw)--

From julien.bournelle@gmail.com  Tue Jun  9 00:01:31 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8CA3A6909; Tue,  9 Jun 2009 00:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loxoMJTtn1G3; Tue,  9 Jun 2009 00:01:30 -0700 (PDT)
Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 736363A683F; Tue,  9 Jun 2009 00:01:29 -0700 (PDT)
Received: by ewy6 with SMTP id 6so4881315ewy.37 for ; Tue, 09 Jun 2009 00:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bwyxGixMXVWwFGCc5VM3lWSRWSETAyDkcEl4xcbIT/Y=; b=NGO0zlMuYmW/DG4Af6fd5EbC38UaXRFMZs1vfcb9/rqEHvUHk3eGUGqn0KQhMudfzK zl8kPcSeGVgXMb6UJdMBR1LMXXoiXRTF9CSN4GCWnyp+E518SW2xIPR6AQzCKxxv6Lt9 2iL5WKVTa8wnImIPfHPeCMdMHWDUF7BIjCOMI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=d7TPS1imEGGXwH6lhsd0hcwH6sFBG8gZE5wcXFC+xK3hFnn5yT1cL4W/rp1b2xdkbE sxDV6oYEvDyoOBlrT4a+6/vlN/50e9XZmYEHWPK550YdYomhErytP0Up2dwTyo7bf7qz Yww0Kkx8ifDP72bKYAjnrON3Z0rQ1IaTu7jfw=
MIME-Version: 1.0
Received: by 10.216.16.208 with SMTP id h58mr2629008weh.60.1244530892606; Tue,  09 Jun 2009 00:01:32 -0700 (PDT)
In-Reply-To: <4A2C8C10.1010507@nict.go.jp>
References: <4A2C8C10.1010507@nict.go.jp>
Date: Tue, 9 Jun 2009 09:01:30 +0200
Message-ID: <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com>
From: Julien Bournelle 
To: Sebastien Decugis 
Content-Type: multipart/alternative; boundary=0016364d2447c42a46046be4ed9a
Cc: "dime@ietf.org" , hokey@ietf.org
Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Jun 2009 07:01:31 -0000

--0016364d2447c42a46046be4ed9a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello,

 See inline,

On Mon, Jun 8, 2009 at 5:57 AM, Sebastien Decugis wrote:

> Hi all DIME and HOKEY members,
>
> I have gone forward on the Diameter ERP topic and created a new draft
> [1] with the same content (re-organized, hopefully for clarity) as I
> presented during last DIME meeting in IETF#74. The main change with
> current draft-ietf-dime-erp-00 is the use of a new separate Diameter
> application for messages exchanged between the NAS and the ER server.
>
> I would like to poll the people interested in this topic about the
> adoption of this new document for Diameter ERP (in which case it would
> become draft-ietf-dime-erp-01). I don't know if this can be done before
> the next IETF meeting, or at least during the meeting in Stockholm?



AFAIK, this is not how things are working at IETF. The WG has already a WG
document called draft-ietf-dime-erp-00.txt which is supposed to reflect the
current WG consensus. We can't arrive with a new individual submission and
just bypass the current WG I-D. At least, I never saw that.

Having said that, we have an issue with the current WG document concerning
use of a new Application-ID or reuse of the Diameter EAP. My understanding
was that we were a little blocked because of an architectural issue
concerning the HOKEY server in regards to AAA/EAP server and because of a
routing issue. So I'd like to know what has changed from this point.

 Note that I'm not against your proposal per se. We just have to get a
consensus.

 Best regards,

 Julien


>
>
> Thank you for reading, and eventually providing your comments.
> Sebastien.
>
> [1]
> http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01.txt
>
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

--0016364d2447c42a46046be4ed9a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

=A0See inline,

On Mon, Jun =
8, 2009 at 5:57 AM, Sebastien Decugis <sdecugis@nict.go.jp> wrote:

Hi all DIME and HOKEY members,



I have gone forward on the Diameter ERP topic and created a new draft

[1] with the same content (re-organized, hopefully for clarity) as I

presented during last DIME meeting in IETF#74. The main change with

current draft-ietf-dime-erp-00 is the use of a new separate Diameter

application for messages exchanged between the NAS and the ER server.



I would like to poll the people interested in this topic about the

adoption of this new document for Diameter ERP (in which case it would

become draft-ietf-dime-erp-01). I don't know if this can be done before=


the next IETF meeting, or at least during the meeting in Stockholm?


AFAIK, this is not how things are working at IETF. The WG=
 has already a WG document called draft-ietf-dime-erp-00.txt which is suppo=
sed to reflect the current WG consensus. We can't arrive with a new ind=
ividual submission and just bypass the current WG I-D. At least, I never sa=
w that.


Having said that, we have an issue with the current WG document concern=
ing use of a new Application-ID or reuse of the Diameter EAP. My understand=
ing was that we were a little blocked because of an architectural issue con=
cerning the HOKEY server in regards to AAA/EAP server and because of a rout=
ing issue. So I'd like to know what has changed from this point.


=A0Note that I'm not against your proposal per se. We just have to =
get a consensus.

=A0Best regards,

=A0Julien
=A0





Thank you for reading, and eventually providing your comments.

Sebastien.



[1]

http://www.ietf.org/internet-drafts/draft-sd=
ecugis-dime-diameter-erp-01.txt



--

Sebastien Decugis

Research fellow

Network Architecture Group

NICT (nict.go.jp)



_______________________________________________

DiME mailing list

DiME@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/dime





--0016364d2447c42a46046be4ed9a--

From sdecugis@nict.go.jp  Tue Jun  9 01:28:17 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D193A6827; Tue,  9 Jun 2009 01:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.86
X-Spam-Level: 
X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=0.495,  BAYES_00=-2.599, HELO_EQ_JP=1.244]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68ymk3oTAtlg; Tue,  9 Jun 2009 01:28:16 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 0C96A3A6806; Tue,  9 Jun 2009 01:28:15 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp  with ESMTP id n598SEjv018902; Tue, 9 Jun 2009 17:28:14 +0900 (JST)
Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp  with ESMTP id n598SEN3018526; Tue, 9 Jun 2009 17:28:14 +0900 (JST)
Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp  with ESMTP id n598SEaX018523; Tue, 9 Jun 2009 17:28:14 +0900 (JST)
Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id BB26B2C147; Tue,  9 Jun 2009 17:28:14 +0900 (JST)
Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NICT Mail) with ESMTP id B4E562C145; Tue,  9 Jun 2009 17:28:14 +0900 (JST)
Message-ID: <4A2E1D0A.90006@nict.go.jp>
Date: Tue, 09 Jun 2009 17:27:54 +0900
From: Sebastien Decugis 
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Julien Bournelle 
References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com>
In-Reply-To: <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com>
X-Enigmail-Version: 0.95.7
OpenPGP: id=33D9F61D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "dime@ietf.org" , hokey@ietf.org
Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Jun 2009 08:28:17 -0000

Hi,

(BTW, I propose the follow-ups directed to the DIME mailing-list only,
to avoid the cross-posting. If people from HOKEY ML are interested and
not subscribed to DIME ML, let me know...)

> AFAIK, this is not how things are working at IETF. The WG has already
> a WG document called draft-ietf-dime-erp-00.txt which is supposed to
> reflect the current WG consensus. We can't arrive with a new
> individual submission and just bypass the current WG I-D. At least, I
> never saw that.
Well, once again, sorry for the quiproquo here... I was not
ill-intended, just interested in pushing a new different direction for
the design of Diameter ERP, and submit the new idea to the WG(s) for
consideration (and eventually integration, not by-passing). Enough with
the politics on the WG lists (but I can continue in private if people
want to argue), and let's focus on technical matters...

> Having said that, we have an issue with the current WG document
> concerning use of a new Application-ID or reuse of the Diameter EAP.
> My understanding was that we were a little blocked because of an
> architectural issue concerning the HOKEY server in regards to AAA/EAP
> server and because of a routing issue. So I'd like to know what has
> changed from this point.
For the routing issue: this new proposal aims to solve it.
For the architectural issue: I think it was a misunderstanding from the
beginning, or at least I did not understand the issue, so if someone can
clarify (what the issue was), it would be helpful.

>  Note that I'm not against your proposal per se. We just have to get a
> consensus.
Of course!

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)


From hannes.tschofenig@nsn.com  Tue Jun  9 01:44:20 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BBFF3A6935; Tue,  9 Jun 2009 01:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Level: 
X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYQwBgUW9e2A; Tue,  9 Jun 2009 01:44:19 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4CFB53A6E11; Tue,  9 Jun 2009 01:44:19 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n598iMAQ002406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Jun 2009 10:44:22 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n598iKiB001405; Tue, 9 Jun 2009 10:44:21 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 9 Jun 2009 10:44:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 9 Jun 2009 11:46:17 +0300
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net>
In-Reply-To: <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] New draft for Diameter ERP: poll for adoption
Thread-Index: Acno0CU9sHLcM8JZR+ykiO5MqMUSogAAFzsg
References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Julien Bournelle" , "Sebastien Decugis" 
X-OriginalArrivalTime: 09 Jun 2009 08:44:21.0020 (UTC) FILETIME=[7B902DC0:01C9E8DE]
Cc: dime@ietf.org, hokey@ietf.org
Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Jun 2009 08:44:20 -0000

Hi all,=20
=20
there seems to be a misunderstanding here.=20
=20
We have a working group document with agreed authors.=20
The only question therefore is what the group wants to go into the
existing document - the content. No new document will be added to the
DIME milestones.
=20
What Sebastien should be asking the group is whether the content in
draft-sdecugis-dime-diameter-erp-01.txt should be included in the next
version of draft-ietf-dime-erp.=20
=20
I personally think that draft-ietf-dime-erp-01 could have included the
updated text already since we discussed it on the list. Anyway, ...=20

In any case, it is good to ask the group whether this significant change
should be made.=20

My answer: I believe that this is the right direction, as I indicated
previously on the list.=20

Ciao
Hannes
=20



________________________________

	From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
Behalf Of ext Julien Bournelle
	Sent: 09 June, 2009 10:02
	To: Sebastien Decugis
	Cc: dime@ietf.org; hokey@ietf.org
	Subject: Re: [Dime] New draft for Diameter ERP: poll for
adoption
=09
=09
	Hello,
=09
	 See inline,
=09
=09
	On Mon, Jun 8, 2009 at 5:57 AM, Sebastien Decugis
 wrote:
=09

		Hi all DIME and HOKEY members,
	=09
		I have gone forward on the Diameter ERP topic and
created a new draft
		[1] with the same content (re-organized, hopefully for
clarity) as I
		presented during last DIME meeting in IETF#74. The main
change with
		current draft-ietf-dime-erp-00 is the use of a new
separate Diameter
		application for messages exchanged between the NAS and
the ER server.
	=09
		I would like to poll the people interested in this topic
about the
		adoption of this new document for Diameter ERP (in which
case it would
		become draft-ietf-dime-erp-01). I don't know if this can
be done before
		the next IETF meeting, or at least during the meeting in
Stockholm?

=09
=09
	AFAIK, this is not how things are working at IETF. The WG has
already a WG document called draft-ietf-dime-erp-00.txt which is
supposed to reflect the current WG consensus. We can't arrive with a new
individual submission and just bypass the current WG I-D. At least, I
never saw that.
=09
	Having said that, we have an issue with the current WG document
concerning use of a new Application-ID or reuse of the Diameter EAP. My
understanding was that we were a little blocked because of an
architectural issue concerning the HOKEY server in regards to AAA/EAP
server and because of a routing issue. So I'd like to know what has
changed from this point.
=09
	 Note that I'm not against your proposal per se. We just have to
get a consensus.
=09
	 Best regards,
=09
	 Julien
	=20

	=09
	=09
		Thank you for reading, and eventually providing your
comments.
		Sebastien.
	=09
		[1]
=09
http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01.
txt
	=09
		--
		Sebastien Decugis
		Research fellow
		Network Architecture Group
		NICT (nict.go.jp)
	=09
		_______________________________________________
		DiME mailing list
		DiME@ietf.org
		https://www.ietf.org/mailman/listinfo/dime
	=09



From tena@huawei.com  Tue Jun  9 21:23:18 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2443A6B77; Tue,  9 Jun 2009 21:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.932
X-Spam-Level: 
X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RECV_IP_219128=1.666]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vilqhPHXIpqK; Tue,  9 Jun 2009 21:23:17 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1F7A53A679C; Tue,  9 Jun 2009 21:23:16 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL0008QI9IVW6@szxga03-in.huawei.com>; Wed, 10 Jun 2009 12:23:19 +0800 (CST)
Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL0002NN9IUEN@szxga03-in.huawei.com>; Wed, 10 Jun 2009 12:23:18 +0800 (CST)
Received: from [192.168.5.105] (196.216.133.219.broad.sz.gd.dynamic.163data.com.cn [219.133.216.196]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0KL000M999ITE9@szxml01-in.huawei.com>; Wed, 10 Jun 2009 12:23:18 +0800 (CST)
Date: Wed, 10 Jun 2009 12:23:17 +0800
From: Tina TSOU 
In-reply-to: <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
Message-id: <27D17F29-6B98-482C-A3EB-7DE170B14F1E@huawei.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.930.3)
Content-type: multipart/alternative; boundary="Boundary_(ID_oQo+nij2iDY8IhNRCgtf4w)"
References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net>
Cc: dime@ietf.org, hokey@ietf.org
Subject: Re: [Dime] [HOKEY]  New draft for Diameter ERP: poll for adoption
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2009 04:23:18 -0000

--Boundary_(ID_oQo+nij2iDY8IhNRCgtf4w)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT

Hi Hannes,
Thank you for your clarification. It is much clearer.
This change should be made, since ERP is one of the most important  
applications for Diameter.

B. R.
Tina
IPTIME - Unified QoS ARchitecture (UQAr) [ju'ka:] /pronounced like  
"you"+"car"/
UQAr@huawei.com
http://uqar.weebly.com
http://tinatsou.weebly.com/contact.html





On Jun 9, 2009, at 4:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Hi all,
>
> there seems to be a misunderstanding here.
>
> We have a working group document with agreed authors.
> The only question therefore is what the group wants to go into the
> existing document - the content. No new document will be added to the
> DIME milestones.
>
> What Sebastien should be asking the group is whether the content in
> draft-sdecugis-dime-diameter-erp-01.txt should be included in the next
> version of draft-ietf-dime-erp.
>
> I personally think that draft-ietf-dime-erp-01 could have included the
> updated text already since we discussed it on the list. Anyway, ...
>
> In any case, it is good to ask the group whether this significant  
> change
> should be made.
>
> My answer: I believe that this is the right direction, as I indicated
> previously on the list.
>
> Ciao
> Hannes
>
>
>
>
> ________________________________
>
> 	From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
> Behalf Of ext Julien Bournelle
> 	Sent: 09 June, 2009 10:02
> 	To: Sebastien Decugis
> 	Cc: dime@ietf.org; hokey@ietf.org
> 	Subject: Re: [Dime] New draft for Diameter ERP: poll for
> adoption
> 	
> 	
> 	Hello,
> 	
> 	 See inline,
> 	
> 	
> 	On Mon, Jun 8, 2009 at 5:57 AM, Sebastien Decugis
>  wrote:
> 	
>
> 		Hi all DIME and HOKEY members,
> 		
> 		I have gone forward on the Diameter ERP topic and
> created a new draft
> 		[1] with the same content (re-organized, hopefully for
> clarity) as I
> 		presented during last DIME meeting in IETF#74. The main
> change with
> 		current draft-ietf-dime-erp-00 is the use of a new
> separate Diameter
> 		application for messages exchanged between the NAS and
> the ER server.
> 		
> 		I would like to poll the people interested in this topic
> about the
> 		adoption of this new document for Diameter ERP (in which
> case it would
> 		become draft-ietf-dime-erp-01). I don't know if this can
> be done before
> 		the next IETF meeting, or at least during the meeting in
> Stockholm?
>
> 	
> 	
> 	AFAIK, this is not how things are working at IETF. The WG has
> already a WG document called draft-ietf-dime-erp-00.txt which is
> supposed to reflect the current WG consensus. We can't arrive with a  
> new
> individual submission and just bypass the current WG I-D. At least, I
> never saw that.
> 	
> 	Having said that, we have an issue with the current WG document
> concerning use of a new Application-ID or reuse of the Diameter EAP.  
> My
> understanding was that we were a little blocked because of an
> architectural issue concerning the HOKEY server in regards to AAA/EAP
> server and because of a routing issue. So I'd like to know what has
> changed from this point.
> 	
> 	 Note that I'm not against your proposal per se. We just have to
> get a consensus.
> 	
> 	 Best regards,
> 	
> 	 Julien
> 	
>
> 		
> 		
> 		Thank you for reading, and eventually providing your
> comments.
> 		Sebastien.
> 		
> 		[1]
> 	
> http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01 
> .
> txt
> 		
> 		--
> 		Sebastien Decugis
> 		Research fellow
> 		Network Architecture Group
> 		NICT (nict.go.jp)
> 		
> 		_______________________________________________
> 		DiME mailing list
> 		DiME@ietf.org
> 		https://www.ietf.org/mailman/listinfo/dime
> 		
>
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey


--Boundary_(ID_oQo+nij2iDY8IhNRCgtf4w)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT


Hi Hannes,
Thank you for your clarification. It is much clearer.
This change should be made, since ERP is one of the most important applications for Diameter.

 

eak-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
B. R.
Tina
IPTIME - Unified QoS ARchitecture (UQAr) [ju'ka:] /pronounced like "you"+"car"/

>

 

On Jun 9, 2009, at 4:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

Hi all, 

there seems to be a misunderstanding here. 

We have a working group document with agreed authors. 
The only question therefore is what the group wants to go into the
existing document - the content. No new document will be added to the
DIME milestones.

What Sebastien should be asking the group is whether the content in
draft-sdecugis-dime-diameter-erp-01.txt should be included in the next
version of draft-ietf-dime-erp. 

I personally think that draft-ietf-dime-erp-01 could have included the
updated text already since we discussed it on the list. Anyway, ... 

In any case, it is good to ask the group whether this significant cha
 nge
s
 answer: I believe that this is the right direction, as I indicated
previously on the list. 

Ciao
Hannes




________________________________

	From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
Behalf Of ext Julien Bournelle
	Sent: 09 June, 2009 10:02
	To: Sebastien Decugis
	Cc: dime@ietf.org; hokey@ietf.org
	Subject: Re: [Dime] New draft for Diameter ERP: poll for
adoption
	
	
	Hello,
	
	 See inline,
	
	
	On Mon, Jun 8, 2009 at 5:57 AM, Sebastien Decugis
<sdecugis@nict.go.jp> wrote:
	

		Hi all DIME and HOKEY members,
		
		I have gone forward
  on the 
>created a new draft
		[1] with the same content (re-organized, hopefully for
clarity) as I
		presented during last DIME meeting in IETF#74. The main
change with
		current draft-ietf-dime-erp-00 is the use of a new
separate Diameter
		application for messages exchanged between the NAS and
the ER server.
		
		I would like to poll the people interested in this topic
about the
		adoption of this new document for Diameter ERP (in which
case it would
		become draft-ietf-dime-erp-01). I don't know if this can
be done before
		the next IETF meeting, or at least during the meeting in
Stockholm?

	
	
	AFAIK, this is not how things are working at IETF. The WG has
already a WG document cal
 led draf
ich is
supposed to reflect the current WG consensus. We can't arrive with a new
individual submission and just bypass the current WG I-D. At least, I
never saw that.
	
	Having said that, we have an issue with the current WG document
concerning use of a new Application-ID or reuse of the Diameter EAP. My
understanding was that we were a little blocked because of an
architectural issue concerning the HOKEY server in regards to AAA/EAP
server and because of a routing issue. So I'd like to know what has
changed from this point.
	
	 Note that I'm not against your proposal per se. We just have to
get a consensus.
	
	
	 Julien
	 

		
		
		Thank you for reading, and eventually providing your
comments.
		Sebastien.
		
		[1]
	
http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01.
txt
		
		--
		Sebastien Decugis
		Research fellow
		Network Architecture Group
	NICT (nict.go.jp)
		
		_______________________________________________
		DiME mailing list
		DiME@ietf.org
		https://www.ietf.org/mailman/listinfo/dime
		

 


______________________
HOKEY mailing list
HOKEY@ietf.org
https://www.ietf.org/mailman/listinfo/hokey



--Boundary_(ID_oQo+nij2iDY8IhNRCgtf4w)--

From sdecugis@nict.go.jp  Tue Jun  9 21:42:51 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F27B3A6C57 for ; Tue,  9 Jun 2009 21:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.942
X-Spam-Level: 
X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=0.413,  BAYES_00=-2.599, HELO_EQ_JP=1.244]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8j8Pfs8kZg8 for ; Tue,  9 Jun 2009 21:42:50 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 200253A6C42 for ; Tue,  9 Jun 2009 21:42:49 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp  with ESMTP id n5A4gsBk003322; Wed, 10 Jun 2009 13:42:54 +0900 (JST)
Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp  with ESMTP id n5A4grFi002438; Wed, 10 Jun 2009 13:42:53 +0900 (JST)
Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp  with ESMTP id n5A4gruJ002435; Wed, 10 Jun 2009 13:42:53 +0900 (JST)
Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id C598A2C1E2; Wed, 10 Jun 2009 13:42:53 +0900 (JST)
Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NICT Mail) with ESMTP id C07C92C1E1; Wed, 10 Jun 2009 13:42:53 +0900 (JST)
Message-ID: <4A2F39B9.5000908@nict.go.jp>
Date: Wed, 10 Jun 2009 13:42:33 +0900
From: Sebastien Decugis 
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net>
X-Enigmail-Version: 0.95.7
OpenPGP: id=33D9F61D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: dime@ietf.org
Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2009 04:42:51 -0000

Hello,

Tschofenig, Hannes (NSN - FI/Espoo) a écrit :
> What Sebastien should be asking the group is whether the content in
> draft-sdecugis-dime-diameter-erp-01.txt should be included in the next
> version of draft-ietf-dime-erp. 
>   
Thank you for the clarification. That was my intention, but I realize
now that my initial mail was very misleading. Sorry for the confusion!

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)


From jouni.nospam@gmail.com  Wed Jun 10 02:55:35 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCBD3A6AB1 for ; Wed, 10 Jun 2009 02:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk813iuZU8-I for ; Wed, 10 Jun 2009 02:55:34 -0700 (PDT)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 5FC623A6879 for ; Wed, 10 Jun 2009 02:55:34 -0700 (PDT)
Received: by fxm9 with SMTP id 9so619800fxm.37 for ; Wed, 10 Jun 2009 02:55:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :references:x-mailer; bh=BjIy6+iGCR2GWvl7JDrBCQqGXMkj/gmKMqmeYThEa4s=; b=SAXX+wkguY6M8peN6VOmXofcfA2kZmOVFX0tetCDbCggG/cwgPlzRixzVEHBnyr2B9 vdxfRC4aj0P9dWGWhONRLnMVYLjfUz95Xfjh9HVxgVRGtbRnUgNXnMqatDqlBV8lmXo5 jMjiulYmzW+CS+vRSJ4Vw/e0G0e5aegpaFFk8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:references:x-mailer; b=KedKU1ykrqFYOu3d8wzCKL00G5DxMM0dVWwPPnViYxHlAYtBpZs2b5VtOj1OmDZwJv m7d5ceUoB51gqiV002fkODRTh7Iz1KhnhrjZOtn6MmjCVD1vB5TDPu2N7tADyvF3vcVy UNQJT1ZT+4zKJJK2v4y+UsXhMUYNfJldL4slo=
Received: by 10.86.70.3 with SMTP id s3mr970340fga.12.1244627738358; Wed, 10 Jun 2009 02:55:38 -0700 (PDT)
Received: from a88-114-166-189.elisa-laajakaista.fi (a88-114-166-189.elisa-laajakaista.fi [88.114.166.189]) by mx.google.com with ESMTPS id e11sm3308440fga.11.2009.06.10.02.55.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 02:55:37 -0700 (PDT)
Message-Id: <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com>
From: jouni korhonen 
To: dime@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 10 Jun 2009 12:55:36 +0300
References: <20090610092653.601A33A6E07@core3.amsl.com>
X-Mailer: Apple Mail (2.935.3)
Subject: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2009 09:55:35 -0000

Hi all,

I have updated the additional feature bits draft. I did remove some  
stuff so that the draft now only reserves MIP6-Feature-Vector flag  
bits and nothing more. I'll forward the draft soon to RFC editor so if  
anyone has comments, please be quick :)

Cheers,
	Jouni

Begin forwarded message:

> From: IETF I-D Submission Tool 
> Date: June 10, 2009 12:26:53 PM GMT+03:00
> To: jouni.nospam@gmail.com
> Subject: New Version Notification for  draft-korhonen-dime-mip6- 
> feature-bits-01
>
>
> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt  
> has been successfuly submitted by Jouni Korhonen and posted to the  
> IETF repository.
>
> Filename:	 draft-korhonen-dime-mip6-feature-bits
> Revision:	 01
> Title:		 Diameter MIP6 Feature Vector Additional Bit Allocations
> Creation_date:	 2009-06-10
> WG ID:		 Independent Submission
> Number_of_pages: 5
>
> Abstract:
> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
> Home Agent and the Authentication, Authorization, and Accounting
> server may exchange a set of authorized mobility capabilities.  This
> document defines new mobility capability flags that are used to
> authorize per Mobile Node route optimization, Multiple Care-of
> Address and user plane traffic encryption support.  Furthermore, this
> document also defines a capability flag of indicating whether the
> Home Agent is authorized to act as a stand alone Virtual Private
> Network gateway.
>
>
>
> The IETF Secretariat.
>
>


From sunseawq@huawei.com  Wed Jun 10 04:45:32 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9782A3A69B0 for ; Wed, 10 Jun 2009 04:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.33
X-Spam-Level: 
X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=1.269,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDnFv7oUHJ27 for ; Wed, 10 Jun 2009 04:45:31 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A062E3A68F3 for ; Wed, 10 Jun 2009 04:45:31 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL000735TZYSH@szxga03-in.huawei.com> for dime@ietf.org; Wed, 10 Jun 2009 19:45:34 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL0005MNTZY8J@szxga03-in.huawei.com> for dime@ietf.org; Wed, 10 Jun 2009 19:45:34 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL000JWCTZYH0@szxml06-in.huawei.com> for dime@ietf.org; Wed, 10 Jun 2009 19:45:34 +0800 (CST)
Date: Wed, 10 Jun 2009 19:45:34 +0800
From: Qin Wu 
To: jouni korhonen , dime@ietf.org
Message-id: <005001c9e9c0$f7252890$260ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com>
Subject: Re: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2009 11:45:32 -0000

Hi, Jouni:
When the HA support Multiple CoA feature, why should the AAA server  care this feature?
If the AAA server neglectsthis feature or does not authorize the use of CoA, does it mean 
mutiple CoA registration will fail or something else?
If I miss anything, please correct me.

Regards!
-Qin
----- Original Message ----- 
From: "jouni korhonen" 
To: 
Sent: Wednesday, June 10, 2009 5:55 PM
Subject: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01


> Hi all,
> 
> I have updated the additional feature bits draft. I did remove some  
> stuff so that the draft now only reserves MIP6-Feature-Vector flag  
> bits and nothing more. I'll forward the draft soon to RFC editor so if  
> anyone has comments, please be quick :)
> 
> Cheers,
> Jouni
> 
> Begin forwarded message:
> 
>> From: IETF I-D Submission Tool 
>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>> To: jouni.nospam@gmail.com
>> Subject: New Version Notification for  draft-korhonen-dime-mip6- 
>> feature-bits-01
>>
>>
>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt  
>> has been successfuly submitted by Jouni Korhonen and posted to the  
>> IETF repository.
>>
>> Filename: draft-korhonen-dime-mip6-feature-bits
>> Revision: 01
>> Title: Diameter MIP6 Feature Vector Additional Bit Allocations
>> Creation_date: 2009-06-10
>> WG ID: Independent Submission
>> Number_of_pages: 5
>>
>> Abstract:
>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
>> Home Agent and the Authentication, Authorization, and Accounting
>> server may exchange a set of authorized mobility capabilities.  This
>> document defines new mobility capability flags that are used to
>> authorize per Mobile Node route optimization, Multiple Care-of
>> Address and user plane traffic encryption support.  Furthermore, this
>> document also defines a capability flag of indicating whether the
>> Home Agent is authorized to act as a stand alone Virtual Private
>> Network gateway.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

From jouni.nospam@gmail.com  Wed Jun 10 06:39:38 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037B13A6E85 for ; Wed, 10 Jun 2009 06:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxmCLJCjLteT for ; Wed, 10 Jun 2009 06:39:37 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 4633D3A6E8B for ; Wed, 10 Jun 2009 06:39:17 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id 13so202917fge.18 for ; Wed, 10 Jun 2009 06:39:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=WJ/hChnqllbkK6NeIAocqWGkyV/wnjSxBmqVxhg1r4k=; b=GSHgYkf5KJyqgkb0YQSGhyNgpz7DqsWxM3ue47tbA53FvmsrzdgICd0fBmNAIVilo6 z7v8LO4b+S5SJ3D0PHJyq3pudExVbpHPBkWRxqKb1qTU5KqsJEwZIEVyrFwmy/TxvZEI cLFReLmzeqKe7MjwFQeU+K/N52EzfKnkrfbbw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=m0gixp24RRbChnpCZE7OBiD08/UsP+fEjKcswHASPmNmR+y/O+KaBR77Pj8gNt5xlt XRNXxelHnqAK6LR0LL8d/MehRm8bqne3OEux17/6Z6idCZ/idAmNZovy3iWqjsGIwQUi mgETtIW8GbwjtgEr+qJmDYv17FpMko2Y8IytE=
Received: by 10.86.51.10 with SMTP id y10mr1162917fgy.9.1244641161146; Wed, 10 Jun 2009 06:39:21 -0700 (PDT)
Received: from a88-114-166-189.elisa-laajakaista.fi (a88-114-166-189.elisa-laajakaista.fi [88.114.166.189]) by mx.google.com with ESMTPS id d6sm3739074fga.2.2009.06.10.06.39.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 06:39:20 -0700 (PDT)
From: jouni korhonen 
To: Qin Wu 
In-Reply-To: <005001c9e9c0$f7252890$260ca40a@china.huawei.com>
X-Priority: 3
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <005001c9e9c0$f7252890$260ca40a@china.huawei.com>
Message-Id: <1A4A1012-2BEE-4908-BB69-0D5D686ED4FC@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 10 Jun 2009 16:39:13 +0300
X-Mailer: Apple Mail (2.935.3)
Cc: dime@ietf.org
Subject: Re: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2009 13:39:38 -0000

Hi Qin,

It is yet another subscription related policy decision.  An operator  
might, for some reason, to have such functionality to be disabled. If  
you go back to draft-ietf-dime-mip6-split-12, you can find all these  
feature vector flag bits there.

If the AAA does not authorize the use of MCoA the HA shall act as it  
would not support MCoA in the first place.

Cheers,
	Jouni


On Jun 10, 2009, at 2:45 PM, Qin Wu wrote:

> Hi, Jouni:
> When the HA support Multiple CoA feature, why should the AAA server   
> care this feature?
> If the AAA server neglectsthis feature or does not authorize the use  
> of CoA, does it mean
> mutiple CoA registration will fail or something else?
> If I miss anything, please correct me.
>
> Regards!
> -Qin
> ----- Original Message -----
> From: "jouni korhonen" 
> To: 
> Sent: Wednesday, June 10, 2009 5:55 PM
> Subject: [Dime] Fwd: New Version Notification fordraft-korhonen-dime- 
> mip6-feature-bits-01
>
>
>> Hi all,
>>
>> I have updated the additional feature bits draft. I did remove some
>> stuff so that the draft now only reserves MIP6-Feature-Vector flag
>> bits and nothing more. I'll forward the draft soon to RFC editor so  
>> if
>> anyone has comments, please be quick :)
>>
>> Cheers,
>> Jouni
>>
>> Begin forwarded message:
>>
>>> From: IETF I-D Submission Tool 
>>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>>> To: jouni.nospam@gmail.com
>>> Subject: New Version Notification for  draft-korhonen-dime-mip6-
>>> feature-bits-01
>>>
>>>
>>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt
>>> has been successfuly submitted by Jouni Korhonen and posted to the
>>> IETF repository.
>>>
>>> Filename: draft-korhonen-dime-mip6-feature-bits
>>> Revision: 01
>>> Title: Diameter MIP6 Feature Vector Additional Bit Allocations
>>> Creation_date: 2009-06-10
>>> WG ID: Independent Submission
>>> Number_of_pages: 5
>>>
>>> Abstract:
>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
>>> Home Agent and the Authentication, Authorization, and Accounting
>>> server may exchange a set of authorized mobility capabilities.  This
>>> document defines new mobility capability flags that are used to
>>> authorize per Mobile Node route optimization, Multiple Care-of
>>> Address and user plane traffic encryption support.  Furthermore,  
>>> this
>>> document also defines a capability flag of indicating whether the
>>> Home Agent is authorized to act as a stand alone Virtual Private
>>> Network gateway.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime


From dvijay@gmail.com  Wed Jun 10 14:49:26 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA363A6C90 for ; Wed, 10 Jun 2009 14:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK+hT68PuQws for ; Wed, 10 Jun 2009 14:49:26 -0700 (PDT)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id CF84A3A6951 for ; Wed, 10 Jun 2009 14:49:25 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 3so513146ywj.49 for ; Wed, 10 Jun 2009 14:49:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OKqnzteYjBvX9wj+Em2Q3DD5Nh9ixp1Nx5jCOkM8KvU=; b=P/zfnkCn7nSVDO1GlyDM6FJHp62p1FLvXPiuYa62Y7vMVvwl7teOV2FUN3dPylcuh7 us9jw7PSQMRTFLnizhosL2BKtuN5yiJiygadzXkvdMe1x9KkujzXV6S8TJtkgWU169OP L1naRpxkpSjxg0BOrn4wpOd4+W2qZAFW4kFsE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cO0Sc9d6T624looSG386FmrRiDA1Ibi3jBh0h/LCw3FfPuyUf8EuFvBf4sVEQnfmr7 ITVB3NTrVMboD4NaUT3bVoaTj50GP4dYY1U052Dg/vaFq6XAMpJNHOnQtdHjw8XPm65j /vGpSl/j9DMDP5i8m5JhV1ornDYorvSZeJrtk=
MIME-Version: 1.0
Received: by 10.151.124.10 with SMTP id b10mr3513428ybn.249.1244670570801;  Wed, 10 Jun 2009 14:49:30 -0700 (PDT)
In-Reply-To: <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com>
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com>
Date: Wed, 10 Jun 2009 14:49:30 -0700
Message-ID: 
From: Vijay Devarapalli 
To: jouni korhonen 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: dime@ietf.org
Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2009 21:49:26 -0000

Hi Jouni,

I have a comment on the "VPN Gateway feature". There is no document
that describes what it means for a Mobile IPv6 home agent to act as a
VPN gateway. The IKEv2 exchange between the MN and the HA [RFC 4877
and 5026] already supports mutual authentication, address assignment
and setting up of tunnel mode ESP SAs. Are you referring to this as
VPN mode? But isn't this regular Home agent functionality?

Or is there a separate IPsec VPN that is first setup and then Mobile
IPv6 is run on top of the IPsec tunnels?

Vijay

On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen wro=
te:
> Hi all,
>
> I have updated the additional feature bits draft. I did remove some stuff=
 so
> that the draft now only reserves MIP6-Feature-Vector flag bits and nothin=
g
> more. I'll forward the draft soon to RFC editor so if anyone has comments=
,
> please be quick :)
>
> Cheers,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Jouni
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool 
>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>> To: jouni.nospam@gmail.com
>> Subject: New Version Notification for
>> =C2=A0draft-korhonen-dime-mip6-feature-bits-01
>>
>>
>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has
>> been successfuly submitted by Jouni Korhonen and posted to the IETF
>> repository.
>>
>> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-korhonen-dime-mip6-feature-bi=
ts
>> Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A001
>> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diameter MIP6 Feature Vector A=
dditional Bit Allocations
>> Creation_date: =C2=A0 2009-06-10
>> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Submission
>> Number_of_pages: 5
>>
>> Abstract:
>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
>> Home Agent and the Authentication, Authorization, and Accounting
>> server may exchange a set of authorized mobility capabilities. =C2=A0Thi=
s
>> document defines new mobility capability flags that are used to
>> authorize per Mobile Node route optimization, Multiple Care-of
>> Address and user plane traffic encryption support. =C2=A0Furthermore, th=
is
>> document also defines a capability flag of indicating whether the
>> Home Agent is authorized to act as a stand alone Virtual Private
>> Network gateway.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

From dvijay@gmail.com  Wed Jun 10 14:51:50 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5718D3A6A7A for ; Wed, 10 Jun 2009 14:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2SiNu7awWTb for ; Wed, 10 Jun 2009 14:51:49 -0700 (PDT)
Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 6D4603A6A6B for ; Wed, 10 Jun 2009 14:51:49 -0700 (PDT)
Received: by gxk10 with SMTP id 10so1472484gxk.13 for ; Wed, 10 Jun 2009 14:51:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QLRDZQA2HOqB7qa9p6TBbnpYbFIprWhEa9LuumJxXaE=; b=xliDT2kZ1Nty8f/saaeIXFk9HatbcaGHYfQ9WIrfHpDZeCrxLpyE3bswaIai3UiWr9 u047gWHnLB3OzOgGt20ddY6V69KEkjscokNn389HPUjer2oaGArcIvJzu8ZZEZ12UmdP F9mloFCvKXKJFhSaZO1mwdoRfVOw/NPXfdS7o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SONNqwT31jh/DqAqDejD5sVFZb9FTdg4KAG7+la6zIWLO/lXoKxwxOFZjrGkUzk7iH DI19wdOLH16qoTZawrAgAzjRKf0jhX7zI+x74vlzKvTSV3e4hMI+8KUnW/z0/CthQzL7 alCjCvlVo0Y4EGXo5lOENPhEeS/1qhhdYQXPw=
MIME-Version: 1.0
Received: by 10.150.58.8 with SMTP id g8mr3506996yba.268.1244670713711; Wed,  10 Jun 2009 14:51:53 -0700 (PDT)
In-Reply-To: <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com>
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com>
Date: Wed, 10 Jun 2009 14:51:53 -0700
Message-ID: 
From: Vijay Devarapalli 
To: jouni korhonen 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: dime@ietf.org
Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2009 21:51:50 -0000

I have another question.

Why does encrypting the payload traffic between the MN and the HA need
AAA authorization?

Vijay

On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen wro=
te:
> Hi all,
>
> I have updated the additional feature bits draft. I did remove some stuff=
 so
> that the draft now only reserves MIP6-Feature-Vector flag bits and nothin=
g
> more. I'll forward the draft soon to RFC editor so if anyone has comments=
,
> please be quick :)
>
> Cheers,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Jouni
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool 
>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>> To: jouni.nospam@gmail.com
>> Subject: New Version Notification for
>> =C2=A0draft-korhonen-dime-mip6-feature-bits-01
>>
>>
>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has
>> been successfuly submitted by Jouni Korhonen and posted to the IETF
>> repository.
>>
>> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-korhonen-dime-mip6-feature-bi=
ts
>> Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A001
>> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diameter MIP6 Feature Vector A=
dditional Bit Allocations
>> Creation_date: =C2=A0 2009-06-10
>> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Submission
>> Number_of_pages: 5
>>
>> Abstract:
>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
>> Home Agent and the Authentication, Authorization, and Accounting
>> server may exchange a set of authorized mobility capabilities. =C2=A0Thi=
s
>> document defines new mobility capability flags that are used to
>> authorize per Mobile Node route optimization, Multiple Care-of
>> Address and user plane traffic encryption support. =C2=A0Furthermore, th=
is
>> document also defines a capability flag of indicating whether the
>> Home Agent is authorized to act as a stand alone Virtual Private
>> Network gateway.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

From sunseawq@huawei.com  Wed Jun 10 18:05:51 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CFA3A68AF for ; Wed, 10 Jun 2009 18:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.436
X-Spam-Level: 
X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq9f0Sw2PRcM for ; Wed, 10 Jun 2009 18:05:45 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 556243A68AC for ; Wed, 10 Jun 2009 18:05:45 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL1002HSV1HN8@szxga02-in.huawei.com> for dime@ietf.org; Thu, 11 Jun 2009 09:05:42 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL1000C1V1HY0@szxga02-in.huawei.com> for dime@ietf.org; Thu, 11 Jun 2009 09:05:41 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL10044VV1HDD@szxml04-in.huawei.com> for dime@ietf.org; Thu, 11 Jun 2009 09:05:41 +0800 (CST)
Date: Thu, 11 Jun 2009 09:05:42 +0800
From: Qin Wu 
To: jouni korhonen 
Message-id: <011d01c9ea30$be1ea920$260ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <005001c9e9c0$f7252890$260ca40a@china.huawei.com> <1A4A1012-2BEE-4908-BB69-0D5D686ED4FC@gmail.com>
Cc: dime@ietf.org
Subject: Re: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2009 01:05:51 -0000

Thank you for your clarification!
----- Original Message ----- 
From: "jouni korhonen" 
To: "Qin Wu" 
Cc: 
Sent: Wednesday, June 10, 2009 9:39 PM
Subject: Re: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01


> Hi Qin,
> 
> It is yet another subscription related policy decision.  An operator  
> might, for some reason, to have such functionality to be disabled. If  
> you go back to draft-ietf-dime-mip6-split-12, you can find all these  
> feature vector flag bits there.
> 
> If the AAA does not authorize the use of MCoA the HA shall act as it  
> would not support MCoA in the first place.
> 
> Cheers,
> Jouni
> 
> 
> On Jun 10, 2009, at 2:45 PM, Qin Wu wrote:
> 
>> Hi, Jouni:
>> When the HA support Multiple CoA feature, why should the AAA server   
>> care this feature?
>> If the AAA server neglectsthis feature or does not authorize the use  
>> of CoA, does it mean
>> mutiple CoA registration will fail or something else?
>> If I miss anything, please correct me.
>>
>> Regards!
>> -Qin
>> ----- Original Message -----
>> From: "jouni korhonen" 
>> To: 
>> Sent: Wednesday, June 10, 2009 5:55 PM
>> Subject: [Dime] Fwd: New Version Notification fordraft-korhonen-dime- 
>> mip6-feature-bits-01
>>
>>
>>> Hi all,
>>>
>>> I have updated the additional feature bits draft. I did remove some
>>> stuff so that the draft now only reserves MIP6-Feature-Vector flag
>>> bits and nothing more. I'll forward the draft soon to RFC editor so  
>>> if
>>> anyone has comments, please be quick :)
>>>
>>> Cheers,
>>> Jouni
>>>
>>> Begin forwarded message:
>>>
>>>> From: IETF I-D Submission Tool 
>>>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>>>> To: jouni.nospam@gmail.com
>>>> Subject: New Version Notification for  draft-korhonen-dime-mip6-
>>>> feature-bits-01
>>>>
>>>>
>>>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt
>>>> has been successfuly submitted by Jouni Korhonen and posted to the
>>>> IETF repository.
>>>>
>>>> Filename: draft-korhonen-dime-mip6-feature-bits
>>>> Revision: 01
>>>> Title: Diameter MIP6 Feature Vector Additional Bit Allocations
>>>> Creation_date: 2009-06-10
>>>> WG ID: Independent Submission
>>>> Number_of_pages: 5
>>>>
>>>> Abstract:
>>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
>>>> Home Agent and the Authentication, Authorization, and Accounting
>>>> server may exchange a set of authorized mobility capabilities.  This
>>>> document defines new mobility capability flags that are used to
>>>> authorize per Mobile Node route optimization, Multiple Care-of
>>>> Address and user plane traffic encryption support.  Furthermore,  
>>>> this
>>>> document also defines a capability flag of indicating whether the
>>>> Home Agent is authorized to act as a stand alone Virtual Private
>>>> Network gateway.
>>>>
>>>>
>>>>
>>>> The IETF Secretariat.
>>>>
>>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>

From jouni.nospam@gmail.com  Wed Jun 10 23:03:44 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372AD3A6899 for ; Wed, 10 Jun 2009 23:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvGP2PbidyMo for ; Wed, 10 Jun 2009 23:03:43 -0700 (PDT)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id DA6E83A67A7 for ; Wed, 10 Jun 2009 23:03:42 -0700 (PDT)
Received: by fxm9 with SMTP id 9so1287026fxm.37 for ; Wed, 10 Jun 2009 23:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=W0YFPpLPKeRu6Cu4FNteIJSuNmSm6upPYalY4QOHHFE=; b=L9z33Eg0Q0S0qV1lsI/IW7sFpPHoKUskltERszZFdnnl+3h5emeZodaNJEWb+/ZmRd nIBfGOsFuKAdeKqBF10Zs7MXiHb04BtIIgSith/HqQ29UfFN0rFkSTAnVhpELJLLsaZI zEYoiIIa42PNcu2YImeb3vwC/seh9PgHfbpoE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=QuhjxO4+ImpRP1ufm9qh8cfCkeOC5tSd5Mmb+hdzOJ7ctWQm/Ot3X6mt27EnrMW3rr QY2iZnxroTi96gW4VFxIGxTtoULau/JHmui2PU7/AxlvK0I0G+XNP9ZYvMFF1BtdhF/7 wHRV+uNCxyyMCJCnnHKfYIqclewK5Ipp1YPzY=
Received: by 10.204.117.16 with SMTP id o16mr2097316bkq.100.1244700226666; Wed, 10 Jun 2009 23:03:46 -0700 (PDT)
Received: from a88-114-166-189.elisa-laajakaista.fi (a88-114-166-189.elisa-laajakaista.fi [88.114.166.189]) by mx.google.com with ESMTPS id 28sm8412200fkx.54.2009.06.10.23.03.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 23:03:46 -0700 (PDT)
Message-Id: <2FA145BF-2534-4A2A-A878-C50A6B3C0087@gmail.com>
From: jouni korhonen 
To: Vijay Devarapalli 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 11 Jun 2009 09:03:45 +0300
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> 
X-Mailer: Apple Mail (2.935.3)
Cc: dime@ietf.org
Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2009 06:03:44 -0000

Hi Vijay,


On Jun 11, 2009, at 12:49 AM, Vijay Devarapalli wrote:

> Hi Jouni,
>
> I have a comment on the "VPN Gateway feature". There is no document
> that describes what it means for a Mobile IPv6 home agent to act as a
> VPN gateway. The IKEv2 exchange between the MN and the HA [RFC 4877
> and 5026] already supports mutual authentication, address assignment
> and setting up of tunnel mode ESP SAs. Are you referring to this as
> VPN mode? But isn't this regular Home agent functionality?

The "VPN mode" is when you use HA IKEv2/IPsec functionality purely for  
conventional VPN remote access purposes without any mobility. That  
type of deployment is shortly referenced in draft-ietf-dime-mip6-split  
Section 4.1. I recall this functionality was originally requested by  
Gerardo.

>
>
> Or is there a separate IPsec VPN that is first setup and then Mobile
> IPv6 is run on top of the IPsec tunnels?

As shortly described in split document:

    In some deployment scenarios, the HA may also act as an IKEv2
    Responder for a conventional IPsec VPN access.  The challenge in  
this
    case is that the IKEv2 responder may not know if IKEv2 is used for
    Mobile IPv6 service or for IPsec VPN access service.  A network
    operator needs to be aware of this limitation.  One solution already
    supported by IKEv2 is to use different responder identities when
    operating as a conventional IPsec VPN gateway or as a HA.  The MN  
can
    then indicate the preferred responder type using the appropriate IDr
    payload in the IKE_AUTH message.

But yeah, now that feature bits are taken into a separate document,  
the connection between the above and the new feature bit is rather  
weak. Either we need more text and/or reference in the draft-korhonen- 
dime-feature-bits or just remove the bit all together. Since the  
difference between conventional IKEv2 IPsec VPN gateway part and HA's  
IKEv2 IPsec functionality is rather small, I would keep the feature  
bit and enhance the text instead.

Jouni


>
>
> Vijay
>
> On Wed, Jun 10, 2009 at 2:55 AM, jouni  
> korhonen wrote:
>> Hi all,
>>
>> I have updated the additional feature bits draft. I did remove some  
>> stuff so
>> that the draft now only reserves MIP6-Feature-Vector flag bits and  
>> nothing
>> more. I'll forward the draft soon to RFC editor so if anyone has  
>> comments,
>> please be quick :)
>>
>> Cheers,
>>        Jouni
>>
>> Begin forwarded message:
>>
>>> From: IETF I-D Submission Tool 
>>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>>> To: jouni.nospam@gmail.com
>>> Subject: New Version Notification for
>>>  draft-korhonen-dime-mip6-feature-bits-01
>>>
>>>
>>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt  
>>> has
>>> been successfuly submitted by Jouni Korhonen and posted to the IETF
>>> repository.
>>>
>>> Filename:        draft-korhonen-dime-mip6-feature-bits
>>> Revision:        01
>>> Title:           Diameter MIP6 Feature Vector Additional Bit  
>>> Allocations
>>> Creation_date:   2009-06-10
>>> WG ID:           Independent Submission
>>> Number_of_pages: 5
>>>
>>> Abstract:
>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
>>> Home Agent and the Authentication, Authorization, and Accounting
>>> server may exchange a set of authorized mobility capabilities.  This
>>> document defines new mobility capability flags that are used to
>>> authorize per Mobile Node route optimization, Multiple Care-of
>>> Address and user plane traffic encryption support.  Furthermore,  
>>> this
>>> document also defines a capability flag of indicating whether the
>>> Home Agent is authorized to act as a stand alone Virtual Private
>>> Network gateway.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>


From jouni.nospam@gmail.com  Wed Jun 10 23:28:10 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4092528C108 for ; Wed, 10 Jun 2009 23:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vze41AO91kN6 for ; Wed, 10 Jun 2009 23:28:09 -0700 (PDT)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 89C1B3A6973 for ; Wed, 10 Jun 2009 23:28:08 -0700 (PDT)
Received: by fxm9 with SMTP id 9so1295129fxm.37 for ; Wed, 10 Jun 2009 23:28:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=dzn82mUe3R66DrTnV+NITybi0vFGbQ++fO0CHUM3CV8=; b=KmBYwJLXjjly2Nq30pTphfbWtx6gnIrVj0oZB4qxfmEZoTLFwRUuk9zOM6dKPDNtKi zSc833tmWCmQGSycgEqpWn8T7tGP/n7OgnoAF3KTvAyzNlS/F0W3hhnYWGS2AyfeHyhZ 6tsAV8sb/0rnDGs1s9do+IIzf4lB0M10E5GSU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=x3cNz8P2RtbNFiNivnipZt9LE9lEjLhm3kwGgwQyacDkxTdtlZuRelZiR760TTFlXO ZsA/VMPQ82XCDcc8iU+sT8vWDdpRMCYgwDC+dfhJuEUxFAE1avlHqJfNzE3Saq+qebMh PV2VBxkbCaVwQj1diClhWSEC6ZpRhpViAtTcc=
Received: by 10.204.66.69 with SMTP id m5mr2112295bki.174.1244701691862; Wed, 10 Jun 2009 23:28:11 -0700 (PDT)
Received: from a88-114-166-189.elisa-laajakaista.fi (a88-114-166-189.elisa-laajakaista.fi [88.114.166.189]) by mx.google.com with ESMTPS id 18sm8450073fkq.26.2009.06.10.23.28.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 23:28:11 -0700 (PDT)
Message-Id: 
From: jouni korhonen 
To: Vijay Devarapalli 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 11 Jun 2009 09:28:10 +0300
References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> 
X-Mailer: Apple Mail (2.935.3)
Cc: dime@ietf.org
Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2009 06:28:10 -0000

Hi Vijay,

On Jun 11, 2009, at 12:51 AM, Vijay Devarapalli wrote:

> I have another question.
>
> Why does encrypting the payload traffic between the MN and the HA need
> AAA authorization?

IMHO payload traffic encryption is a potential place for a policy  
decision. An operator may want to control it depending on the  
deployment and the subscription in situations where the the same HA  
could be used for various types of deployments. As you know e.g.  
certain SDOs purposely forbid the use of payload encryption in their  
environment where as that might not make sense in other type of  
deployment.

Jouni

>
>
> Vijay
>
> On Wed, Jun 10, 2009 at 2:55 AM, jouni  
> korhonen wrote:
>> Hi all,
>>
>> I have updated the additional feature bits draft. I did remove some  
>> stuff so
>> that the draft now only reserves MIP6-Feature-Vector flag bits and  
>> nothing
>> more. I'll forward the draft soon to RFC editor so if anyone has  
>> comments,
>> please be quick :)
>>
>> Cheers,
>>        Jouni
>>
>> Begin forwarded message:
>>
>>> From: IETF I-D Submission Tool 
>>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>>> To: jouni.nospam@gmail.com
>>> Subject: New Version Notification for
>>>  draft-korhonen-dime-mip6-feature-bits-01
>>>
>>>
>>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt  
>>> has
>>> been successfuly submitted by Jouni Korhonen and posted to the IETF
>>> repository.
>>>
>>> Filename:        draft-korhonen-dime-mip6-feature-bits
>>> Revision:        01
>>> Title:           Diameter MIP6 Feature Vector Additional Bit  
>>> Allocations
>>> Creation_date:   2009-06-10
>>> WG ID:           Independent Submission
>>> Number_of_pages: 5
>>>
>>> Abstract:
>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
>>> Home Agent and the Authentication, Authorization, and Accounting
>>> server may exchange a set of authorized mobility capabilities.  This
>>> document defines new mobility capability flags that are used to
>>> authorize per Mobile Node route optimization, Multiple Care-of
>>> Address and user plane traffic encryption support.  Furthermore,  
>>> this
>>> document also defines a capability flag of indicating whether the
>>> Home Agent is authorized to act as a stand alone Virtual Private
>>> Network gateway.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>


From hannes.tschofenig@nsn.com  Thu Jun 11 01:20:57 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E513A6B82; Thu, 11 Jun 2009 01:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.439
X-Spam-Level: 
X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eht63uL49ax9; Thu, 11 Jun 2009 01:20:56 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id BCDFB3A6939; Thu, 11 Jun 2009 01:20:55 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n5B8Ku7d011382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Jun 2009 10:20:56 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n5B8KtWw010339; Thu, 11 Jun 2009 10:20:56 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 11 Jun 2009 10:20:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Jun 2009 11:22:52 +0300
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45016DD142@FIESEXC015.nsn-intra.net>
In-Reply-To: <27D17F29-6B98-482C-A3EB-7DE170B14F1E@huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HOKEY] [Dime] New draft for Diameter ERP: poll for adoption
Thread-Index: AcnpgzJOvv1YzaqOTi6zidbMN49UJgA6hxLA
References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net> <27D17F29-6B98-482C-A3EB-7DE170B14F1E@huawei.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Tina TSOU" 
X-OriginalArrivalTime: 11 Jun 2009 08:20:54.0770 (UTC) FILETIME=[8A32F520:01C9EA6D]
Cc: dime@ietf.org, hokey@ietf.org
Subject: Re: [Dime] [HOKEY]  New draft for Diameter ERP: poll for adoption
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2009 08:20:57 -0000

Hi Tina,=20
=20
thanks for the support regarding the Diameter ERP work.=20
I hope the excitement for it will also result in some running code that
would help us to make the design decisions in a better fashion.=20

When I was talking to Sebastien recently we were wondering whether there
is HOKEY ERP code available somewhere since this is a pre-requisite for
the implementation of the Diameter ERP stuff.=20

Ciao
Hannes
=20


________________________________

	From: ext Tina TSOU [mailto:tena@huawei.com]=20
	Sent: 10 June, 2009 07:23
	To: Tschofenig, Hannes (NSN - FI/Espoo)
	Cc: ext Julien Bournelle; Sebastien Decugis; dime@ietf.org;
hokey@ietf.org
	Subject: Re: [HOKEY] [Dime] New draft for Diameter ERP: poll for
adoption
=09
=09
	Hi Hannes,
	Thank you for your clarification. It is much clearer.
	This change should be made, since ERP is one of the most
important applications for Diameter.

=09
eak-word; -webkit-nbsp-mode: space; -webkit-line-break:
after-white-space; ">=20
					B. R.
	Tina
	IPTIME - Unified QoS ARchitecture (UQAr) [ju'ka:] /pronounced
like "you"+"car"/
	UQAr@huawei.com
	http://uqar.weebly.com

	http://tinatsou.weebly.com/contact.html
=09

=09
=09

							>
						=09
=09

	On Jun 9, 2009, at 4:46 PM, Tschofenig, Hannes (NSN - FI/Espoo)
wrote:


		Hi all,=20
	=09
		there seems to be a misunderstanding here.=20
	=09
		We have a working group document with agreed authors.=20
		The only question therefore is what the group wants to
go into the
		existing document - the content. No new document will be
added to the
		DIME milestones.
	=09
		What Sebastien should be asking the group is whether the
content in
		draft-sdecugis-dime-diameter-erp-01.txt should be
included in the next
		version of draft-ietf-dime-erp.=20
	=09
		I personally think that draft-ietf-dime-erp-01 could
have included the
		updated text already since we discussed it on the list.
Anyway, ...=20
	=09
		In any case, it is good to ask the group whether this
significant change
		s answer: I believe that this is the right direction, as
I indicated
		previously on the list.=20
	=09
		Ciao
		Hannes
	=09
	=09
	=09
	=09
		________________________________
	=09
		From: dime-bounces@ietf.org
[mailto:dime-bounces@ietf.org] On
		Behalf Of ext Julien Bournelle
		Sent: 09 June, 2009 10:02
		To: Sebastien Decugis
		Cc: dime@ietf.org; hokey@ietf.org
		Subject: Re: [Dime] New draft for Diameter ERP: poll for
		adoption
	=09
	=09
		Hello,
	=09
		See inline,
	=09
	=09
		On Mon, Jun 8, 2009 at 5:57 AM, Sebastien Decugis
		 wrote:
	=09
	=09
		Hi all DIME and HOKEY members,
	=09
		I have gone forward on the >created a new draft
		[1] with the same content (re-organized, hopefully for
		clarity) as I
		presented during last DIME meeting in IETF#74. The main
		change with
		current draft-ietf-dime-erp-00 is the use of a new
		separate Diameter
		application for messages exchanged between the NAS and
		the ER server.
	=09
		I would like to poll the people interested in this topic
		about the
		adoption of this new document for Diameter ERP (in which
		case it would
		become draft-ietf-dime-erp-01). I don't know if this can
		be done before
		the next IETF meeting, or at least during the meeting in
		Stockholm?
	=09
	=09
	=09
		AFAIK, this is not how things are working at IETF. The
WG has
		already a WG document called draf ich is
		supposed to reflect the current WG consensus. We can't
arrive with a new
		individual submission and just bypass the current WG
I-D. At least, I
		never saw that.
	=09
		Having said that, we have an issue with the current WG
document
		concerning use of a new Application-ID or reuse of the
Diameter EAP. My
		understanding was that we were a little blocked because
of an
		architectural issue concerning the HOKEY server in
regards to AAA/EAP
		server and because of a routing issue. So I'd like to
know what has
		changed from this point.
	=09
		Note that I'm not against your proposal per se. We just
have to
		get a consensus.
	=09
	=09
		Julien
	=09
	=09
	=09
	=09
		Thank you for reading, and eventually providing your
		comments.
		Sebastien.
	=09
		[1]
	=09
=09
http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01.
		txt
	=09
		--
		Sebastien Decugis
		Research fellow
		Network Architecture Group
		NICT (nict.go.jp)
	=09
		_______________________________________________
		DiME mailing list
		DiME@ietf.org
		https://www.ietf.org/mailman/listinfo/dime
	=09
	=09
	=09
		______________________
		HOKEY mailing list
		HOKEY@ietf.org
		https://www.ietf.org/mailman/listinfo/hokey
	=09


=09

From glenzorn@comcast.net  Thu Jun 11 08:25:17 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD793A6D37 for ; Thu, 11 Jun 2009 08:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level: 
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.721,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DSf44+eAvKh for ; Thu, 11 Jun 2009 08:25:16 -0700 (PDT)
Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 7D4A03A6D24 for ; Thu, 11 Jun 2009 08:25:15 -0700 (PDT)
Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 2ZzR1c0030ldTLk52fRPbi; Thu, 11 Jun 2009 15:25:23 +0000
Received: from gwzPC ([124.122.163.40]) by OMTA04.westchester.pa.mail.comcast.net with comcast id 2fQy1c00c0scVYk3QfR51U; Thu, 11 Jun 2009 15:25:21 +0000
From: "Glen Zorn" 
To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Julien Bournelle'" , "'Sebastien Decugis'" 
References: <4A2C8C10.1010507@nict.go.jp>	<5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net>
Date: Thu, 11 Jun 2009 22:21:35 +0700
Message-ID: <00ad01c9eaa8$5d067780$17136680$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acno0CU9sHLcM8JZR+ykiO5MqMUSogAAFzsgAHXYs6A=
Content-Language: en-us
Cc: dime@ietf.org, hokey@ietf.org
Subject: Re: [Dime] [HOKEY]  New draft for Diameter ERP: poll for adoption
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2009 15:25:17 -0000

Tschofenig, Hannes (NSN - FI/Espoo) [mailto://hannes.tschofenig@nsn.com]
writes:

> Hi all,
> 
> there seems to be a misunderstanding here.
> 
> We have a working group document with agreed authors.
> The only question therefore is what the group wants to go into the
> existing document - the content. No new document will be added to the
> DIME milestones.
> 
> What Sebastien should be asking the group is whether the content in
> draft-sdecugis-dime-diameter-erp-01.txt should be included in the next
> version of draft-ietf-dime-erp.

Yes.

> 
> I personally think that draft-ietf-dime-erp-01 could have included the
> updated text already since we discussed it on the list. Anyway, ...

Yes.

> 
> In any case, it is good to ask the group whether this significant
> change
> should be made.
> 
> My answer: I believe that this is the right direction, as I indicated
> previously on the list.

A quick review and comparison with the WG draft suggests to me that the new
doc is an improvement.

> 
> Ciao
> Hannes
> 
> 
> 
> 
> ________________________________
> 
> 	From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
> Behalf Of ext Julien Bournelle
> 	Sent: 09 June, 2009 10:02
> 	To: Sebastien Decugis
> 	Cc: dime@ietf.org; hokey@ietf.org
> 	Subject: Re: [Dime] New draft for Diameter ERP: poll for
> adoption
> 
> 
> 	Hello,
> 
> 	 See inline,
> 
> 
> 	On Mon, Jun 8, 2009 at 5:57 AM, Sebastien Decugis
>  wrote:
> 
> 
> 		Hi all DIME and HOKEY members,
> 
> 		I have gone forward on the Diameter ERP topic and
> created a new draft
> 		[1] with the same content (re-organized, hopefully for
> clarity) as I
> 		presented during last DIME meeting in IETF#74. The main
> change with
> 		current draft-ietf-dime-erp-00 is the use of a new
> separate Diameter
> 		application for messages exchanged between the NAS and
> the ER server.
> 
> 		I would like to poll the people interested in this topic
> about the
> 		adoption of this new document for Diameter ERP (in which
> case it would
> 		become draft-ietf-dime-erp-01). I don't know if this can
> be done before
> 		the next IETF meeting, or at least during the meeting in
> Stockholm?
> 
> 
> 
> 	AFAIK, this is not how things are working at IETF. The WG has
> already a WG document called draft-ietf-dime-erp-00.txt which is
> supposed to reflect the current WG consensus. We can't arrive with a
> new
> individual submission and just bypass the current WG I-D. At least, I
> never saw that.
> 
> 	Having said that, we have an issue with the current WG document
> concerning use of a new Application-ID or reuse of the Diameter EAP. My
> understanding was that we were a little blocked because of an
> architectural issue concerning the HOKEY server in regards to AAA/EAP
> server and because of a routing issue. So I'd like to know what has
> changed from this point.
> 
> 	 Note that I'm not against your proposal per se. We just have to
> get a consensus.
> 
> 	 Best regards,
> 
> 	 Julien
> 
> 
> 
> 
> 		Thank you for reading, and eventually providing your
> comments.
> 		Sebastien.
> 
> 		[1]
> 
> http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-
> 01.
> txt
> 
> 		--
> 		Sebastien Decugis
> 		Research fellow
> 		Network Architecture Group
> 		NICT (nict.go.jp)
> 
> 		_______________________________________________
> 		DiME mailing list
> 		DiME@ietf.org
> 		https://www.ietf.org/mailman/listinfo/dime
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey


From tnvee.vj@gmail.com  Thu Jun 11 10:58:02 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731203A6BEE for ; Thu, 11 Jun 2009 10:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhGglwqonzg9 for ; Thu, 11 Jun 2009 10:58:01 -0700 (PDT)
Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by core3.amsl.com (Postfix) with ESMTP id 6A6853A6954 for ; Thu, 11 Jun 2009 10:58:00 -0700 (PDT)
Received: by bwz27 with SMTP id 27so73718bwz.43 for ; Thu, 11 Jun 2009 10:58:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=YO6bsnDhWkfRWEcjOBhxiId1MX2txsjMQZplIiI41WE=; b=N+0ayg0fDD3cboqAYJ2fc3XMTvQ/Sh4+2NTFI13hMGbhbSK52s6vww/Elu7JAFBbdI T9ssX6m8llxS7JkkgfnvMCBWlvFEXEs+jiqGVuZ0seQaL8W5eFWvKBGXOJ1dwQ4Prpwg C4B9KzzITEOSgSzNpYaLUpHtGX+G+x3suJS9Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=GlUKUACwuVZfGqXHZ2E6mSuoC6bqfZJotSvaiZcJE1lo2iUlRSPvk1S/sKsfdiUYef 1izxYeUwFsIW29nmULpTM27l1QhXfGZWMtO3wreO2SQnUDHhls1OcE/FKAm26fcrKh/6 rCsGggkAvXUy8uz3/ZW+iP4Qtox5wnjXBgIm4=
MIME-Version: 1.0
Received: by 10.204.113.12 with SMTP id y12mr2703951bkp.214.1244743085757;  Thu, 11 Jun 2009 10:58:05 -0700 (PDT)
Date: Thu, 11 Jun 2009 19:58:05 +0200
Message-ID: 
From: Vijay Iyengar 
To: dime@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Dime] rfc3588 query
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2009 17:58:02 -0000

Hi ,

I have a question or I am confused.

The command flags as defined in Chapter 3 in RFC3588 are as below

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |R P E T r r r r|
      +-+-+-+-+-+-+-+-+

How would exactly this look on the wire? Will be 0x80 or 0x01? I am
getting confused with the illustration of the DIAMETER header format
and the bits.

Thanks in advance.

Regards
Vj




3. Diameter Header


   A summary of the Diameter header format is shown below.  The fields
   are transmitted in network byte order.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |                 Message Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | command flags |                  Command-Code                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Application-ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Hop-by-Hop Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      End-to-End Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AVPs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Version
      This Version field MUST be set to 1 to indicate Diameter Version
      1.

   Message Length
      The Message Length field is three octets and indicates the length
      of the Diameter message including the header fields.

   Command Flags
      The Command Flags field is eight bits.  The following bits are
      assigned:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |R P E T r r r r|
      +-+-+-+-+-+-+-+-+

      R(equest)   - If set, the message is a request.  If cleared, the
                    message is an answer.
      P(roxiable) - If set, the message MAY be proxied, relayed or
                    redirected.  If cleared, the message MUST be
                    locally processed.
      E(rror)     - If set, the message contains a protocol error,
                    and the message will not conform to the ABNF
                    described for this command.  Messages with the 'E'

From jnordqvist@alcatel-lucent.com  Thu Jun 11 11:18:06 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BBBD3A687F for ; Thu, 11 Jun 2009 11:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlsEB74no-Ki for ; Thu, 11 Jun 2009 11:18:05 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 6E32E3A6873 for ; Thu, 11 Jun 2009 11:18:04 -0700 (PDT)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n5BIIA4i025487;  Thu, 11 Jun 2009 13:18:10 -0500 (CDT)
Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n5BII9LU017551; Thu, 11 Jun 2009 13:18:09 -0500 (CDT)
Received: from [192.168.0.38] (clover.8950aaa.com [192.168.0.38]) by hal.8950aaa.com (Postfix) with ESMTP id D85F85C1B2; Thu, 11 Jun 2009 11:18:08 -0700 (PDT)
Message-ID: <4A314A4F.9090300@alcatel-lucent.com>
Date: Thu, 11 Jun 2009 11:17:51 -0700
From: Jan Nordqvist 
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Vijay Iyengar 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: dime@ietf.org
Subject: Re: [Dime] rfc3588 query
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2009 18:18:06 -0000

VJ,

It is per IETF standard, i.e. only R set would appear as 0x80 in your 
computer memory receive buffer. (On the wire it would appear as a pulse 
train :)

Jan Nordqvist

Vijay Iyengar wrote:
> Hi ,
>
> I have a question or I am confused.
>
> The command flags as defined in Chapter 3 in RFC3588 are as below
>
>        0 1 2 3 4 5 6 7
>       +-+-+-+-+-+-+-+-+
>       |R P E T r r r r|
>       +-+-+-+-+-+-+-+-+
>
> How would exactly this look on the wire? Will be 0x80 or 0x01? I am
> getting confused with the illustration of the DIAMETER header format
> and the bits.
>
> Thanks in advance.
>
> Regards
> Vj
>
>
>
>
> 3. Diameter Header
>
>
>    A summary of the Diameter header format is shown below.  The fields
>    are transmitted in network byte order.
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Version    |                 Message Length                |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | command flags |                  Command-Code                 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Application-ID                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Hop-by-Hop Identifier                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      End-to-End Identifier                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  AVPs ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-
>
>    Version
>       This Version field MUST be set to 1 to indicate Diameter Version
>       1.
>
>    Message Length
>       The Message Length field is three octets and indicates the length
>       of the Diameter message including the header fields.
>
>    Command Flags
>       The Command Flags field is eight bits.  The following bits are
>       assigned:
>
>        0 1 2 3 4 5 6 7
>       +-+-+-+-+-+-+-+-+
>       |R P E T r r r r|
>       +-+-+-+-+-+-+-+-+
>
>       R(equest)   - If set, the message is a request.  If cleared, the
>                     message is an answer.
>       P(roxiable) - If set, the message MAY be proxied, relayed or
>                     redirected.  If cleared, the message MUST be
>                     locally processed.
>       E(rror)     - If set, the message contains a protocol error,
>                     and the message will not conform to the ABNF
>                     described for this command.  Messages with the 'E'
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>   


From tena@huawei.com  Thu Jun 11 21:52:07 2009
Return-Path: 
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE1E3A63CB for ; Thu, 11 Jun 2009 21:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.632
X-Spam-Level: 
X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, SARE_RECV_IP_219128=1.666]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNXK1wCKO0O7 for ; Thu, 11 Jun 2009 21:52:06 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 5D28F3A6DA0 for ; Thu, 11 Jun 2009 21:52:05 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL3009SVZPAO8@szxga01-in.huawei.com> for dime@ietf.org; Fri, 12 Jun 2009 12:41:35 +0800 (CST)
Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL300EHDZPAXF@szxga01-in.huawei.com> for dime@ietf.org; Fri, 12 Jun 2009 12:41:34 +0800 (CST)
Received: from [192.168.5.105] (183.216.133.219.broad.sz.gd.dynamic.163data.com.cn [219.133.216.183]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0KL3002CHZP802@szxml01-in.huawei.com>; Fri, 12 Jun 2009 12:41:34 +0800 (CST)
Date: Fri, 12 Jun 2009 12:41:31 +0800
From: Tina TSOU 
In-reply-to: <3521BC55-4B72-4AAE-9796-42BA4872BFC3@huawei.com>
To: dime@ietf.org
Message-id: 
MIME-version: 1.0
X-Mailer: Apple Mail (2.930.3)
Content-type: multipart/alternative; boundary="Boundary_(ID_vLN/r0/2hlAZGriS7ZAC5w)"
References: <3D3C75174CB95F42AD6BCC56E5555B4501684A67@FIESEXC015.nsn-intra.net>  <01b901c9e5bc$cab965d0$0301a8c0@nsnintra.net> <3521BC55-4B72-4AAE-9796-42BA4872BFC3@huawei.com>
Subject: Re: [Dime] DIME Rechartering (Update)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Jun 2009 04:52:07 -0000

--Boundary_(ID_vLN/r0/2hlAZGriS7ZAC5w)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT

Hi,
As requested by Hannes, here is the pointer of a separate I-D for it.
http://www.ietf.org/internet-drafts/draft-tsou-dime-realm-based-redirect-00.txt
You comments are welcome.

Hannes, would you ask the WG consensus now?

Have a nice weekend:)


B. R.
Tina
http://tinatsou.weebly.com/contact.html




On Jun 9, 2009, at 2:55 PM, Tina TSOU wrote:

> Hi Hannes,
> It was in
> http://groups.google.com/group/diameter-routing/browse_thread/thread/6750c39d5970aada?hl=en
>
> 3.  Use Cases
> ...
> 3.2.  Redirect Indication based on realm
>
>    Consider an Operator; say Operator_A offering some service to
>    Diameter client in its Realm; say Realm_A. For business/maintenance
>    reasons, the operator wants to discontinue the service.  However  
> the
>    operator has asked another Operator; say Operator_B (serving  
> Realm_B)
>    to provide the service to the clients.  In this case, all the  
> clients
>    should be configured to contact Realm_B instead of Realm_A for the
>    service.
>
>    For smooth transition, agents may be employed in Realm_A which  
> could
>    answer with a redirect indication suggesting that the service
>    requests may be sent to another realm; Realm_B in this case, so  
> as to
>    be served
> ...
> 4.  Problem Statements
> ...
> 4.3.  Redirect Indication based on realm
>
>    This is the statement of the problem posed by the case presented in
>    Section 3.2.
>
>    1.  Existing Diameter message routing behaviour: Redirect  
> indication
>        is provided at host level.  It provides a list of servers that
>        may be contacted for the request to be served.
>
>    2.  Undesirable behaviour in the existing method: Redirect  
> indication
>        is not provided at the realm level.  There is no option to
>        provide a (list of) realm(s) that may be contacted for the
>        request to be served.
>
>    3.  Desired behaviour: Redirect indication could be provided at the
>        realm level also.  The indication may specify a (list of)
>        realm(s) which could be contacted for the request to be served.
>
> B. R.
> Tina
> http://tinatsou.weebly.com/contact.html
>
>
>
>
> On Jun 5, 2009, at 5:05 PM, Hannes Tschofenig wrote:
>
>> Could you send the link to the draft around?
>>
>>
>>
>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On  
>> Behalf Of Tina TSOU
>> Sent: 05 June, 2009 11:57
>> To: Tschofenig, Hannes (NSN - FI/Espoo)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] DIME Rechartering (Update)
>>
>> Could the redirect at realm level be included?
>>
>> http://tinatsou.weebly.com/contact.html
>>
>>
>>
>>
>>
>> On Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo)  
>> wrote:
>>
>>> Based on the feedback I have updated the text.
>>> <>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://w ww.ietf.
>>
>


--Boundary_(ID_vLN/r0/2hlAZGriS7ZAC5w)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: quoted-printable


Hi,
As requested =
by Hannes, here is the pointer of a separate I-D for =
it.
You comments are =
welcome.

Hannes, would you ask the WG consensus =
now?

Have a nice =
weekend:)


=
 
On Jun 9, 2009, at 2:55 PM, Tina TSOU =
wrote:

Hi =
Hannes,
It was in

<=
div>
3.  Use Cases
...
3.2.  =
Redirect Indication based on realm

   Consider an Operator; say Operator_A offering some service to
   Diameter client in its Realm; say Realm_A. For business/maintenance
   reasons, the operator wants to discontinue the service.  However the
   operator has asked another Operator; say Operator_B (serving Realm_B)
   to provide the service to the clients.  In this case, all the clients
   should be configured to contact Realm_B instead of Realm_A for the
   service.

   For smooth transition, agents may be employed in Realm_A which could
   answer with a redirect indication suggesting that the service
   requests may be sent to another realm; Realm_B in this case, so as to
   be served
...
4.  Problem Statements
...
 
On Jun 5, 2009, at 5:05 PM, Hannes Tschofenig =
wrote:

 
 
Could you send the link to the draft =
around? 
 
 
 
 

 =

  
 =
 
  From: dime-bounces@ietf.org   [mailto:dime-bounces@ietf.org] =
On Behalf Of Tina TSOU
Sent:   05 June, 2009 =
11:57
To: Tschofenig, Hannes (NSN -   FI/Espoo)
Cc: =
dime@ietf.org
Subject: =
Re: [Dime] DIME   Rechartering (Update)

  =

Could the redirect at realm level be included?  

  =
  

  

  
  
On =
Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo)   =
wrote:

  
    
Based on the feedback I have updated the text. =
    
<<dime-recharter.pdf>>     =

<dime-recharter.pdf>_____________________=
__________________________
DiME     mailing list
DiME@ietf.org
https://w ww.ietf.   

  =


= --Boundary_(ID_vLN/r0/2hlAZGriS7ZAC5w)-- From gwz@net-zen.net Thu Jun 11 22:06:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2403A6A71 for ; Thu, 11 Jun 2009 22:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgOZE27j227n for ; Thu, 11 Jun 2009 22:06:35 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id AD1463A63CB for ; Thu, 11 Jun 2009 22:06:35 -0700 (PDT) Received: (qmail 3032 invoked from network); 12 Jun 2009 05:06:39 -0000 Received: from unknown (124.122.161.93) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 12 Jun 2009 05:06:38 -0000 From: "Glen Zorn" To: "'Vijay Iyengar'" References: In-Reply-To: Date: Fri, 12 Jun 2009 12:03:14 +0700 Organization: Network Zen Message-ID: <000001c9eb1b$19d9fa90$4d8defb0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnqvi+YzgCzyQysT/23ylIOQC2H9AAUuK6Q Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] rfc3588 query X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 05:06:37 -0000 Vijay Iyengar [mailto://tnvee.vj@gmail.com] writes: ... > I have a question or I am confused. > > The command flags as defined in Chapter 3 in RFC3588 are as below > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |R P E T r r r r| > +-+-+-+-+-+-+-+-+ > > How would exactly this look on the wire? Will be 0x80 or 0x01? I am > getting confused with the illustration of the DIAMETER header format > and the bits. It _is_ different from the way in which bit are usually numbered in, for example, computer science textbooks (where the bits are normally numbered from right to left w/the least significant bit numbered zero (i.e., the number of the bit corresponds to its binary exponent)). In Diameter (and RADIUS and PPP), bits are labeled in order of transmission, from left to right. ... From hannes.tschofenig@nsn.com Thu Jun 11 22:42:28 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3C53A688F for ; Thu, 11 Jun 2009 22:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+7FRdej5o4y for ; Thu, 11 Jun 2009 22:42:27 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 81EEF3A63CB for ; Thu, 11 Jun 2009 22:42:26 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n5C5gXte027629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 Jun 2009 07:42:33 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n5C5gX20014082 for ; Fri, 12 Jun 2009 07:42:33 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 07:42:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 08:44:30 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501711EDC@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HUM regarding draft-tsou-dime-realm-based-redirect-00.txt Thread-Index: AcnrINsCKkzvXRhiR12SCJLJN+1dFQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Jun 2009 05:42:32.0992 (UTC) FILETIME=[951C7200:01C9EB20] Subject: [Dime] HUM regarding draft-tsou-dime-realm-based-redirect-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 05:42:28 -0000 Hi all,=20 Tina had been repeately been asking whether the functionality of realm-based redirect can become a chartered working group item. Now, an independent I-D describing the problem and the solution is available, see "Realm-Based Redirection In Diameter": http://www.ietf.org/internet-drafts/draft-tsou-dime-realm-based-redirect -00.txt Please let us know whether you would want draft-tsou-dime-realm-based-redirect-00.txt to become a working group item in DIME or whether you have objections.=20 Deadline: June 26th.=20 Ciao Hannes & Victor PS: Comments to the draft are also welcome! From gwz@net-zen.net Thu Jun 11 23:19:06 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46633A6AAA for ; Thu, 11 Jun 2009 23:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN-pRCAXr0lp for ; Thu, 11 Jun 2009 23:19:06 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id DE4DF3A6C19 for ; Thu, 11 Jun 2009 23:19:05 -0700 (PDT) Received: (qmail 15693 invoked from network); 12 Jun 2009 06:19:13 -0000 Received: from unknown (124.122.161.93) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 12 Jun 2009 06:19:11 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'Victor Fajardo'" References: <3D3C75174CB95F42AD6BCC56E5555B4501711EDC@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501711EDC@FIESEXC015.nsn-intra.net> Date: Fri, 12 Jun 2009 13:15:46 +0700 Organization: Network Zen Message-ID: <002c01c9eb25$3c8fbca0$b5af35e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnrINsCKkzvXRhiR12SCJLJN+1dFQABC9Vw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] HUM regarding draft-tsou-dime-realm-based-redirect-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 06:19:06 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto://hannes.tschofenig@nsn.com] writes: > Hi all, > > Tina had been repeately been asking whether the functionality of > realm-based redirect can become a chartered working group item. Now, an > independent I-D describing the problem and the solution is available, > see "Realm-Based Redirection In Diameter": > http://www.ietf.org/internet-drafts/draft-tsou-dime-realm-based- > redirect > -00.txt > > Please let us know whether you would want > draft-tsou-dime-realm-based-redirect-00.txt to become a working group > item in DIME or whether you have objections. OK w/me. ... From gwz@net-zen.net Fri Jun 12 23:50:41 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B4A3A69B9 for ; Fri, 12 Jun 2009 23:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y27N+jKIX9bg for ; Fri, 12 Jun 2009 23:50:40 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id 8315E3A6887 for ; Fri, 12 Jun 2009 23:50:40 -0700 (PDT) Received: (qmail 16431 invoked from network); 13 Jun 2009 06:50:48 -0000 Received: from unknown (124.122.162.56) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 13 Jun 2009 06:50:48 -0000 From: "Glen Zorn" To: "'Tina TSOU'" Date: Sat, 13 Jun 2009 13:47:21 +0700 Organization: Network Zen Message-ID: <001101c9ebf2$d0af4450$720dccf0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnr8s08QkLa1a6TRiOB3KUkHHYFiw== Content-Language: en-us Cc: dime@ietf.org Subject: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 06:50:41 -0000 Section 2 says: Note that regardless of which approach is used, the original operator cannot escape the necessity to specify at least one individual Redirect-Host in indications to upstream Diameter nodes that cannot handle realm-based redirection. That being the case, this capability seems pretty much useless. Presumably, one of the main purposes of realm-based redirection is to allow SPs to avoid keeping track of Diameter nodes in other realms, but if one node needs to be tracked, why not all? Therefore, I think that this draft needs to be changed to either a) define a new application (so that realm-based redirection support can be advertised) or b) changed to Standards-Track & stated to update RFC 3588. ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From gwz@net-zen.net Sat Jun 13 00:23:17 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0827C3A659C for ; Sat, 13 Jun 2009 00:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLsnDGFXnDIE for ; Sat, 13 Jun 2009 00:23:16 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 41B9D3A67F5 for ; Sat, 13 Jun 2009 00:23:16 -0700 (PDT) Received: (qmail 28157 invoked from network); 13 Jun 2009 07:23:24 -0000 Received: from unknown (124.122.162.56) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 13 Jun 2009 07:23:23 -0000 From: "Glen Zorn" To: Date: Sat, 13 Jun 2009 14:19:57 +0700 Organization: Network Zen Message-ID: <001201c9ebf7$5e0f72d0$1a2e5870$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnr91rMe+YL0ga2RJi8TAsTqez5MQ== Content-Language: en-us Subject: [Dime] WGLC comment on rfc3588bis: section 11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 07:23:17 -0000 Section 11.4, Paragraph 2 says IANA [RFC5226] has assigned the range 0x00000001 to 0x00ffffff for standards-track applications; and 0x01000000 - 0xfffffffe for vendor specific applications, on a first-come, first-served basis. The following values are allocated. RFC 5226 is not a definition of IANA, it contains guidelines regarding policies for namespaces managed by the IANA. Suggest changing this to: IANA has allocated the range 0x00000001 to 0x00ffffff for standards-track applications; and 0x01000000 - 0xfffffffe for vendor- specific applications, on a first-come, first-served basis. The following values are assigned in this document: Also, I can't see why the reference to BCP 26 in section 11. isn't sufficient for the whole section; the constant referencing of RFC 5226 seems redundant and distracting to me. ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From sdecugis@nict.go.jp Sun Jun 14 20:12:54 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A5A3A6907 for ; Sun, 14 Jun 2009 20:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, FRT_SOMA2=2.199, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaHgBMhwv8+x for ; Sun, 14 Jun 2009 20:12:53 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 126863A6903 for ; Sun, 14 Jun 2009 20:12:52 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n5F3Cer7014974; Mon, 15 Jun 2009 12:12:40 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n5F3Cev8016163; Mon, 15 Jun 2009 12:12:40 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n5F3CdS4016160; Mon, 15 Jun 2009 12:12:39 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id DBC2615F7B; Mon, 15 Jun 2009 12:12:39 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id D64A15391; Mon, 15 Jun 2009 12:12:39 +0900 (JST) Message-ID: <4A35BC11.2060005@nict.go.jp> Date: Mon, 15 Jun 2009 12:12:17 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "'Tina TSOU'" References: <001101c9ebf2$d0af4450$720dccf0$@net> In-Reply-To: <001101c9ebf2$d0af4450$720dccf0$@net> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 03:12:54 -0000 Hi, I have a naive question. Is it not possible to define a new error code (distinct from DIAMETER_REDIRECT_INDICATION) for this purpose, to get rid of managing a single host in the redirect agent? I guess this would also imply update of RFC 3588, but at least backward compatibility issues can be removed from the draft. Best regards, Sebastien. Glen Zorn a écrit : > Section 2 says: > > Note that regardless of which approach is used, the original operator > cannot escape the necessity to specify at least one individual > Redirect-Host in indications to upstream Diameter nodes that cannot > handle realm-based redirection. > > That being the case, this capability seems pretty much useless. Presumably, > one of the main purposes of realm-based redirection is to allow SPs to avoid > keeping track of Diameter nodes in other realms, but if one node needs to be > tracked, why not all? Therefore, I think that this draft needs to be > changed to either a) define a new application (so that realm-based > redirection support can be advertised) or b) changed to Standards-Track & > stated to update RFC 3588. > > > > > ~gwz > > Play assigns meaning to human activity--work erases it. > -- P.L. Wilson > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From hannes.tschofenig@nsn.com Sun Jun 14 23:52:06 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545163A6BEC for ; Sun, 14 Jun 2009 23:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-1.917, BAYES_00=-2.599, FRT_SOMA2=2.199] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBBhehm+9ufZ for ; Sun, 14 Jun 2009 23:52:05 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1A78A3A69DF for ; Sun, 14 Jun 2009 23:52:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n5F6q8PM017286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Jun 2009 08:52:08 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n5F6q8Zp003660; Mon, 15 Jun 2009 08:52:08 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 08:52:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 09:54:08 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> In-Reply-To: <4A35BC11.2060005@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6Q References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sebastien Decugis" , "Tina TSOU" X-OriginalArrivalTime: 15 Jun 2009 06:52:07.0976 (UTC) FILETIME=[CCD5B280:01C9ED85] Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 06:52:06 -0000 The first thing to decide about the document is whether there is a real = problem we want to solve.=20 Then, we jump into how to solve it.=20 Still, thanks a lot for the review.=20 Ciao Hannes =20 >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >Behalf Of ext Sebastien Decugis >Sent: 15 June, 2009 06:12 >To: 'Tina TSOU' >Cc: dime@ietf.org >Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 > >Hi, > >I have a naive question. Is it not possible to define a new=20 >error code (distinct from DIAMETER_REDIRECT_INDICATION) for=20 >this purpose, to get rid of managing a single host in the=20 >redirect agent? I guess this would also imply update of RFC=20 >3588, but at least backward compatibility issues can be=20 >removed from the draft. > >Best regards, >Sebastien. > > >Glen Zorn a =E9crit : >> Section 2 says: >> >> Note that regardless of which approach is used, the=20 >original operator >> cannot escape the necessity to specify at least one individual >> Redirect-Host in indications to upstream Diameter nodes=20 >that cannot >> handle realm-based redirection. >> >> That being the case, this capability seems pretty much useless. =20 >> Presumably, one of the main purposes of realm-based=20 >redirection is to=20 >> allow SPs to avoid keeping track of Diameter nodes in other realms,=20 >> but if one node needs to be tracked, why not all? =20 >Therefore, I think=20 >> that this draft needs to be changed to either a) define a new=20 >> application (so that realm-based redirection support can be=20 >> advertised) or b) changed to Standards-Track & stated to=20 >update RFC 3588. >> >> >> >> >> ~gwz >> >> Play assigns meaning to human activity--work erases it. >> -- P.L. Wilson >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> =20 > >-- >Sebastien Decugis >Research fellow >Network Architecture Group >NICT (nict.go.jp) > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From dromasca@avaya.com Mon Jun 15 00:00:50 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9547028C0ED for ; Mon, 15 Jun 2009 00:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, FRT_SOMA2=2.199] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMbNjQojcMoU for ; Mon, 15 Jun 2009 00:00:49 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3817E3A6BEC for ; Mon, 15 Jun 2009 00:00:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,220,1243828800"; d="scan'208";a="148532533" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2009 03:00:57 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jun 2009 03:00:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 09:00:44 +0200 Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAAz5jA= References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Sebastien Decugis" , "Tina TSOU" Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 07:00:50 -0000 Do we have indications from operators of users that this is a problem = and that standard DIAMETER extensions would be an appropriate way to = solve this problem?=20 Dan =20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Monday, June 15, 2009 9:54 AM > To: ext Sebastien Decugis; Tina TSOU > Cc: dime@ietf.org > Subject: Re: [Dime] comments on=20 > draft-tsou-dime-realm-based-redirect-00 >=20 > The first thing to decide about the document is whether there=20 > is a real problem we want to solve.=20 >=20 > Then, we jump into how to solve it.=20 > Still, thanks a lot for the review.=20 >=20 > Ciao > Hannes > =20 >=20 > >-----Original Message----- > >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20 > On Behalf Of=20 > >ext Sebastien Decugis > >Sent: 15 June, 2009 06:12 > >To: 'Tina TSOU' > >Cc: dime@ietf.org > >Subject: Re: [Dime] comments on=20 > draft-tsou-dime-realm-based-redirect-00 > > > >Hi, > > > >I have a naive question. Is it not possible to define a new=20 > error code=20 > >(distinct from DIAMETER_REDIRECT_INDICATION) for this=20 > purpose, to get=20 > >rid of managing a single host in the redirect agent? I guess=20 > this would=20 > >also imply update of RFC 3588, but at least backward compatibility=20 > >issues can be removed from the draft. > > > >Best regards, > >Sebastien. > > > > > >Glen Zorn a =E9crit : > >> Section 2 says: > >> > >> Note that regardless of which approach is used, the > >original operator > >> cannot escape the necessity to specify at least one individual > >> Redirect-Host in indications to upstream Diameter nodes > >that cannot > >> handle realm-based redirection. > >> > >> That being the case, this capability seems pretty much useless. =20 > >> Presumably, one of the main purposes of realm-based > >redirection is to > >> allow SPs to avoid keeping track of Diameter nodes in=20 > other realms,=20 > >> but if one node needs to be tracked, why not all? > >Therefore, I think > >> that this draft needs to be changed to either a) define a new=20 > >> application (so that realm-based redirection support can be > >> advertised) or b) changed to Standards-Track & stated to > >update RFC 3588. > >> > >> > >> > >> > >> ~gwz > >> > >> Play assigns meaning to human activity--work erases it. > >> -- P.L. Wilson > >> > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >> > >> =20 > > > >-- > >Sebastien Decugis > >Research fellow > >Network Architecture Group > >NICT (nict.go.jp) > > > >_______________________________________________ > >DiME mailing list > >DiME@ietf.org > >https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From gwz@net-zen.net Mon Jun 15 01:27:40 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90AB3A6C92 for ; Mon, 15 Jun 2009 01:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXbGqrxXedBa for ; Mon, 15 Jun 2009 01:27:38 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 9F1713A6C95 for ; Mon, 15 Jun 2009 01:27:38 -0700 (PDT) Received: (qmail 26608 invoked from network); 15 Jun 2009 08:27:48 -0000 Received: from unknown (124.122.164.31) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 15 Jun 2009 08:27:47 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> Date: Mon, 15 Jun 2009 15:24:16 +0700 Organization: Network Zen Message-ID: <001a01c9ed92$af1c10b0$0d543210$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAJ//QA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 08:27:40 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] writes: > The first thing to decide about the document is whether there is a real > problem we want to solve. I thought that one of the useful outputs of the routing design team was that this (along with NAI-based routing) were useful things that should be pursued. Am I mistaken? > > Then, we jump into how to solve it. > Still, thanks a lot for the review. This is what you said in your "Hum" message: "Please let us know whether you would want draft-tsou-dime-realm-based-redirect-00.txt to become a working group item in DIME or whether you have objections." I don't see anything in there about "whether there is a real problem to be solved"; you ask about whether the document should become a WG item. It it's possible to offer a real opinion on that question _without_ reviewing the document, perhaps you can tell me how? Prophecy, perhaps? Furthermore, discussion of solutions would seem to imply that the problem is considered to be one that would be useful to solve, at least to those doing the discussing. ... From hannes.tschofenig@nsn.com Mon Jun 15 01:37:26 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CC828C111 for ; Mon, 15 Jun 2009 01:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6GXpU0VGM4J for ; Mon, 15 Jun 2009 01:37:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D898728C0CE for ; Mon, 15 Jun 2009 01:37:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n5F8bLsR030178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Jun 2009 10:37:21 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n5F8bKr2010523; Mon, 15 Jun 2009 10:37:21 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 10:37:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 11:39:21 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45017125B8@FIESEXC015.nsn-intra.net> In-Reply-To: <001a01c9ed92$af1c10b0$0d543210$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAJ//QAAAPJvMA== References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> <001a01c9ed92$af1c10b0$0d543210$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" X-OriginalArrivalTime: 15 Jun 2009 08:37:21.0245 (UTC) FILETIME=[7FD618D0:01C9ED94] Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 08:37:27 -0000 Hi Glen, >Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] >writes: > >> The first thing to decide about the document is whether there is a=20 >> real problem we want to solve. > >I thought that one of the useful outputs of the routing design=20 >team was that this (along with NAI-based routing) were useful=20 >things that should be pursued. Am I mistaken? You need to make your own assessment how successful the design team work was.=20 Picking up work that folks believe is important is appreciated.=20 > >>=20 >> Then, we jump into how to solve it. >> Still, thanks a lot for the review. > >This is what you said in your "Hum" message: "Please let us=20 >know whether you would want=20 >draft-tsou-dime-realm-based-redirect-00.txt to become a=20 >working group item in DIME or whether you have objections." I=20 >don't see anything in there about "whether there is a real=20 >problem to be solved"; you ask about whether the document=20 >should become a WG item. It it's possible to offer a real=20 >opinion on that question _without_ reviewing the document,=20 >perhaps you can tell me how? Prophecy, perhaps? Furthermore,=20 >discussion of solutions would seem to imply that the problem=20 >is considered to be one that would be useful to solve, at=20 >least to those doing the discussing. My mail was sent in light with the alternative proposals on how to solve the problem.=20 As you know, draft-tsou-dime-realm-based-redirect-00.txt is only the starting point and everything can change (from a content point of view) but hopefully the problem to be solved remains roughly the same :-) Ciao Hannes > >... > > > From dromasca@avaya.com Mon Jun 15 02:03:48 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DBE3A69ED for ; Mon, 15 Jun 2009 02:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu4OkNu9UI-G for ; Mon, 15 Jun 2009 02:03:47 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 49E7E3A6A8F for ; Mon, 15 Jun 2009 02:03:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,221,1243828800"; d="scan'208";a="164280510" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 15 Jun 2009 05:03:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jun 2009 05:03:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 11:03:19 +0200 Message-ID: In-Reply-To: <001b01c9ed95$fddd5260$f997f720$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAAz5jAAA7BmcAAAhgAA References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> <001b01c9ed95$fddd5260$f997f720$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Sebastien Decugis" , "Tina TSOU" Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 09:03:48 -0000 =20 > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net]=20 > Sent: Monday, June 15, 2009 11:48 AM > To: Romascanu, Dan (Dan); 'Tschofenig, Hannes (NSN -=20 > FI/Espoo)'; 'ext Sebastien Decugis'; 'Tina TSOU' > Cc: dime@ietf.org > Subject: RE: [Dime] comments on=20 > draft-tsou-dime-realm-based-redirect-00 >=20 > Romascanu, Dan (Dan) [mailto://Dan Romascanu=20 > (dromasca@avaya.com)] writes: >=20 > > Do we have indications from operators of users that this is=20 > a problem=20 > > and that standard DIAMETER extensions would be an=20 > appropriate way to=20 > > solve this problem? >=20 > You're kidding, right? If we waited for operators to notice=20 > a problem before tackling it IPv6 development would have=20 > started last week ;-). >=20 Maybe, but we are in OPS and we do protocols and data models for operators here. So even if we do not enjoy the participation of many operators in this WG nowadays asking whether at least the vendors who are proposing a piece of work are basing their proposal on requirements they hear from operators and end-users seems to me a reasonable sanity checking method for dealing with such 'hums'. Dan From gwz@net-zen.net Mon Jun 15 02:51:22 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3D23A6C9C for ; Mon, 15 Jun 2009 02:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdRyxEX+oTRh for ; Mon, 15 Jun 2009 02:51:21 -0700 (PDT) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by core3.amsl.com (Postfix) with SMTP id 6839C3A6C95 for ; Mon, 15 Jun 2009 02:51:21 -0700 (PDT) Received: (qmail 24665 invoked from network); 15 Jun 2009 08:51:28 -0000 Received: from unknown (124.122.164.31) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 15 Jun 2009 08:51:28 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Sebastien Decugis'" , "'Tina TSOU'" References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> In-Reply-To: Date: Mon, 15 Jun 2009 15:47:56 +0700 Organization: Network Zen Message-ID: <001b01c9ed95$fddd5260$f997f720$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAAz5jAAA7BmcA== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 09:51:22 -0000 Romascanu, Dan (Dan) [mailto://Dan Romascanu (dromasca@avaya.com)] writes: > Do we have indications from operators of users that this is a problem > and that standard DIAMETER extensions would be an appropriate way to > solve this problem? You're kidding, right? If we waited for operators to notice a problem before tackling it IPv6 development would have started last week ;-). ... From Hannes.Tschofenig@gmx.net Mon Jun 15 02:59:19 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87F43A6A67 for ; Mon, 15 Jun 2009 02:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rbNo9EzXzVe for ; Mon, 15 Jun 2009 02:59:18 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 79DEE3A6834 for ; Mon, 15 Jun 2009 02:59:18 -0700 (PDT) Received: (qmail invoked by alias); 15 Jun 2009 09:59:26 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp049) with SMTP; 15 Jun 2009 11:59:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8T+lt9R/8R6F35kF8G8ixS9fmFAINKFtKnVLf+f SGK1lmEP+LBcnW From: "Hannes Tschofenig" To: "'Glen Zorn'" , "'Romascanu, Dan \(Dan\)'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "'ext Sebastien Decugis'" , "'Tina TSOU'" References: <001101c9ebf2$d0af4450$720dccf0$@net><4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> <001b01c9ed95$fddd5260$f997f720$@net> Date: Mon, 15 Jun 2009 13:01:25 +0300 Message-ID: <01ae01c9eda0$4053e500$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <001b01c9ed95$fddd5260$f997f720$@net> Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAAz5jAAA7BmcAACcW+A X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 09:59:19 -0000 Glen, >Romascanu, Dan (Dan) [mailto://Dan Romascanu >(dromasca@avaya.com)] writes: > >> Do we have indications from operators of users that this is >a problem >> and that standard DIAMETER extensions would be an appropriate way to >> solve this problem? > >You're kidding, right? If we waited for operators to notice a >problem before tackling it IPv6 development would have started >last week ;-). Checking with those folks who deploy some of the extensions we are working on isn't a bad idea (tm). This is useful input for our work. I also encourage folks to implement extensions, which is another source of input. All these things are important. When time in the group is limited and the group itself has a limited capacity for processing stuff it is important to select items that are more likely to ever see the light at the end of the tunnel. Maybe draft-tsou-dime-realm-based-redirect is such an item that will be demanded a lot. Everyone needs to make their own judgement. Ideally, folks might also like to indicate why they like a certain thing. In the previous IETF meeting Avi stood up when you presented your MIB things and said that they would implement them once they become RFC. That's useful information (if correct). Ciao Hannes From gwz@net-zen.net Mon Jun 15 03:07:24 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BEE28C115 for ; Mon, 15 Jun 2009 03:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+TVzF6Zp0fe for ; Mon, 15 Jun 2009 03:07:23 -0700 (PDT) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id F3B3428C0D7 for ; Mon, 15 Jun 2009 03:07:22 -0700 (PDT) Received: (qmail 17241 invoked from network); 15 Jun 2009 10:07:32 -0000 Received: from unknown (124.122.164.31) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 15 Jun 2009 10:07:31 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> <001a01c9ed92$af1c10b0$0d543210$@net> <3D3C75174CB95F42AD6BCC56E5555B45017125B8@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45017125B8@FIESEXC015.nsn-intra.net> Date: Mon, 15 Jun 2009 17:03:59 +0700 Organization: Network Zen Message-ID: <002201c9eda0$9d7a7b90$d86f72b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAJ//QAAAPJvMAAC5qfw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 10:07:24 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] writes: ... > Picking up work that folks believe is important is appreciated. I think that the idea may be useful; the draft needs a lot of work, though. For example, what should the client do if it has no peer in the specified realm? ... > >This is what you said in your "Hum" message: "Please let us > >know whether you would want > >draft-tsou-dime-realm-based-redirect-00.txt to become a > >working group item in DIME or whether you have objections." I > >don't see anything in there about "whether there is a real > >problem to be solved"; you ask about whether the document > >should become a WG item. It it's possible to offer a real > >opinion on that question _without_ reviewing the document, > >perhaps you can tell me how? Prophecy, perhaps? Furthermore, > >discussion of solutions would seem to imply that the problem > >is considered to be one that would be useful to solve, at > >least to those doing the discussing. > > My mail was sent in light with the alternative proposals on how to > solve > the problem. I see. I just wasn't aware of any alternative proposals... > As you know, draft-tsou-dime-realm-based-redirect-00.txt is only the > starting point Of course! > and everything can change (from a content point of view) > but hopefully the problem to be solved remains roughly the same :-) Ah, but ensuring that's your job (with Victor :-). ... From gwz@net-zen.net Mon Jun 15 03:17:18 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61B23A6C08 for ; Mon, 15 Jun 2009 03:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNZrFxHOAO0Q for ; Mon, 15 Jun 2009 03:17:18 -0700 (PDT) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id EA2913A6AAA for ; Mon, 15 Jun 2009 03:17:17 -0700 (PDT) Received: (qmail 23841 invoked from network); 15 Jun 2009 10:17:28 -0000 Received: from unknown (124.122.164.31) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 15 Jun 2009 10:17:27 -0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" , "'Romascanu, Dan \(Dan\)'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Sebastien Decugis'" , "'Tina TSOU'" References: <001101c9ebf2$d0af4450$720dccf0$@net><4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> <001b01c9ed95$fddd5260$f997f720$@net> <01ae01c9eda0$4053e500$0301a8c0@nsnintra.net> In-Reply-To: <01ae01c9eda0$4053e500$0301a8c0@nsnintra.net> Date: Mon, 15 Jun 2009 17:13:54 +0700 Organization: Network Zen Message-ID: <002801c9eda2$00db59b0$02920d10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAAz5jAAA7BmcAACcW+AAACC4iA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 10:17:18 -0000 Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] writes: > Checking with those folks who deploy some of the extensions we are > working > on isn't a bad idea (tm). This is useful input for our work. My point was that this kind of thing should not be a limiting factor. People often have no idea how much they needed something until they get it... ... > When time in the group is limited and the group itself has a limited > capacity for processing stuff it is important to select items that are > more > likely to ever see the light at the end of the tunnel. Maybe > draft-tsou-dime-realm-based-redirect is such an item that will be > demanded a > lot. In my (admittedly limited) experience, if something is useful, it will be used. > Everyone needs to make their own judgement. Ideally, folks might > also > like to indicate why they like a certain thing. In the previous IETF > meeting > Avi stood up when you presented your MIB things and said that they > would > implement them once they become RFC. That's useful information (if > correct). > > Ciao > Hannes > From gwz@net-zen.net Mon Jun 15 03:40:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC233A6BBB for ; Mon, 15 Jun 2009 03:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnmdQ-VkPmFz for ; Mon, 15 Jun 2009 03:40:41 -0700 (PDT) Received: from smtpout04.prod.mesa1.secureserver.net (smtpout04-01.prod.mesa1.secureserver.net [64.202.165.196]) by core3.amsl.com (Postfix) with SMTP id 4D61C3A6A86 for ; Mon, 15 Jun 2009 03:40:41 -0700 (PDT) Received: (qmail 21120 invoked from network); 15 Jun 2009 10:40:51 -0000 Received: from unknown (124.122.164.31) by smtpout04.prod.mesa1.secureserver.net (64.202.165.196) with ESMTP; 15 Jun 2009 10:40:50 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Sebastien Decugis'" , "'Tina TSOU'" References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> <001b01c9ed95$fddd5260$f997f720$@net> In-Reply-To: Date: Mon, 15 Jun 2009 17:37:18 +0700 Organization: Network Zen Message-ID: <002f01c9eda5$44eeb090$cecc11b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAAz5jAAA7BmcAAAhgAAAAKi/LA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 10:40:42 -0000 Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: ... > > You're kidding, right? If we waited for operators to notice > > a problem before tackling it IPv6 development would have > > started last week ;-). > > > > Maybe, but we are in OPS and we do protocols and data models for > operators here. So even if we do not enjoy the participation of many > operators in this WG nowadays asking whether at least the vendors who > are proposing a piece of work are basing their proposal on requirements > they hear from operators and end-users seems to me a reasonable sanity > checking method for dealing with such 'hums'. Possibly so, but here's a question that may cast some light upon the validity of this approach: How many years elapsed between the publication of RFC 3588 & (some) operators' discovery that they needed the protocol we're busily extending? > > Dan From gwz@net-zen.net Mon Jun 15 04:52:29 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046D628C13C for ; Mon, 15 Jun 2009 04:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgEiKbO6GCtS for ; Mon, 15 Jun 2009 04:52:28 -0700 (PDT) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id EDB8928C132 for ; Mon, 15 Jun 2009 04:52:27 -0700 (PDT) Received: (qmail 677 invoked from network); 15 Jun 2009 11:51:46 -0000 Received: from unknown (124.122.164.31) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 15 Jun 2009 11:51:45 -0000 From: "Glen Zorn" To: "'Victor Fajardo'" References: <005901c9e81f$e49b8f40$add2adc0$@net> In-Reply-To: <005901c9e81f$e49b8f40$add2adc0$@net> Date: Mon, 15 Jun 2009 18:48:13 +0700 Organization: Network Zen Message-ID: <004801c9edaf$2d2551d0$876ff570$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnoH+GzXIZ4BVZgQLe/7l0VfwvDAwCWL9EQ Content-Language: en-us Cc: dime@ietf.org Subject: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 21-30 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 11:52:29 -0000 EDITORIAL Section 1.3.4 ------------- Under "M-bit Setting", paragraph 1, CHANGE "Adding an AVP with the M-bit in the MUST column of the AVP flag table to an existing Command/Application" TO "An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application" Under "M-bit Setting", paragraph 2, CHANGE "Adding an AVP with the M-bit in the MAY column of the AVP flag table to an existing Command/Application" TO "An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application" Clarification: Suggest changing An implementation MAY add arbitrary optional AVPs with the M-bit cleared to a command defined in an application, including vendor- specific AVPs without needing to define a new application. This can be done if the commands ABNF allows for it. Please refer to Section 11.1.1 for details. to If the ABNF definition of a command allows it, an implementation may add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to that command without needing to define a new application. Please refer to Section 11.1.1 for details. Section 2.1 ----------- Paragraph 3, s/backwards compatibility purpose/for purposes of backward compatibility/ Paragraph 5, it would be really nice to have a reference to section 12 after "the Tc timer"; in fact, to make such reference easier it might be a good idea to add subsections of section 12 for each of the configurable parameters discussed there In the last paragraph, it took a couple of readings to make sense of the last 3 sentence; for clarification, suggest changing "If Diameter receives data up from TCP that cannot be parsed or identified as a Diameter error made by the peer, the stream is compromised and cannot be recovered." to "If Diameter receives data from the lower layer that cannot be parsed or identified as a Diameter error made by the peer, the stream is compromised and cannot be recovered." Section 2.3 ----------- The second sentence of paragraph one seems rather poorly written to me: suggest changing "For a given application, advertising support of" to "Advertising support of" Same comment on paragraph 2; suggest changing An implementation MAY add arbitrary optional AVPs with the M-bit cleared to a command defined in an application, including vendor- specific AVPs only if the commands ABNF allows for it. Please refer to Section 11.1.1 for details. to Implementations MAY add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to a command defined in an application, but only if the command's ABNF syntax specification allows for it. Please refer to Section 11.1.1 for details. Section 2.5 ----------- I had no idea that a session would (or even could) spawn! Suggest changing A session is a logical concept at the application layer, it spawns from the Diameter client to the Diameter server and is identified via the Session-Id AVP. to A session is a logical concept at the application layer existing between the Diameter client and the Diameter server; it is identified via the Session-Id AVP. in paragraph 2. In paragraph 4, s/application specific/application-specific/ Section 2.6 ----------- Under "Static or Dynamic", s/configured, or/configured or/ Section 2.7 ----------- Under "Local Action", bullet 4 s/Section 6.1.9 for redirect guidelines./Section 6.1.8 for redirect guidelines. Under "Server Identifier", s/One or more servers the message is to be routed to./One or more servers to which the message is to be routed./ Under "Static or Dynamic", s/configured, or/configured or/ Under "Expiration Time", s/Specifies the time which/Specifies the time at which/ Section 2.8 ----------- In paragraph 1, s/In addition to client and servers/In addition to clients and servers/ In paragraph 4, s/information; by/information by/ Same paragraph, s/considered active either until it is notified otherwise, or by expiration. Each authorized session has an expiration/considered active either until the agent is notified otherwise, or the session expires. Each authorized session has an expiration time/ TECHNICAL Section 2 --------- I don't really understand this section, nor even why it is included For example: Diameter Clients MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the client's service, e.g., NASREQ and/or Mobile IPv4. A Diameter Client that does not support both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Client" where X is the application which it supports, and not a "Diameter Client". There are a ton of Diameter applications; what's so special about NASREQ & MIPv4? Even if there is a rationale for keeping this part of the original text, section 2 in bis doesn't seem like any improvement of section 2 of RFC 3588. From KENNETH.G.CARLBERG@saic.com Mon Jun 15 04:59:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804FE3A6CC3 for ; Mon, 15 Jun 2009 04:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHoEzETducPW for ; Mon, 15 Jun 2009 04:59:04 -0700 (PDT) Received: from mclmx.mail.saic.com (mclmx.mail.saic.com [149.8.64.10]) by core3.amsl.com (Postfix) with ESMTP id B00403A6CD1 for ; Mon, 15 Jun 2009 04:59:04 -0700 (PDT) Received: from 0015-its-sbg01.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com with ESMTP id BT-MMP-7541250; Mon, 15 Jun 2009 07:58:11 -0400 X-AuditID: 9508401a-b7bd9ae000000b98-00-4a363753ca97 Received: from 0015-its-exbh03.us.saic.com (mcl-sixl-nat.saic.com [149.8.64.21]) by 0015-its-sbg01.saic.com (Symantec Brightmail Gateway) with SMTP id C4.1C.02968.357363A4; Mon, 15 Jun 2009 07:58:11 -0400 (EDT) Received: from 0015-its-exmb11.us.saic.com ([10.43.229.22]) by 0015-its-exbh03.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 07:58:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 07:58:10 -0400 Message-Id: In-Reply-To: <002801c9eda2$00db59b0$02920d10$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAAz5jAAA7BmcAACcW+AAACC4iAAA3+lAA== References: <001101c9ebf2$d0af4450$720dccf0$@net><4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net><001b01c9ed95$fddd5260$f997f720$@net><01ae01c9eda0$4053e500$0301a8c0@nsnintra.net> <002801c9eda2$00db59b0$02920d10$@net> From: "Carlberg, Kenneth G." To: "Glen Zorn" , "Hannes Tschofenig" , "Romascanu, Dan (Dan)" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Sebastien Decugis" , "Tina TSOU" X-OriginalArrivalTime: 15 Jun 2009 11:58:11.0523 (UTC) FILETIME=[8E5C9930:01C9EDB0] X-Brightmail-Tracker: AAAAAA== Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 11:59:05 -0000 > Glen Zorn writes: > > > Checking with those folks who deploy some of the extensions we are=20 > > working on isn't a bad idea (tm). This is useful input for=20 > our work. > =20 > My point was that this kind of thing should not be a limiting factor. > People often have no idea how much they needed something=20 > until they get it... I'm inclined to agree with elements of both sides of the argument. Sanity checks in terms of what is distinctly broken are appreciated (even desired) by the operator community. But, I much rather prefer to lean towards the presence of additional tools (particularly those favored by vendors) and rely on the old adage of "letting the market decide". (speaking as one who doesn't have a horse in this particular race :-) -ken From dromasca@avaya.com Mon Jun 15 05:13:38 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C4C3A6CCB for ; Mon, 15 Jun 2009 05:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE0itTSOJoec for ; Mon, 15 Jun 2009 05:13:37 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 7EF063A6C0A for ; Mon, 15 Jun 2009 05:13:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,222,1243828800"; d="scan'208";a="164294917" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 15 Jun 2009 08:13:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Jun 2009 08:13:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 14:12:50 +0200 Message-ID: In-Reply-To: <002f01c9eda5$44eeb090$cecc11b0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 Thread-Index: AcntZz7HFZpRGsWkSsWlcCUGSDkCGQAHsB6QAAAz5jAAA7BmcAAAhgAAAAKi/LAAA7iksA== References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> <001b01c9ed95$fddd5260$f997f720$@net> <002f01c9eda5$44eeb090$cecc11b0$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Sebastien Decugis" , "Tina TSOU" Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 12:13:38 -0000 =20 > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net]=20 > Sent: Monday, June 15, 2009 1:37 PM > To: Romascanu, Dan (Dan); 'Tschofenig, Hannes (NSN -=20 > FI/Espoo)'; 'ext Sebastien Decugis'; 'Tina TSOU' > Cc: dime@ietf.org > Subject: RE: [Dime] comments on=20 > draft-tsou-dime-realm-based-redirect-00 >=20 > Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: >=20 > ... >=20 > > > You're kidding, right? If we waited for operators to notice a=20 > > > problem before tackling it IPv6 development would have=20 > started last=20 > > > week ;-). > > > > >=20 > > Maybe, but we are in OPS and we do protocols and data models for=20 > > operators here. So even if we do not enjoy the=20 > participation of many=20 > > operators in this WG nowadays asking whether at least the=20 > vendors who=20 > > are proposing a piece of work are basing their proposal on=20 > > requirements they hear from operators and end-users seems to me a=20 > > reasonable sanity checking method for dealing with such 'hums'. >=20 > Possibly so, but here's a question that may cast some light=20 > upon the validity of this approach: How many years elapsed=20 > between the publication of RFC 3588 & (some) operators'=20 > discovery that they needed the protocol we're busily extending? >=20 > >=20 > > Dan >=20 >=20 I am not making the argument that popular demand should be the only way we decide what to do. What I am saying is that there are cases when a WG can use operators and users input as a way to filter and prioritize - especially when the WG has more new things to do proposed than it is capable to execute.=20 Dan >=20 From jouni.nospam@gmail.com Mon Jun 15 11:24:27 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094623A68DD for ; Mon, 15 Jun 2009 11:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FRT_SOMA2=2.199] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB+WGcQfFarY for ; Mon, 15 Jun 2009 11:24:26 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id A8E6A3A67F9 for ; Mon, 15 Jun 2009 11:24:25 -0700 (PDT) Received: by bwz9 with SMTP id 9so3534556bwz.37 for ; Mon, 15 Jun 2009 11:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=0bRUsHfDIXByOjB6lFnK/VmladfbRyviCE6WTSHXGqQ=; b=WIUTXMzW4uAdVqhWlFA4+8EWC+e+0cqEDr1TBL3dIKoCLgsLwZYC/d5odBBTfdktg8 qplBGzbx4s+/X74SHOBnn75xdccwiy9MhBxin6QtVJYGZwlgEuZLhzbsQP85Ypv4rhpF nQid5gXde5VI/1e0rk0jBZ7y+Ph92mb1M6EiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=p89DOJrCUso1lq5dA+VR0F2nlvoACqHOdNuUL7iLOmqf0bwckY85GTOnwEy+/xtRfT aRLT8ZDSQ/WlDVlLKgljbz8DmxrAdLOtMfxtM9K4ZDkpRZxld3XU8A2/0XlSWRqlD3g8 BNFpkFIaLFzy0TVnCMep+4Jt4vDJ71aHgIE3E= Received: by 10.204.123.83 with SMTP id o19mr7324059bkr.12.1245090272592; Mon, 15 Jun 2009 11:24:32 -0700 (PDT) Received: from a88-114-166-199.elisa-laajakaista.fi (a88-114-166-199.elisa-laajakaista.fi [88.114.166.199]) by mx.google.com with ESMTPS id e17sm8452710fke.18.2009.06.15.11.24.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 11:24:31 -0700 (PDT) Message-Id: <2BD72045-AD95-48A6-9DC3-B8454D2D26F5@gmail.com> From: jouni korhonen To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 21:24:30 +0300 References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:24:27 -0000 Well.. I don't personally know of any concrete requirements, yet. =20 However, a plethora of (mobile) operators have just started to work on =20= their Diameter based roaming recommendations (LTE roaming), so I would =20= say that not too many (mobile) operator has yet realized what they =20 will exactly need at Diameter level. Still, the concept proposed by this draft could be an useful tool. Not =20= necessarily in the "problem context" the draft presents and the =20 solution could be different. One thing I was thinking here is whether =20= the redirection could be achieved transparently. For example a back-to-=20= back type solution could probably work and would not require support =20 from originating hosts or agents beyond those doing the redirection.. Cheers, Jouni On Jun 15, 2009, at 10:00 AM, Romascanu, Dan (Dan) wrote: > Do we have indications from operators of users that this is a =20 > problem and that standard DIAMETER extensions would be an =20 > appropriate way to solve this problem? > > Dan > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Monday, June 15, 2009 9:54 AM >> To: ext Sebastien Decugis; Tina TSOU >> Cc: dime@ietf.org >> Subject: Re: [Dime] comments on >> draft-tsou-dime-realm-based-redirect-00 >> >> The first thing to decide about the document is whether there >> is a real problem we want to solve. >> >> Then, we jump into how to solve it. >> Still, thanks a lot for the review. >> >> Ciao >> Hannes >> >> >>> -----Original Message----- >>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >> On Behalf Of >>> ext Sebastien Decugis >>> Sent: 15 June, 2009 06:12 >>> To: 'Tina TSOU' >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] comments on >> draft-tsou-dime-realm-based-redirect-00 >>> >>> Hi, >>> >>> I have a naive question. Is it not possible to define a new >> error code >>> (distinct from DIAMETER_REDIRECT_INDICATION) for this >> purpose, to get >>> rid of managing a single host in the redirect agent? I guess >> this would >>> also imply update of RFC 3588, but at least backward compatibility >>> issues can be removed from the draft. >>> >>> Best regards, >>> Sebastien. >>> >>> >>> Glen Zorn a =E9crit : >>>> Section 2 says: >>>> >>>> Note that regardless of which approach is used, the >>> original operator >>>> cannot escape the necessity to specify at least one individual >>>> Redirect-Host in indications to upstream Diameter nodes >>> that cannot >>>> handle realm-based redirection. >>>> >>>> That being the case, this capability seems pretty much useless. >>>> Presumably, one of the main purposes of realm-based >>> redirection is to >>>> allow SPs to avoid keeping track of Diameter nodes in >> other realms, >>>> but if one node needs to be tracked, why not all? >>> Therefore, I think >>>> that this draft needs to be changed to either a) define a new >>>> application (so that realm-based redirection support can be >>>> advertised) or b) changed to Standards-Track & stated to >>> update RFC 3588. >>>> >>>> >>>> >>>> >>>> ~gwz >>>> >>>> Play assigns meaning to human activity--work erases it. >>>> -- P.L. Wilson >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> >>> >>> -- >>> Sebastien Decugis >>> Research fellow >>> Network Architecture Group >>> NICT (nict.go.jp) >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dvijay@gmail.com Mon Jun 15 17:32:33 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5193A6AC3 for ; Mon, 15 Jun 2009 17:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcjlyAxQxeDh for ; Mon, 15 Jun 2009 17:32:32 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id AFD233A69BC for ; Mon, 15 Jun 2009 17:32:32 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so1963596ywj.49 for ; Mon, 15 Jun 2009 17:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bDm+ryHZCorwa81xXAF/wAKMEsJV3mIXjWFWyc2lp3k=; b=evCMX/tkxWGNElaGe5K6pRbxx5h4y2In8rQXfYLt1JZdj/hP/G7lqBkZ5phJpJ20/r dc64bBn5bVlvlA0254cssv17n1P++t+gOwTomvMPZZSC+TG3BaNC5IxbFqJM91XnCNkK DnM+A+Ok+2fHW23YH6ZBNZW5hdWX/DAomdP4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xo2j5QFMDzakVqXUz0BSnYbave9+DqT449r0RqK2HqX/YxnVRX+9iS/ObKJJlobSsq QPHI29Ma6lCDLMqanC2WXnJL6qf7jTuQZzFEqIfRB3+S6TrIxby9OrVbgRqgEZ5Q7YMK 3mQJJlkeLtBRX+pyTlvXptj2+3KN5M2aH3TQ4= MIME-Version: 1.0 Received: by 10.151.129.2 with SMTP id g2mr14406270ybn.153.1245112360449; Mon, 15 Jun 2009 17:32:40 -0700 (PDT) In-Reply-To: <2FA145BF-2534-4A2A-A878-C50A6B3C0087@gmail.com> References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <2FA145BF-2534-4A2A-A878-C50A6B3C0087@gmail.com> Date: Mon, 15 Jun 2009 17:32:40 -0700 Message-ID: From: Vijay Devarapalli To: jouni korhonen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 00:32:34 -0000 Hi Jouni, On Wed, Jun 10, 2009 at 11:03 PM, jouni korhonen wr= ote: > Hi Vijay, > > > On Jun 11, 2009, at 12:49 AM, Vijay Devarapalli wrote: > >> Hi Jouni, >> >> I have a comment on the "VPN Gateway feature". There is no document >> that describes what it means for a Mobile IPv6 home agent to act as a >> VPN gateway. The IKEv2 exchange between the MN and the HA [RFC 4877 >> and 5026] already supports mutual authentication, address assignment >> and setting up of tunnel mode ESP SAs. Are you referring to this as >> VPN mode? But isn't this regular Home agent functionality? > > The "VPN mode" is when you use HA IKEv2/IPsec functionality purely for > conventional VPN remote access purposes without any mobility. Again, what does this mean? When you run IKEv2 as described in RFC 4877 and 5026, you are creating tunnel mode security associations for a *Mobile IPv6 tunnel*. In the "VPN" mode, does the mobile node switch of the Mobile IPv6 stack? Or does the Home Agent behave an IPsec VPN gateway for pure IPsec clients, i.e., there is no Mobile IPv6 stack on these clients. > That type of > deployment is shortly referenced in draft-ietf-dime-mip6-split Section 4.= 1. > I recall this functionality was originally requested by Gerardo. It doesn't make sense to me. :) This looks more like co-locating a Mbile IPv6 home agent and an IPsec VPN gateway and supporting both Mobile IPv6 mobile nodes and plain IPsec clients at the same time. There has to be more to this scenario than just the short paragraph in draft-ietf-dime-mip6-split. >> Or is there a separate IPsec VPN that is first setup and then Mobile >> IPv6 is run on top of the IPsec tunnels? > > As shortly described in split document: > > =C2=A0 In some deployment scenarios, the HA may also act as an IKEv2 > =C2=A0 Responder for a conventional IPsec VPN access. =C2=A0The challenge= in this > =C2=A0 case is that the IKEv2 responder may not know if IKEv2 is used for > =C2=A0 Mobile IPv6 service or for IPsec VPN access service. =C2=A0A netwo= rk > =C2=A0 operator needs to be aware of this limitation. =C2=A0One solution = already > =C2=A0 supported by IKEv2 is to use different responder identities when > =C2=A0 operating as a conventional IPsec VPN gateway or as a HA. =C2=A0Th= e MN can > =C2=A0 then indicate the preferred responder type using the appropriate I= Dr > =C2=A0 payload in the IKE_AUTH message. > > But yeah, now that feature bits are taken into a separate document, the > connection between the above and the new feature bit is rather weak. Eith= er > we need more text and/or reference in the draft-korhonen-dime-feature-bit= s > or just remove the bit all together. Since the difference between > conventional IKEv2 IPsec VPN gateway part and HA's IKEv2 IPsec functional= ity > is rather small, I would keep the feature bit and enhance the text instea= d. It is not "rather small" in my opinion. I don't understand how supporting plain IPsec clients can be a feature on a Mobile IPv6 home agent. :) Vijay > > Jouni > > >> >> >> Vijay >> >> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen >> wrote: >>> >>> Hi all, >>> >>> I have updated the additional feature bits draft. I did remove some stu= ff >>> so >>> that the draft now only reserves MIP6-Feature-Vector flag bits and >>> nothing >>> more. I'll forward the draft soon to RFC editor so if anyone has >>> comments, >>> please be quick :) >>> >>> Cheers, >>> =C2=A0 =C2=A0 =C2=A0 Jouni >>> >>> Begin forwarded message: >>> >>>> From: IETF I-D Submission Tool >>>> Date: June 10, 2009 12:26:53 PM GMT+03:00 >>>> To: jouni.nospam@gmail.com >>>> Subject: New Version Notification for >>>> =C2=A0draft-korhonen-dime-mip6-feature-bits-01 >>>> >>>> >>>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has >>>> been successfuly submitted by Jouni Korhonen and posted to the IETF >>>> repository. >>>> >>>> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-korhonen-dime-mip6-feature-= bits >>>> Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A001 >>>> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diameter MIP6 Feature Vector= Additional Bit Allocations >>>> Creation_date: =C2=A0 2009-06-10 >>>> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Submission >>>> Number_of_pages: 5 >>>> >>>> Abstract: >>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 >>>> Home Agent and the Authentication, Authorization, and Accounting >>>> server may exchange a set of authorized mobility capabilities. =C2=A0T= his >>>> document defines new mobility capability flags that are used to >>>> authorize per Mobile Node route optimization, Multiple Care-of >>>> Address and user plane traffic encryption support. =C2=A0Furthermore, = this >>>> document also defines a capability flag of indicating whether the >>>> Home Agent is authorized to act as a stand alone Virtual Private >>>> Network gateway. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > > From dvijay@gmail.com Mon Jun 15 17:39:50 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E301C3A67E6 for ; Mon, 15 Jun 2009 17:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po3QmaWS4e8m for ; Mon, 15 Jun 2009 17:39:50 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id D081E3A6781 for ; Mon, 15 Jun 2009 17:39:49 -0700 (PDT) Received: by gxk10 with SMTP id 10so7193576gxk.13 for ; Mon, 15 Jun 2009 17:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VhQA43QqK9I34Sxnd43ZoyttD997x8rB0spD21z9zQM=; b=XlLVtrOTtE2k+MnNvULr8ctBzVp7mvMwg58dvar57aDmFR8jkTDi5M9TgpnULBN0Ur 0s0lV2M3ia8ALUTkUNvOCTRY6CoivSw0W2K/kPOjWiseV5vS/+mkrFZfI14e5I2QFoQT wmFfDkKCh8ON57mE79zNQh9xEgvhOHi7nt92k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a3HwRSWRwlgVrX6ct1mOTAsEcVxArKtLl6ywFInp9uvCXTNCt0rmrm6KXIHlMRwqg5 6WZ7hLup4ZNUJTTdOGweLqTwV+7ToAFFWWVMSZZHSqyh+svUtK5UfMIT/aZshZPZXhE3 4BvAj6byqQOcVTXIDKl4x2SzOJpilQP7c2SUg= MIME-Version: 1.0 Received: by 10.151.72.9 with SMTP id z9mr14446710ybk.78.1245112796670; Mon, 15 Jun 2009 17:39:56 -0700 (PDT) In-Reply-To: References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> Date: Mon, 15 Jun 2009 17:39:56 -0700 Message-ID: From: Vijay Devarapalli To: jouni korhonen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 00:39:51 -0000 Hi Jouni, On Wed, Jun 10, 2009 at 11:28 PM, jouni korhonen wr= ote: > Hi Vijay, > > On Jun 11, 2009, at 12:51 AM, Vijay Devarapalli wrote: > >> I have another question. >> >> Why does encrypting the payload traffic between the MN and the HA need >> AAA authorization? > > IMHO payload traffic encryption is a potential place for a policy decisio= n. > An operator may want to control it depending on the deployment and the > subscription in situations where the the same HA could be used for variou= s > types of deployments. As you know e.g. certain SDOs purposely forbid the = use > of payload encryption in their environment where as that might not make > sense in other type of deployment. Let me see if I understand this. Lets say the home operator (MSP) that provides the home agent does not want the mobile node to use payload encryption. Isn't this better enforced on the home agent itself? The home agent can refuse create CHILD SAs for payload protection. In another case, lets say the client is roaming and is attached to some visited network and is accessing a home agent in the home network. I can understand the visited network wanting to prevent payload encryption. But how does this work if the home agent is talking to the AAA server in the home network? Does the AAA server, based on the fact that the client is coming from a specific visited network, the payload traffic should not be encrypted? Can you give me an example where this kind of control would help? Vijay > > Jouni > >> >> >> Vijay >> >> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen >> wrote: >>> >>> Hi all, >>> >>> I have updated the additional feature bits draft. I did remove some stu= ff >>> so >>> that the draft now only reserves MIP6-Feature-Vector flag bits and >>> nothing >>> more. I'll forward the draft soon to RFC editor so if anyone has >>> comments, >>> please be quick :) >>> >>> Cheers, >>> =C2=A0 =C2=A0 =C2=A0 Jouni >>> >>> Begin forwarded message: >>> >>>> From: IETF I-D Submission Tool >>>> Date: June 10, 2009 12:26:53 PM GMT+03:00 >>>> To: jouni.nospam@gmail.com >>>> Subject: New Version Notification for >>>> =C2=A0draft-korhonen-dime-mip6-feature-bits-01 >>>> >>>> >>>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has >>>> been successfuly submitted by Jouni Korhonen and posted to the IETF >>>> repository. >>>> >>>> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-korhonen-dime-mip6-feature-= bits >>>> Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A001 >>>> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diameter MIP6 Feature Vector= Additional Bit Allocations >>>> Creation_date: =C2=A0 2009-06-10 >>>> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent Submission >>>> Number_of_pages: 5 >>>> >>>> Abstract: >>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 >>>> Home Agent and the Authentication, Authorization, and Accounting >>>> server may exchange a set of authorized mobility capabilities. =C2=A0T= his >>>> document defines new mobility capability flags that are used to >>>> authorize per Mobile Node route optimization, Multiple Care-of >>>> Address and user plane traffic encryption support. =C2=A0Furthermore, = this >>>> document also defines a capability flag of indicating whether the >>>> Home Agent is authorized to act as a stand alone Virtual Private >>>> Network gateway. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > > From jouni.nospam@gmail.com Tue Jun 16 03:27:54 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08373A6AA7 for ; Tue, 16 Jun 2009 03:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28atz3kQjW4d for ; Tue, 16 Jun 2009 03:27:52 -0700 (PDT) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by core3.amsl.com (Postfix) with ESMTP id 61A943A692D for ; Tue, 16 Jun 2009 03:27:52 -0700 (PDT) Received: by fxm7 with SMTP id 7so519582fxm.37 for ; Tue, 16 Jun 2009 03:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=wgEjzl6nglJwCUBvqiGVyOrolF+LVmoJny80Xf8ezsA=; b=nzxZEVKbOUEAHgAemfJTQb14XXFk4NdhaO6xzOj6uNPR4Qt7gc/nrpm5VR+2v2eKG4 yZaeNCDr82L76DJVIjIz/Fsj23F8eOGMXXBfkq/keSlL1Bjiu5mV8pDIAnnnB52gaLSx 0IAiu9O1ZMwFPCZz2WL6yUsnnE6GAe63FvnBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=MNXFOSwHdctSAlBssxXiAUxQ5cb4SR68dc6EFz3RSqMCBsu66597y9+ihIb0gXRlLo 8jRdiKF4OfYKHdE0guaHY18OFFBdZMvsw449vtyg7v8VaABR+PmTSsQcmNPVRAK7Mstc gvabYKPOsRkD2RgPaunyKNVG04Kf7LuJYTexU= Received: by 10.103.8.3 with SMTP id l3mr4348186mui.116.1245148067754; Tue, 16 Jun 2009 03:27:47 -0700 (PDT) Received: from ?192.168.100.17? (MYDCCLI.gprs.sl-laajakaista.fi [85.77.238.152]) by mx.google.com with ESMTPS id 23sm568101mum.5.2009.06.16.03.27.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 03:27:47 -0700 (PDT) Message-Id: <5CC059D9-6113-49A3-9748-9F4562A248CC@gmail.com> From: jouni korhonen To: Vijay Devarapalli In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 13:27:44 +0300 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <2FA145BF-2534-4A2A-A878-C50A6B3C0087@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 10:27:54 -0000 Hi Vijay, On Jun 16, 2009, at 3:32 AM, Vijay Devarapalli wrote: > Hi Jouni, > > On Wed, Jun 10, 2009 at 11:03 PM, jouni korhonen > wrote: >> Hi Vijay, >> >> >> On Jun 11, 2009, at 12:49 AM, Vijay Devarapalli wrote: >> >>> Hi Jouni, >>> >>> I have a comment on the "VPN Gateway feature". There is no document >>> that describes what it means for a Mobile IPv6 home agent to act >>> as a >>> VPN gateway. The IKEv2 exchange between the MN and the HA [RFC 4877 >>> and 5026] already supports mutual authentication, address assignment >>> and setting up of tunnel mode ESP SAs. Are you referring to this as >>> VPN mode? But isn't this regular Home agent functionality? >> >> The "VPN mode" is when you use HA IKEv2/IPsec functionality purely >> for >> conventional VPN remote access purposes without any mobility. > > Again, what does this mean? When you run IKEv2 as described in RFC > 4877 and 5026, you are creating tunnel mode security associations for > a *Mobile IPv6 tunnel*. In the "VPN" mode, does the mobile node switch > of the Mobile IPv6 stack? VPN mode is plain RFC4306 + 4303 etc. You end up implementing that machinery there in any case, so why not allow using a HA as a VPN gateway as well. In this case, there is no mobility involved. > > Or does the Home Agent behave an IPsec VPN gateway for pure IPsec > clients, i.e., there is no Mobile IPv6 stack on these clients. Yes. > > >> That type of >> deployment is shortly referenced in draft-ietf-dime-mip6-split >> Section 4.1. >> I recall this functionality was originally requested by Gerardo. > > It doesn't make sense to me. :) This looks more like co-locating a > Mbile IPv6 home agent and an IPsec VPN gateway and supporting both > Mobile IPv6 mobile nodes and plain IPsec clients at the same time. Yes, it is about co-location. To me it makes sense as much as IKEv2+IPsec with MIP6 ;) > > > There has to be more to this scenario than just the short paragraph in > draft-ietf-dime-mip6-split. Yes, agree. > > >>> Or is there a separate IPsec VPN that is first setup and then Mobile >>> IPv6 is run on top of the IPsec tunnels? >> >> As shortly described in split document: >> >> In some deployment scenarios, the HA may also act as an IKEv2 >> Responder for a conventional IPsec VPN access. The challenge in >> this >> case is that the IKEv2 responder may not know if IKEv2 is used for >> Mobile IPv6 service or for IPsec VPN access service. A network >> operator needs to be aware of this limitation. One solution >> already >> supported by IKEv2 is to use different responder identities when >> operating as a conventional IPsec VPN gateway or as a HA. The MN >> can >> then indicate the preferred responder type using the appropriate >> IDr >> payload in the IKE_AUTH message. >> >> But yeah, now that feature bits are taken into a separate document, >> the >> connection between the above and the new feature bit is rather >> weak. Either >> we need more text and/or reference in the draft-korhonen-dime- >> feature-bits >> or just remove the bit all together. Since the difference between >> conventional IKEv2 IPsec VPN gateway part and HA's IKEv2 IPsec >> functionality >> is rather small, I would keep the feature bit and enhance the text >> instead. > > It is not "rather small" in my opinion. I don't understand how > supporting plain IPsec clients can be a feature on a Mobile IPv6 home > agent. :) Well.. feature in a sense that you have both functionalities in the same box anyway. Stretching my memory on the requirements, this came from the cases where an I-WLAN PDG and a HA were to be bundled together. Jouni > > > Vijay > >> >> Jouni >> >> >>> >>> >>> Vijay >>> >>> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen>> > >>> wrote: >>>> >>>> Hi all, >>>> >>>> I have updated the additional feature bits draft. I did remove >>>> some stuff >>>> so >>>> that the draft now only reserves MIP6-Feature-Vector flag bits and >>>> nothing >>>> more. I'll forward the draft soon to RFC editor so if anyone has >>>> comments, >>>> please be quick :) >>>> >>>> Cheers, >>>> Jouni >>>> >>>> Begin forwarded message: >>>> >>>>> From: IETF I-D Submission Tool >>>>> Date: June 10, 2009 12:26:53 PM GMT+03:00 >>>>> To: jouni.nospam@gmail.com >>>>> Subject: New Version Notification for >>>>> draft-korhonen-dime-mip6-feature-bits-01 >>>>> >>>>> >>>>> A new version of I-D, draft-korhonen-dime-mip6-feature- >>>>> bits-01.txt has >>>>> been successfuly submitted by Jouni Korhonen and posted to the >>>>> IETF >>>>> repository. >>>>> >>>>> Filename: draft-korhonen-dime-mip6-feature-bits >>>>> Revision: 01 >>>>> Title: Diameter MIP6 Feature Vector Additional Bit >>>>> Allocations >>>>> Creation_date: 2009-06-10 >>>>> WG ID: Independent Submission >>>>> Number_of_pages: 5 >>>>> >>>>> Abstract: >>>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile >>>>> IPv6 >>>>> Home Agent and the Authentication, Authorization, and Accounting >>>>> server may exchange a set of authorized mobility capabilities. >>>>> This >>>>> document defines new mobility capability flags that are used to >>>>> authorize per Mobile Node route optimization, Multiple Care-of >>>>> Address and user plane traffic encryption support. Furthermore, >>>>> this >>>>> document also defines a capability flag of indicating whether the >>>>> Home Agent is authorized to act as a stand alone Virtual Private >>>>> Network gateway. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >> >> From jouni.nospam@gmail.com Tue Jun 16 03:55:34 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A743A6ACB for ; Tue, 16 Jun 2009 03:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAO0MWHPl9Ho for ; Tue, 16 Jun 2009 03:55:33 -0700 (PDT) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by core3.amsl.com (Postfix) with ESMTP id DAE193A6862 for ; Tue, 16 Jun 2009 03:55:32 -0700 (PDT) Received: by fxm7 with SMTP id 7so534303fxm.37 for ; Tue, 16 Jun 2009 03:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=0HYSHkRJf9HoAgLMYtFBVVFfCN9SPB3Yij0Rj66Mdps=; b=DbTk3KG9FIRyV5qQTdl84y7QusYUDjQ1VxsRp0LR+XJppAQPRVIw8qgjgr1Jfqfyq9 o71d7uPUOi/DfH/6x7yUId6begX1V4S+Gehf2kt2RBVhm1uOF7Mapz3roLARa4dqgVVG A+arkbu9treb5Xafq8NF3RfWF4jrWGo+zN7uA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=w6ov9tmXvEPX9wFvpEzmVfJxHE0U6KdzbJLzPGnH1J+5j/58EHQIfceCQUi+Pt19xw Zqm+Rf/shyhsbo68jEoJAYEjEIY/LOJV7fAr33k+XX3Yrobwu+V4Wqcp1GflDY3ByaJb +EkdNWJQdNRqwY4TXmAIun+GSExQadWtHOYUE= Received: by 10.103.221.14 with SMTP id y14mr4367163muq.111.1245149629425; Tue, 16 Jun 2009 03:53:49 -0700 (PDT) Received: from ?192.168.100.17? (MYDCCLI.gprs.sl-laajakaista.fi [85.77.238.152]) by mx.google.com with ESMTPS id e10sm1702541muf.44.2009.06.16.03.53.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 03:53:49 -0700 (PDT) Message-Id: From: jouni korhonen To: Vijay Devarapalli In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 13:53:46 +0300 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 10:55:34 -0000 Hi Vijay ;) On Jun 16, 2009, at 3:39 AM, Vijay Devarapalli wrote: > Hi Jouni, > > On Wed, Jun 10, 2009 at 11:28 PM, jouni korhonen > wrote: >> Hi Vijay, >> >> On Jun 11, 2009, at 12:51 AM, Vijay Devarapalli wrote: >> >>> I have another question. >>> >>> Why does encrypting the payload traffic between the MN and the HA >>> need >>> AAA authorization? >> >> IMHO payload traffic encryption is a potential place for a policy >> decision. >> An operator may want to control it depending on the deployment and >> the >> subscription in situations where the the same HA could be used for >> various >> types of deployments. As you know e.g. certain SDOs purposely >> forbid the use >> of payload encryption in their environment where as that might not >> make >> sense in other type of deployment. > > Let me see if I understand this. Lets say the home operator (MSP) that > provides the home agent does not want the mobile node to use payload > encryption. Isn't this better enforced on the home agent itself? The > home agent can refuse create CHILD SAs for payload protection. The same HA may serve multiple providers and within a provider multiple services. Provisioning this information dynamically into a HA is not how I would like to see this managed. As a result of this policy decision the HA would refuse to CHILD SA creation for payload protection. There could also be a notification of this to the MN in a BA, but it is left out of this draft. > > > In another case, lets say the client is roaming and is attached to > some visited network and is accessing a home agent in the home > network. I can understand the visited network wanting to prevent > payload encryption. But how does this work if the home agent is > talking to the AAA server in the home network? Does the AAA server, > based on the fact that the client is coming from a specific visited > network, the payload traffic should not be encrypted? The challenge in the visited network case here is how the HA/AAA would even know that the MN is "roaming". There are ways of doing that though like analyzing CoAs (done today rather widely) or based on network access authentication (if available). In managed networks where "roaming" as a concept fits better, the policy decision would be based on roaming contracts and the subscription profile. > > > Can you give me an example where this kind of control would help? You roam into area where encryption is not seen as a good thing.. The AAA could turn this off for you if you forget or cannot change the setting yourself. Jouni > > > Vijay > > >> >> Jouni >> >>> >>> >>> Vijay >>> >>> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen>> > >>> wrote: >>>> >>>> Hi all, >>>> >>>> I have updated the additional feature bits draft. I did remove >>>> some stuff >>>> so >>>> that the draft now only reserves MIP6-Feature-Vector flag bits and >>>> nothing >>>> more. I'll forward the draft soon to RFC editor so if anyone has >>>> comments, >>>> please be quick :) >>>> >>>> Cheers, >>>> Jouni >>>> >>>> Begin forwarded message: >>>> >>>>> From: IETF I-D Submission Tool >>>>> Date: June 10, 2009 12:26:53 PM GMT+03:00 >>>>> To: jouni.nospam@gmail.com >>>>> Subject: New Version Notification for >>>>> draft-korhonen-dime-mip6-feature-bits-01 >>>>> >>>>> >>>>> A new version of I-D, draft-korhonen-dime-mip6-feature- >>>>> bits-01.txt has >>>>> been successfuly submitted by Jouni Korhonen and posted to the >>>>> IETF >>>>> repository. >>>>> >>>>> Filename: draft-korhonen-dime-mip6-feature-bits >>>>> Revision: 01 >>>>> Title: Diameter MIP6 Feature Vector Additional Bit >>>>> Allocations >>>>> Creation_date: 2009-06-10 >>>>> WG ID: Independent Submission >>>>> Number_of_pages: 5 >>>>> >>>>> Abstract: >>>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile >>>>> IPv6 >>>>> Home Agent and the Authentication, Authorization, and Accounting >>>>> server may exchange a set of authorized mobility capabilities. >>>>> This >>>>> document defines new mobility capability flags that are used to >>>>> authorize per Mobile Node route optimization, Multiple Care-of >>>>> Address and user plane traffic encryption support. Furthermore, >>>>> this >>>>> document also defines a capability flag of indicating whether the >>>>> Home Agent is authorized to act as a stand alone Virtual Private >>>>> Network gateway. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >> >> From hannes.tschofenig@nsn.com Tue Jun 16 10:19:25 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC3A3A6ACC for ; Tue, 16 Jun 2009 10:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.328 X-Spam-Level: X-Spam-Status: No, score=-5.328 tagged_above=-999 required=5 tests=[AWL=1.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoO-9TOg1GSe for ; Tue, 16 Jun 2009 10:19:21 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7C5203A6A61 for ; Tue, 16 Jun 2009 10:19:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n5GHJVmD031253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jun 2009 19:19:31 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n5GHJV7C022074 for ; Tue, 16 Jun 2009 19:19:31 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 19:19:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 20:21:30 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45017404A1@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: REMINDER: DIME WGLCs! Thread-Index: AcnupuOpJjhFBEnMSjCvN6p4VbInmQ== X-Priority: 1 Priority: Urgent Importance: high From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 16 Jun 2009 17:19:30.0922 (UTC) FILETIME=[9C312CA0:01C9EEA6] Subject: [Dime] REMINDER: DIME WGLCs! X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:19:25 -0000 Hi all,=20 Please keep the ongoing WGLCs in mind. Here is a short summary: * draft-ietf-dime-rfc3588bis-17.txt http://www.ietf.org/mail-archive/web/dime/current/msg03533.html Deadline: Sunday, 5 July * draft-ietf-dime-diameter-cmd-iana-00.txt http://www.ietf.org/mail-archive/web/dime/current/msg03534.html Deadline: Wednesday, 17 June. * draft-ietf-dime-diameter-base-protocol-mib-00.txt http://www.ietf.org/mail-archive/web/dime/current/msg03535.html Deadline: Sunday, 21 June * draft-ietf-dime-diameter-cc-appl-mib-00.txt http://www.ietf.org/mail-archive/web/dime/current/msg03536.html Deadline: Sunday, 21 June. Ciao Hannes PS: If you are the author of a specification in DIME I expect that you read other people's document as well.=20 From john.loughney@nokia.com Tue Jun 16 10:46:46 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B7C928C1B5 for ; Tue, 16 Jun 2009 10:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCvqJKzeeJGh for ; Tue, 16 Jun 2009 10:46:45 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 40A1228C1B4 for ; Tue, 16 Jun 2009 10:46:45 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5GHk0Np011125 for ; Tue, 16 Jun 2009 12:46:30 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 20:46:15 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 20:46:10 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 16 Jun 2009 19:46:10 +0200 From: To: Importance: high Date: Tue, 16 Jun 2009 19:46:08 +0200 Thread-Topic: Quick review of draft-ietf-dime-diameter-cmd-iana-00.txt Thread-Index: AcnuqHi7tlI9gXP/SHu3uope/OaB3gAAMpwQ Message-ID: <1F18D6510CF0474A8C9500565A7E41A20545674479@NOK-EUMSG-02.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jun 2009 17:46:10.0984 (UTC) FILETIME=[55E74280:01C9EEAA] X-Nokia-AV: Clean Subject: [Dime] Quick review of draft-ietf-dime-diameter-cmd-iana-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:46:46 -0000 Dear Dime-ers, Here is a quick review of draft-ietf-dime-diameter-cmd-iana-00.txt http://www.ietf.org/mail-archive/web/dime/current/msg03534.html Basically, this seems like a reasonable approach to me. Some specific=20 comments: The introduction says: The Diameter Base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands, i.e. messages used by Diameter applications, and applications as the most extensive enhancements. I am confused by the wording "extensive enhancements" - do you mean " ...co= mmon=20 ways to extend the protocol"? If so, then it make sense. More substantive: IANA considerations say: The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific command codes, to be allocated on a First Come, First Served basis by IANA [RFC5226]. The request to IANA for a Vendor-Specific Command Code SHOULD include a reference to a publicly available specification which documents the command in sufficient detail to aid in interoperability between independent implementations. If the specification cannot be made publicly available, the request for a vendor-specific command code MUST include the contact information of persons and/or entities responsible for authoring and maintaining the command. My biggest worry is that we get a lot of fragmentation in the command code = space, like we have seen with RADIUS, and we just end up making Diameter =3D 2xRAD= IUS ... I don't have a great solution, other than labeling this area as 'EXPERIMENT= AL' code space and if someone wants to upgrade it to a standard, then they shou= ld have a lightweight publication mechanism via the IETF.=20 Then again, perhaps the WG has gone through this and understands all of the= trade-offs and implications of this, therefore my worries are no warranted. If it is = so, then I am fine with this approach. John= From john.loughney@nokia.com Tue Jun 16 10:59:18 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7ED3A6807 for ; Tue, 16 Jun 2009 10:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+jGszeCBugZ for ; Tue, 16 Jun 2009 10:59:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 23DB03A68D7 for ; Tue, 16 Jun 2009 10:59:18 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5GHwenL020793 for ; Tue, 16 Jun 2009 12:59:31 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 20:56:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 20:56:54 +0300 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 16 Jun 2009 19:56:52 +0200 From: To: Date: Tue, 16 Jun 2009 19:56:50 +0200 Thread-Topic: Quick review of MIBs Thread-Index: Acnuq9NUQVvshZPQRRelyDd+NhO0EQ== Message-ID: <1F18D6510CF0474A8C9500565A7E41A2054567448A@NOK-EUMSG-02.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1F18D6510CF0474A8C9500565A7E41A2054567448ANOKEUMSG02mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jun 2009 17:56:54.0049 (UTC) FILETIME=[D5333110:01C9EEAB] X-Nokia-AV: Clean Subject: [Dime] Quick review of MIBs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:59:18 -0000 --_000_1F18D6510CF0474A8C9500565A7E41A2054567448ANOKEUMSG02mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dime-ers, I have read through the MIB documents (CCA and Base spec). I am by no mean= s a MIB expert, but they seem reasonable to me. John --_000_1F18D6510CF0474A8C9500565A7E41A2054567448ANOKEUMSG02mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dime-ers,
 
I have read through the MIB documents (CCA and Base spec).  I am = by no means a MIB expert, but they seem reasonable to me. 
 
John
 
 --_000_1F18D6510CF0474A8C9500565A7E41A2054567448ANOKEUMSG02mgd_-- From Mark.Jones@bridgewatersystems.com Tue Jun 16 13:38:18 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF2428C1AE for ; Tue, 16 Jun 2009 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GksjDwhu0cB2 for ; Tue, 16 Jun 2009 13:38:18 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 3091328C18F for ; Tue, 16 Jun 2009 13:38:17 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Tue, 16 Jun 2009 16:38:28 -0400 From: Mark Jones To: "dime@ietf.org" Date: Tue, 16 Jun 2009 16:38:27 -0400 Thread-Topic: Review of draft-ietf-dime-diameter-base-protocol-mib-00 Thread-Index: AcnuwmapFSKhsYI8SLuJgJpMFzVh9g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Dime] Review of draft-ietf-dime-diameter-base-protocol-mib-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:38:19 -0000 I have reviewed this draft and only have one comment: The dbpPeerVendorId s= hould be Unsigned32 rather than enumerated INTEGER. Other than that the dra= ft looks fine to me. Regards Mark From gwz@net-zen.net Tue Jun 16 22:52:46 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4D53A6DC7 for ; Tue, 16 Jun 2009 22:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+kuTSBN1vhy for ; Tue, 16 Jun 2009 22:52:45 -0700 (PDT) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id 17D773A6DBF for ; Tue, 16 Jun 2009 22:52:44 -0700 (PDT) Received: (qmail 9704 invoked from network); 17 Jun 2009 05:52:55 -0000 Received: from unknown (124.122.162.63) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 17 Jun 2009 05:52:54 -0000 From: "Glen Zorn" To: "'Mark Jones'" References: In-Reply-To: Date: Wed, 17 Jun 2009 12:49:22 +0700 Organization: Network Zen Message-ID: <00f701c9ef0f$60384c60$20a8e520$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnuwmapFSKhsYI8SLuJgJpMFzVh9gATM9Ww Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-diameter-base-protocol-mib-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 05:52:46 -0000 Mark Jones [mailto://Mark.Jones@bridgewatersystems.com] writes: > I have reviewed this draft and only have one comment: The > dbpPeerVendorId should be Unsigned32 rather than enumerated INTEGER. OK. > Other than that the draft looks fine to me. > > Regards > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Wed Jun 17 01:45:38 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5C628C179 for ; Wed, 17 Jun 2009 01:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW-xkYLPjtQH for ; Wed, 17 Jun 2009 01:45:37 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 5478F28C0E2 for ; Wed, 17 Jun 2009 01:45:37 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n5H8jjuH020832 for ; Wed, 17 Jun 2009 17:45:45 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n5H8jjax014198 for ; Wed, 17 Jun 2009 17:45:45 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n5H8jjO0014192 for ; Wed, 17 Jun 2009 17:45:45 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id B6B9215FB2 for ; Wed, 17 Jun 2009 17:45:45 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NICT Mail) with ESMTP id B15A815FB1 for ; Wed, 17 Jun 2009 17:45:45 +0900 (JST) Message-ID: <4A38AD20.4020606@nict.go.jp> Date: Wed, 17 Jun 2009 17:45:20 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "dime@ietf.org" References: <1F18D6510CF0474A8C9500565A7E41A20545674479@NOK-EUMSG-02.mgdnok.nokia.com> In-Reply-To: <1F18D6510CF0474A8C9500565A7E41A20545674479@NOK-EUMSG-02.mgdnok.nokia.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Quick review of draft-ietf-dime-diameter-cmd-iana-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 08:45:38 -0000 Hello, I'd just have a very small editorial comment. By the end of page 4: WG [I-D.ietf-dime-rfc3588bis]. and when approved will obsolete RFC ^^^ I think the dot after the reference should be removed. Since the content is redundant with rfc3588bis section 11.2.1, I am wondering if modifying that draft (3588bis) to reference this one when it becomes an RFC (hopefully before the 3588bis) would not result in less work for everyone ? Just an idea... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Wed Jun 17 02:42:15 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BA128C21E for ; Wed, 17 Jun 2009 02:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atibGbQiYOAO for ; Wed, 17 Jun 2009 02:42:15 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1BC5128C12C for ; Wed, 17 Jun 2009 02:42:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLD00JJ7MWYVA@szxga04-in.huawei.com> for dime@ietf.org; Wed, 17 Jun 2009 17:41:22 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLD00EFYMWXBM@szxga04-in.huawei.com> for dime@ietf.org; Wed, 17 Jun 2009 17:41:22 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLD001LSMWXL7@szxml04-in.huawei.com> for dime@ietf.org; Wed, 17 Jun 2009 17:41:21 +0800 (CST) Date: Wed, 17 Jun 2009 17:41:21 +0800 From: Qin Wu To: dime@ietf.org Message-id: <046f01c9ef2f$c5d5bbf0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1F18D6510CF0474A8C9500565A7E41A20545674479@NOK-EUMSG-02.mgdnok.nokia.com> <4A38AD20.4020606@nict.go.jp> Subject: Re: [Dime] Quick review of draft-ietf-dime-diameter-cmd-iana-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 09:42:15 -0000 Hi: May I have a quick comment for draft-dime-diameter-cmd-iana. In the introduction of this draft, it points out a serious design issue that other SDO choose to define new applications on existing commands rather than asking for assignment of new command codes. I totally agree with it. I wonder how this problem is really resolved in this draft? Does it mean that the other SDO uses vendor specific command code namespace to assign new command codes if they want to avoid IETF review? Why not strenghen interoperability between different SDO to get around this problem? Also I wonder whether there is the similar bad design issue in the IETF relevant work? Regards! -Qin From sunseawq@huawei.com Wed Jun 17 02:44:55 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDDE3A6893; Wed, 17 Jun 2009 02:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4FQGYCmTXN3; Wed, 17 Jun 2009 02:44:54 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6A78A3A686D; Wed, 17 Jun 2009 02:44:54 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLD00G8FMZZL1@szxga01-in.huawei.com>; Wed, 17 Jun 2009 17:43:11 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLD007UTMZY8I@szxga01-in.huawei.com>; Wed, 17 Jun 2009 17:43:10 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLD00ADUMZYCJ@szxml06-in.huawei.com>; Wed, 17 Jun 2009 17:43:10 +0800 (CST) Date: Wed, 17 Jun 2009 17:43:10 +0800 From: Qin Wu To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Julien Bournelle , Sebastien Decugis Message-id: <047801c9ef30$06cda960$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906090001te5184f0w1aaa487161ad39be@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B45016DC48B@FIESEXC015.nsn-intra.net> Cc: dime@ietf.org, hokey@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 09:44:55 -0000 > Hi all, > > there seems to be a misunderstanding here. > > We have a working group document with agreed authors. > The only question therefore is what the group wants to go into the > existing document - the content. No new document will be added to the > DIME milestones. > > What Sebastien should be asking the group is whether the content in > draft-sdecugis-dime-diameter-erp-01.txt should be included in the next > version of draft-ietf-dime-erp. [Qin]: I support incorporating Sebastien's changes into next version of draft-ietf-dime-erp. > In any case, it is good to ask the group whether this significant change > should be made. > > My answer: I believe that this is the right direction, as I indicated > previously on the list. > > Ciao > Hannes > > > > > ________________________________ > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of ext Julien Bournelle > Sent: 09 June, 2009 10:02 > To: Sebastien Decugis > Cc: dime@ietf.org; hokey@ietf.org > Subject: Re: [Dime] New draft for Diameter ERP: poll for > adoption > > > Hello, > > See inline, > > > On Mon, Jun 8, 2009 at 5:57 AM, Sebastien Decugis > wrote: > > > Hi all DIME and HOKEY members, > > I have gone forward on the Diameter ERP topic and > created a new draft > [1] with the same content (re-organized, hopefully for > clarity) as I > presented during last DIME meeting in IETF#74. The main > change with > current draft-ietf-dime-erp-00 is the use of a new > separate Diameter > application for messages exchanged between the NAS and > the ER server. > > I would like to poll the people interested in this topic > about the > adoption of this new document for Diameter ERP (in which > case it would > become draft-ietf-dime-erp-01). I don't know if this can > be done before > the next IETF meeting, or at least during the meeting in > Stockholm? > > > > AFAIK, this is not how things are working at IETF. The WG has > already a WG document called draft-ietf-dime-erp-00.txt which is > supposed to reflect the current WG consensus. We can't arrive with a new > individual submission and just bypass the current WG I-D. At least, I > never saw that. > > Having said that, we have an issue with the current WG document > concerning use of a new Application-ID or reuse of the Diameter EAP. My > understanding was that we were a little blocked because of an > architectural issue concerning the HOKEY server in regards to AAA/EAP > server and because of a routing issue. So I'd like to know what has > changed from this point. > > Note that I'm not against your proposal per se. We just have to > get a consensus. > > Best regards, > > Julien > > > > > Thank you for reading, and eventually providing your > comments. > Sebastien. > > [1] > > http://www.ietf.org/internet-drafts/draft-sdecugis-dime-diameter-erp-01. > txt > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From julien.bournelle@gmail.com Wed Jun 17 06:18:35 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C6D28C25F for ; Wed, 17 Jun 2009 06:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmkNSKAXeLQ9 for ; Wed, 17 Jun 2009 06:18:33 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id E2D7F3A685E for ; Wed, 17 Jun 2009 06:18:32 -0700 (PDT) Received: by ewy6 with SMTP id 6so492611ewy.37 for ; Wed, 17 Jun 2009 06:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DEVEESqgd3/GjsJ3mqvWaDG4sGegn9qGQNHMXucPvm8=; b=of2Q13vgSrrPcEIsXo//N/EusSgyRuSZ5gbNJJpQOU/o/Et887cEmnEdiSbCDTg0g0 vqvJHPa54yyUed4BwlUVbp0LrW4I+dxJtLLfTpRK6DtbAIHD9RuXtAYfxZfXzj6vPCIW XOkSOY8v6+NQny9GH+stAseqXUdmS94MqcrGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bfaS9s1W6cR7/NnyL4SiRgD7YreQpgZRiJrs8UOk3AgHY89wQGGQkH8nMv2nXilh5b PlmSwCj2p3/Me8XXmmQ0k/JreWABkYztJoHWGf7N78QWCe7r/8qAHpbfyMvsEn0upmbf ZaGQG5mUYVSm9iKl04DJIx1Z/YSMcw+JHExl0= MIME-Version: 1.0 Received: by 10.216.10.208 with SMTP id 58mr76123wev.82.1245244711943; Wed, 17 Jun 2009 06:18:31 -0700 (PDT) In-Reply-To: <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> Date: Wed, 17 Jun 2009 15:18:31 +0200 Message-ID: <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis , dime@ietf.org Content-Type: multipart/alternative; boundary=0016364d2633b6cd39046c8b2044 Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:18:35 -0000 --0016364d2633b6cd39046c8b2044 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all, please find my comments inline (draft is quoted with ">"), On Wed, Jun 17, 2009 at 2:37 PM, Julien Bournelle < julien.bournelle@gmail.com> wrote: > > 1. Introduction > > [RFC5296] defines the EAP Re-authentication Protocol (ERP) and > mechanism that consists in the two following steps: > > 1. Bootstrapping: creation of a root key for re-authentication, > after initial EAP authentication of the peer. This root key is > distributed from the EAP server to the ER server. How this key > is tranported is not specified in the ERP mechanism. > > 2. Re-authentication: one-round-trip exchange between the peer and > the ER server, functionally equivalent to a full EAP > authentication. > > This document specifies how Diameter is used to carry the re- > authentication exchange (second step). For this purpose, we define a > new Application Id for ERP, and re-use the Diameter EAP commands > (DER/DEA). We need a justification here. > > We also discuss the key distribution (first step, bootstrapping) and > propose some solutions for different architectures. Anyway, > implementors are free to choose a different mechanism for key > distribution, as for example using RADIUS [I-D.ietf-hokey-key-mgm]. Rafa sent an email on this draft and I agree with him i.e. the draft should not mention RADIUS, only AAA. > Security considerations for key distribution are explained in > [RFC5295]. > > 1.1. Differences with other documents > > This document differs from [I-D.ietf-dime-erp] in its design and > scope. In this new version, we use a new Diameter application id for > messages with ERP payload exchanged between authenticator and ER > server. This simplifies the routing of Diameter messages to the > appropriate server, and allows more flexibility in the deployment of > ERP. in which scenario does it simplify the routing process ? in case of HO to a new authenticator ? If this is the case, I don't really understand how it solves the problem because we may have deployed 2 ERPs servers. > > The scope of previous documents ([I-D.ietf-dime-erp] and > [I-D.wu-dime-local-keytran]) was focused on the bootstrapping of the > mechanism. this is not really true. The goal of our document was to define how to use Diameter for ERP for bootstrapping and reauthentication. > In particular, these documents did not consider the > routing of Diameter message for re-authentication exchanges (ERP > exchange, and also [RFC4187] for the second document). By re-using > the Diameter EAP application, they create implicit constraints on > routing of messages that cannot be met by standard Diameter routing > algorithm, as defined in the Diameter Base Protocol [RFC3588]. > > A separate Diameter application solves this routing issue, and can > also allow the authenticator to dynamically discover if the local > domain supports re-authentication or not. I think that it is important to highlight what was the issue and how the Application-Id solve it. I don't think that we can go in this new direction without a clear understanding of the issue and of course of the proposed solution. So, could you send an email explaining the Issue and the proposed solution ? > > > > > Decugis Expires December 10, 2009 [Page 3] > > Internet-Draft Diameter ERP support June 2009 > > > 2. Terminology > > We re-use in this document the terminology from [RFC5296]. In > particular, unless specified otherwise, the EAP server has implicit > support for ERP extensions for generation of ERP keying material and > its transmission to ER server. These terms "authenticator", "ER > server", "EAP server" designate logical functional entities and make > no assumption on the real implementation and deployment. > > "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK > derived from an EMSK, depending on the location of the ER server in > home or foreign domain. > > We re-use also some terminology and abbreviations from [RFC4072], for > example DER/DEA. > > 2.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > 3. Overview > > During the lifetime of an EMSK (derived during a full EAP > authentication by compatible EAP methods), a peer may attach to > several authenticators. In this case, re-authentication is more > efficient than full authentication, especially in the case of > roaming. ERP provides a mechanism for re-authentication independent > of the link layer, so it can be used in case of multihoming or > handovers between different access technologies. The following > figure shows the components involved in ERP, and their interactions. > When the peer attaches to a new authenticator, the ER server involved > in the transaction may change, for example in the case of inter- > domain roaming. The home EAP server is assumed to be constant for a > given peer. > > Diameter +--------+ > +-------------+ ERP +-----------+ (*) | Home | > Peer <->|Authenticator|<=======>| ER server | <---> | EAP | > +-------------+ +-----------+ | server | > +--------+ > (*) Several protocols can be used between ER server and > home EAP server to transport bootstrapping material. > > Figure 1. Diameter applications used in the ERP mechanism. > > The ER server may be located in the home domain (same as EAP server) > > > > Decugis Expires December 10, 2009 [Page 4] > > Internet-Draft Diameter ERP support June 2009 > > > or the visited domain (same as authenticator, when it differs from > the home domain). [[Editor1: Can the ER server be located in a third > domain (ex: broker's)?]] Editor1: I don't think that we should consider this. > > The bootstrapping of the ER server has to occur sometime between the > initial EAP authentication and the first ERP re-authentication with > this ER server. See section Section 7 for detail on this process. > Then, the peer re-authenticates, for example after a movement that > makes it attach to a new authenticator. The following figure > describes this re-authentication, and shows how Diameter is used in > this context. See section Section 8 for a detailed description, and > following sections for details on the Diameter messages format. > > ER server > (bootstrapped) > Peer Authenticator (local or home domain) > ==== ============= ====================== > [ <------------------------ ] > [optional EAP-Initiate/Re-auth-start] > > -----------------------> > EAP-Initiate/Re-auth > ==================================> > Diameter ERP, cmd code DER > User-Name: Keyname-NAI > EAP-Payload: EAP-Initiate/Re-auth > > <================================== > Diameter ERP, cmd code DEA > EAP-Payload: EAP-Finish/Re-auth > EAP-Master-Session-Key: rMSK > <---------------------- > EAP-Finish/Re-auth > > Figure 2. Diameter ERP exchange. Just wondering: what happens with the originial AAA/EAP server which is supposed to handle in particular lifetime session ? Do we need to inform him of the HO ? what happens to its AAA session with the first authenticator ? and that's all for the moment. Regards, Julien --0016364d2633b6cd39046c8b2044 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,

please find my comments inline (draft is quoted with &qu= ot;>"),

On Wed, Jun 17, 2009 at 2:37 PM, Julien Bournelle &l= t;julien.bo= urnelle@gmail.com> wrote:
>

> 1. =A0Introduction
>
> =A0 [RFC5296] defines t= he EAP Re-authentication Protocol (ERP) and
> =A0 mechanism that cons= ists in the two following steps:
>
> =A0 1. =A0Bootstrapping: c= reation of a root key for re-authentication,
> =A0 =A0 =A0 after initial EAP authentication of the peer. =A0This root= key is
> =A0 =A0 =A0 distributed from the EAP server to the ER serve= r. =A0How this key
> =A0 =A0 =A0 is tranported is not specified in th= e ERP mechanism.
>
> =A0 2. =A0Re-authentication: one-round-trip exchange between t= he peer and
> =A0 =A0 =A0 the ER server, functionally equivalent to a= full EAP
> =A0 =A0 =A0 authentication.
>
> =A0 This docu= ment specifies how Diameter is used to carry the re-
> =A0 authentication exchange (second step). =A0For this purpose, we def= ine a
> =A0 new Application Id for ERP, and re-use the Diameter EAP c= ommands
> =A0 (DER/DEA).

We need a justification here.

>
> =A0 We also discuss the key distribution (first step, bootstra= pping) and
> =A0 propose some solutions for different architectures. = =A0Anyway,
> =A0 implementors are free to choose a different mechanis= m for key
> =A0 distribution, as for example using RADIUS [I-D.ietf-hokey-key-mgm]= .

=A0Rafa sent an email on this draft and I agree with him i.e. the = draft should
not mention RADIUS, only AAA.


> =A0 Security= considerations for key distribution are explained in
> =A0 [RFC5295].
>
> 1.1. =A0Differences with other document= s
>
> =A0 This document differs from [I-D.ietf-dime-erp] in its= design and
> =A0 scope. =A0In this new version, we use a new Diamete= r application id for
> =A0 messages with ERP payload exchanged between authenticator and ER> =A0 server. =A0This simplifies the routing of Diameter messages to t= he
> =A0 appropriate server, and allows more flexibility in the deplo= yment of
> =A0 ERP.

=A0in which scenario does it simplify the routing proc= ess ? in case of HO to a new authenticator ?
=A0If this is the case, I d= on't really understand how it solves the problem because we may have de= ployed
2 ERPs servers.

>
> =A0 The scope of previous documents ([I= -D.ietf-dime-erp] and
> =A0 [I-D.wu-dime-local-keytran]) was focused = on the bootstrapping of the
> =A0 mechanism.=A0

=A0this is not really true. The goal of our = document was to define how to use Diameter
for ERP for bootstrapping and= reauthentication.

>=A0 In particular, these documents did not co= nsider the
> =A0 routing of Diameter message for re-authentication exchanges (ERP> =A0 exchange, and also [RFC4187] for the second document). =A0By re-= using
> =A0 the Diameter EAP application, they create implicit constraints on<= br>> =A0 routing of messages that cannot be met by standard Diameter rou= ting
> =A0 algorithm, as defined in the Diameter Base Protocol [RFC35= 88].
>
> =A0 A separate Diameter application solves this routing issue,= and can
> =A0 also allow the authenticator to dynamically discover i= f the local
> =A0 domain supports re-authentication or not.

= =A0I think that it is important to highlight what was the issue and how the=
Application-Id solve it. I don't think that we can go in this new direc= tion
without a clear understanding of the issue and of course of the pro= posed
solution.

=A0So, could you send an email explaining the Is= sue and the proposed solution ?

>
>
>
>
> Decugis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Expire= s December 10, 2009 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page 3]
>
> In= ternet-Draft =A0 =A0 =A0 =A0 =A0 =A0Diameter ERP support =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 June 2009
>
>
> 2. =A0Terminology
>
> =A0 We re-use in this document the terminology from [RFC5296].= =A0In
> =A0 particular, unless specified otherwise, the EAP server h= as implicit
> =A0 support for ERP extensions for generation of ERP ke= ying material and
> =A0 its transmission to ER server. =A0These terms "authenticator&= quot;, "ER
> =A0 server", "EAP server" designate = logical functional entities and make
> =A0 no assumption on the real = implementation and deployment.
>
> =A0 "Root key" (RK) or "bootstrapping material&= quot; refer to the rRK or rDSRK
> =A0 derived from an EMSK, depending= on the location of the ER server in
> =A0 home or foreign domain. >
> =A0 We re-use also some terminology and abbreviations from [RFC4072], = for
> =A0 example DER/DEA.
>
> 2.1. =A0Requirements Langu= age
>
> =A0 The key words "MUST", "MUST NOT"= ;, "REQUIRED", "SHALL", "SHALL NOT",
> =A0 "SHOULD", "SHOULD NOT", "RECOMMENDED"= ;, "MAY", and "OPTIONAL" in this
> =A0 document a= re to be interpreted as described in [RFC2119].
>
> 3. =A0Overv= iew
>
> =A0 During the lifetime of an EMSK (derived during a full EAP<= br>> =A0 authentication by compatible EAP methods), a peer may attach to=
> =A0 several authenticators. =A0In this case, re-authentication is = more
> =A0 efficient than full authentication, especially in the case of
&= gt; =A0 roaming. =A0ERP provides a mechanism for re-authentication independ= ent
> =A0 of the link layer, so it can be used in case of multihoming= or
> =A0 handovers between different access technologies. =A0The following<= br>> =A0 figure shows the components involved in ERP, and their interact= ions.
> =A0 When the peer attaches to a new authenticator, the ER ser= ver involved
> =A0 in the transaction may change, for example in the case of inter-> =A0 domain roaming. =A0The home EAP server is assumed to be constant= for a
> =A0 given peer.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Diameter =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--= ------+
> =A0 =A0 =A0 =A0 =A0 +-------------+ =A0 ERP =A0 +-----------+ =A0(*) = =A0| =A0Home =A0|
> =A0 Peer <->|Authenticator|<=3D=3D=3D=3D= =3D=3D=3D>| ER server | <---> | =A0EAP =A0 |
> =A0 =A0 =A0 = =A0 =A0 +-------------+ =A0 =A0 =A0 =A0 +-----------+ =A0 =A0 =A0 | server = |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--------+
> =A0 =A0 =A0 (*) = Several protocols can be used between ER server and
> =A0 =A0 =A0 =A0= =A0home EAP server to transport bootstrapping material.
>
> =A0 =A0 =A0 =A0Figure 1. Diameter applications used in the ERP mechani= sm.
>
> =A0 The ER server may be located in the home domain (sa= me as EAP server)
>
>
>
> Decugis =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Expires December 10, 2009 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page= 4]
>
> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0Diameter ERP support =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 June 2009
>
>
> =A0 or the v= isited domain (same as authenticator, when it differs from
> =A0 the = home domain). =A0[[Editor1: Can the ER server be located in a third
> =A0 domain (ex: broker's)?]]

=A0Editor1: I don't think = that we should consider this.

>
> =A0 The bootstrapping of = the ER server has to occur sometime between the
> =A0 initial EAP aut= hentication and the first ERP re-authentication with
> =A0 this ER server. =A0See section Section 7 for detail on this proces= s.
> =A0 Then, the peer re-authenticates, for example after a movement that=
> =A0 makes it attach to a new authenticator. =A0The following figur= e
> =A0 describes this re-authentication, and shows how Diameter is u= sed in
> =A0 this context. =A0See section Section 8 for a detailed description,= and
> =A0 following sections for details on the Diameter messages fo= rmat.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ER server
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(bootstrapped)
> =A0Peer =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Authenticator =A0 =A0 =A0 =A0 =A0 =A0 =A0 (loca= l or home domain)
> =A0=3D=3D=3D=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =A0[ <------------------------ =A0 =A0 =A0 =A0 ]
> =A0[option= al EAP-Initiate/Re-auth-start]
>
> =A0 -----------------------&= gt;
> =A0 =A0 EAP-Initiate/Re-auth
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Diamete= r ERP, cmd code DER
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0User-Name: Keyname-NAI
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0EAP-Payload: EAP-Initiate/Re-auth
>= ;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Diamete= r ERP, cmd code DEA
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0EAP-Payload: EAP-Finish/Re-auth
> =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EAP-Master-Session-Key: rMSK
> = =A0 =A0<----------------------
> =A0 =A0 =A0EAP-Finish/Re-auth
>
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Figure 2. Diameter ERP exchange.


=A0Just wonderi= ng: what happens with the originial AAA/EAP server which is
supposed to = handle in particular lifetime session ? Do we need to inform
him of the HO ? what happens to its AAA session with the first authenticato= r ?

=A0and that's all for the moment.

=A0Regards,

= =A0Julien


--0016364d2633b6cd39046c8b2044-- From behcetsarikaya@yahoo.com Wed Jun 17 12:39:06 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3949F28C2E5 for ; Wed, 17 Jun 2009 12:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idvVbLI2wJSK for ; Wed, 17 Jun 2009 12:39:05 -0700 (PDT) Received: from n64.bullet.mail.sp1.yahoo.com (n64.bullet.mail.sp1.yahoo.com [98.136.44.189]) by core3.amsl.com (Postfix) with SMTP id 74D123A6A2B for ; Wed, 17 Jun 2009 12:38:50 -0700 (PDT) Received: from [69.147.84.144] by n64.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jun 2009 19:39:00 -0000 Received: from [67.195.9.82] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jun 2009 19:39:00 -0000 Received: from [67.195.9.99] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 17 Jun 2009 19:39:00 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 17 Jun 2009 19:36:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 795609.9455.bm@omp103.mail.gq1.yahoo.com Received: (qmail 70681 invoked by uid 60001); 17 Jun 2009 19:39:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245267540; bh=xcsac6OfOc2sito/n4yNggBdLXzq7E9rrDZHjsT5HtA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=daYGJBznm8rFMUACEJjbjiSs1VbtzvmSzp+gNcdQsvbWF1ZHd6L39DZ5bugj9CagS0tn8nzRz4GY7phTWYsJyunUw3mw62uObpWooGZMiIXUnpII+Ry4g8YnuN8592Ur5SjbCsWYSx45HRsTnPFf38lkSBx3z8DquBJM9IbXdg0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vdY5vGQhvRc1cnvNhPIRuYXTW26WJaYD1owr6OiNoL/i6CowtsC7CUmJyD2T1O83kqTrzPKM06iT6uOnpH/OuyXYXUcnyU/PgvjUqSODuA/XrgYYjJ30ce+qsY51pvFhpiYwsHIWAm6e/BUPA6Ce/6Re0eVKRhugaz+gFDMJ8X8=; Message-ID: <505836.70599.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: JJymww4VM1nRbbfcvY9.MNf7uNPKjzQfwfrX84Ce5FC7QT9GfRcLV6cIMgGCnNuUrDu4RTbJvZpFVIbQPiv.jq6dVHV4hxg_vziMfQb_rHdJuoUQVVJiCp5S..U8ZA1joaEQAXVBdDCTcp4pqE8ayvoUsYgMNLO7u4ZuPfxIs8XRo2LwiP9ZOZfLqnTRiQk7ZTU3BVK0etU6mT68XEb0wYDVwdvi7x1iCsHrFVp1131J2uBAoH.WedlTnLM0EHCuyAKFsLU0_EKb8MLNDGW8ipHeZqvdknlNv5XSrub4jvousYWGho4VbfHB1CFI4jAdkbZsXKSch3ELdB039TyCbpI- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Wed, 17 Jun 2009 12:39:00 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <2FA145BF-2534-4A2A-A878-C50A6B3C0087@gmail.com> <5CC059D9-6113-49A3-9748-9F4562A248CC@gmail.com> Date: Wed, 17 Jun 2009 12:39:00 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen , Vijay Devarapalli In-Reply-To: <5CC059D9-6113-49A3-9748-9F4562A248CC@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 19:39:06 -0000 Hi Jouni,=0A=A0 I have no comment on your points below except this one:=0AW= ell.. feature in a sense that you have both functionalities in the same box= anyway. Stretching my memory on the requirements, this came from the cases= where an I-WLAN PDG and a HA were to be bundled together.=0A=0AI don't thi= nk ePDG and HA can be bundled together in 3GPP architecture. HA is at the P= DN Gateway an entity above PDG.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- = Original Message ----=0AFrom: jouni korhonen =0ATo:= Vijay Devarapalli =0ACc: dime@ietf.org=0ASent: Tuesday, = June 16, 2009 5:27:44 AM=0ASubject: Re: [Dime] Fwd: New Version Notificatio= n for draft-korhonen-dime-mip6-feature-bits-01=0A=0AHi Vijay,=0A=0AOn Jun 1= 6, 2009, at 3:32 AM, Vijay Devarapalli wrote:=0A=0A> Hi Jouni,=0A> =0A> On = Wed, Jun 10, 2009 at 11:03 PM, jouni korhonen wrote= :=0A>> Hi Vijay,=0A>> =0A>> =0A>> On Jun 11, 2009, at 12:49 AM, Vijay Devar= apalli wrote:=0A>> =0A>>> Hi Jouni,=0A>>> =0A>>> I have a comment on the "V= PN Gateway feature". There is no document=0A>>> that describes what it mean= s for a Mobile IPv6 home agent to act as a=0A>>> VPN gateway. The IKEv2 exc= hange between the MN and the HA [RFC 4877=0A>>> and 5026] already supports = mutual authentication, address assignment=0A>>> and setting up of tunnel mo= de ESP SAs. Are you referring to this as=0A>>> VPN mode? But isn't this reg= ular Home agent functionality?=0A>> =0A>> The "VPN mode" is when you use HA= IKEv2/IPsec functionality purely for=0A>> conventional VPN remote access p= urposes without any mobility.=0A> =0A> Again, what does this mean? When you= run IKEv2 as described in RFC=0A> 4877 and 5026, you are creating tunnel m= ode security associations for=0A> a *Mobile IPv6 tunnel*. In the "VPN" mode= , does the mobile node switch=0A> of the Mobile IPv6 stack?=0A=0AVPN mode i= s plain RFC4306 + 4303 etc. You end up implementing that machinery there in= any case, so why not allow using a HA as a VPN gateway as well. In this ca= se, there is no mobility involved.=0A=0A> =0A> Or does the Home Agent behav= e an IPsec VPN gateway for pure IPsec=0A> clients, i.e., there is no Mobile= IPv6 stack on these clients.=0A=0AYes.=0A=0A=0A> =0A> =0A>> That type of= =0A>> deployment is shortly referenced in draft-ietf-dime-mip6-split Sectio= n 4.1.=0A>> I recall this functionality was originally requested by Gerardo= ..=0A> =0A> It doesn't make sense to me. :) This looks more like co-locating= a=0A> Mbile IPv6 home agent and an IPsec VPN gateway and supporting both= =0A> Mobile IPv6 mobile nodes and plain IPsec clients at the same time.=0A= =0AYes, it is about co-location. To me it makes sense as much as IKEv2+IPse= c with MIP6 ;)=0A=0A=0A> =0A> =0A> There has to be more to this scenario th= an just the short paragraph in=0A> draft-ietf-dime-mip6-split.=0A=0AYes, ag= ree.=0A=0A=0A> =0A> =0A>>> Or is there a separate IPsec VPN that is first s= etup and then Mobile=0A>>> IPv6 is run on top of the IPsec tunnels?=0A>> = =0A>> As shortly described in split document:=0A>> =0A>>=A0 In some deploym= ent scenarios, the HA may also act as an IKEv2=0A>>=A0 Responder for a conv= entional IPsec VPN access.=A0 The challenge in this=0A>>=A0 case is that th= e IKEv2 responder may not know if IKEv2 is used for=0A>>=A0 Mobile IPv6 ser= vice or for IPsec VPN access service.=A0 A network=0A>>=A0 operator needs t= o be aware of this limitation.=A0 One solution already=0A>>=A0 supported by= IKEv2 is to use different responder identities when=0A>>=A0 operating as a= conventional IPsec VPN gateway or as a HA.=A0 The MN can=0A>>=A0 then indi= cate the preferred responder type using the appropriate IDr=0A>>=A0 payload= in the IKE_AUTH message.=0A>> =0A>> But yeah, now that feature bits are ta= ken into a separate document, the=0A>> connection between the above and the= new feature bit is rather weak. Either=0A>> we need more text and/or refer= ence in the draft-korhonen-dime-feature-bits=0A>> or just remove the bit al= l together. Since the difference between=0A>> conventional IKEv2 IPsec VPN = gateway part and HA's IKEv2 IPsec functionality=0A>> is rather small, I wou= ld keep the feature bit and enhance the text instead.=0A> =0A> It is not "r= ather small" in my opinion. I don't understand how=0A> supporting plain IPs= ec clients can be a feature on a Mobile IPv6 home=0A> agent. :)=0A=0AWell..= feature in a sense that you have both functionalities in the same box anyw= ay. Stretching my memory on the requirements, this came from the cases wher= e an I-WLAN PDG and a HA were to be bundled together.=0A=0AJouni=0A=0A=0A> = =0A> =0A> Vijay=0A> =0A>> =0A>> Jouni=0A>> =0A>> =0A>>> =0A>>> =0A>>> Vijay= =0A>>> =0A>>> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen=0A>>> wrote:=0A>>>> =0A>>>> Hi all,=0A>>>> =0A>>>> I have update= d the additional feature bits draft. I did remove some stuff=0A>>>> so=0A>>= >> that the draft now only reserves MIP6-Feature-Vector flag bits and=0A>>>= > nothing=0A>>>> more. I'll forward the draft soon to RFC editor so if anyo= ne has=0A>>>> comments,=0A>>>> please be quick :)=0A>>>> =0A>>>> Cheers,=0A= >>>>=A0 =A0 =A0 Jouni=0A>>>> =0A>>>> Begin forwarded message:=0A>>>> =0A>>>= >> From: IETF I-D Submission Tool =0A>>>>> Date: Jun= e 10, 2009 12:26:53 PM GMT+03:00=0A>>>>> To: jouni.nospam@gmail.com=0A>>>>>= Subject: New Version Notification for=0A>>>>>=A0 draft-korhonen-dime-mip6-= feature-bits-01=0A>>>>> =0A>>>>> =0A>>>>> A new version of I-D, draft-korho= nen-dime-mip6-feature-bits-01.txt has=0A>>>>> been successfuly submitted by= Jouni Korhonen and posted to the IETF=0A>>>>> repository.=0A>>>>> =0A>>>>>= Filename:=A0 =A0 =A0 =A0 draft-korhonen-dime-mip6-feature-bits=0A>>>>> Rev= ision:=A0 =A0 =A0 =A0 01=0A>>>>> Title:=A0 =A0 =A0 =A0 =A0 Diameter MIP6 Fe= ature Vector Additional Bit Allocations=0A>>>>> Creation_date:=A0 2009-06-1= 0=0A>>>>> WG ID:=A0 =A0 =A0 =A0 =A0 Independent Submission=0A>>>>> Number_o= f_pages: 5=0A>>>>> =0A>>>>> Abstract:=0A>>>>> During the Mobile IPv6 Split = Scenario bootstrapping the Mobile IPv6=0A>>>>> Home Agent and the Authentic= ation, Authorization, and Accounting=0A>>>>> server may exchange a set of a= uthorized mobility capabilities.=A0 This=0A>>>>> document defines new mobil= ity capability flags that are used to=0A>>>>> authorize per Mobile Node rou= te optimization, Multiple Care-of=0A>>>>> Address and user plane traffic en= cryption support.=A0 Furthermore, this=0A>>>>> document also defines a capa= bility flag of indicating whether the=0A>>>>> Home Agent is authorized to a= ct as a stand alone Virtual Private=0A>>>>> Network gateway.=0A>>>>> =0A>>>= >> =0A>>>>> =0A>>>>> The IETF Secretariat.=0A>>>>> =0A>>>>> =0A>>>> =0A>>>>= _______________________________________________=0A>>>> DiME mailing list= =0A>>>> DiME@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/dime=0A>= >>> =0A>> =0A>> =0A=0A_______________________________________________=0ADiM= E mailing list=0ADiME@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/dime= =0A=0A=0A=0A From jouni.nospam@gmail.com Wed Jun 17 13:31:57 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C23E3A6C75 for ; Wed, 17 Jun 2009 13:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FvKnFtpaJzU for ; Wed, 17 Jun 2009 13:31:56 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id D3DC53A6C10 for ; Wed, 17 Jun 2009 13:31:55 -0700 (PDT) Received: from a88-112-142-249.elisa-laajakaista.fi (a88-112-142-249.elisa-laajakaista.fi [88.112.142.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 7B119139792; Wed, 17 Jun 2009 23:32:01 +0300 (EEST) Message-Id: <945B86A7-D1F9-4D78-8EDB-1402B273A94A@gmail.com> From: jouni To: Behcet Sarikaya In-Reply-To: <505836.70599.qm@web111413.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 23:32:00 +0300 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <2FA145BF-2534-4A2A-A878-C50A6B3C0087@gmail.com> <5CC059D9-6113-49A3-9748-9F4562A248CC@gmail.com> <505836.70599.qm@web111413.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 20:31:57 -0000 Hi Behcet, I-WLAN PDG is not exactly the same as ePDG. And one can implement boxes that are not entirely the same as drawn is some SDO architecture. Cheers, Jouni On Jun 17, 2009, at 10:39 PM, Behcet Sarikaya wrote: > > Hi Jouni, > I have no comment on your points below except this one: > Well.. feature in a sense that you have both functionalities in the > same box anyway. Stretching my memory on the requirements, this came > from the cases where an I-WLAN PDG and a HA were to be bundled > together. > > I don't think ePDG and HA can be bundled together in 3GPP > architecture. HA is at the PDN Gateway an entity above PDG. > > Regards, > > Behcet > > > > ----- Original Message ---- > From: jouni korhonen > To: Vijay Devarapalli > Cc: dime@ietf.org > Sent: Tuesday, June 16, 2009 5:27:44 AM > Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen- > dime-mip6-feature-bits-01 > > Hi Vijay, > > On Jun 16, 2009, at 3:32 AM, Vijay Devarapalli wrote: > >> Hi Jouni, >> >> On Wed, Jun 10, 2009 at 11:03 PM, jouni korhonen> > wrote: >>> Hi Vijay, >>> >>> >>> On Jun 11, 2009, at 12:49 AM, Vijay Devarapalli wrote: >>> >>>> Hi Jouni, >>>> >>>> I have a comment on the "VPN Gateway feature". There is no document >>>> that describes what it means for a Mobile IPv6 home agent to act >>>> as a >>>> VPN gateway. The IKEv2 exchange between the MN and the HA [RFC 4877 >>>> and 5026] already supports mutual authentication, address >>>> assignment >>>> and setting up of tunnel mode ESP SAs. Are you referring to this as >>>> VPN mode? But isn't this regular Home agent functionality? >>> >>> The "VPN mode" is when you use HA IKEv2/IPsec functionality purely >>> for >>> conventional VPN remote access purposes without any mobility. >> >> Again, what does this mean? When you run IKEv2 as described in RFC >> 4877 and 5026, you are creating tunnel mode security associations for >> a *Mobile IPv6 tunnel*. In the "VPN" mode, does the mobile node >> switch >> of the Mobile IPv6 stack? > > VPN mode is plain RFC4306 + 4303 etc. You end up implementing that > machinery there in any case, so why not allow using a HA as a VPN > gateway as well. In this case, there is no mobility involved. > >> >> Or does the Home Agent behave an IPsec VPN gateway for pure IPsec >> clients, i.e., there is no Mobile IPv6 stack on these clients. > > Yes. > > >> >> >>> That type of >>> deployment is shortly referenced in draft-ietf-dime-mip6-split >>> Section 4.1. >>> I recall this functionality was originally requested by Gerardo.. >> >> It doesn't make sense to me. :) This looks more like co-locating a >> Mbile IPv6 home agent and an IPsec VPN gateway and supporting both >> Mobile IPv6 mobile nodes and plain IPsec clients at the same time. > > Yes, it is about co-location. To me it makes sense as much as > IKEv2+IPsec with MIP6 ;) > > >> >> >> There has to be more to this scenario than just the short paragraph >> in >> draft-ietf-dime-mip6-split. > > Yes, agree. > > >> >> >>>> Or is there a separate IPsec VPN that is first setup and then >>>> Mobile >>>> IPv6 is run on top of the IPsec tunnels? >>> >>> As shortly described in split document: >>> >>> In some deployment scenarios, the HA may also act as an IKEv2 >>> Responder for a conventional IPsec VPN access. The challenge in >>> this >>> case is that the IKEv2 responder may not know if IKEv2 is used for >>> Mobile IPv6 service or for IPsec VPN access service. A network >>> operator needs to be aware of this limitation. One solution >>> already >>> supported by IKEv2 is to use different responder identities when >>> operating as a conventional IPsec VPN gateway or as a HA. The >>> MN can >>> then indicate the preferred responder type using the appropriate >>> IDr >>> payload in the IKE_AUTH message. >>> >>> But yeah, now that feature bits are taken into a separate >>> document, the >>> connection between the above and the new feature bit is rather >>> weak. Either >>> we need more text and/or reference in the draft-korhonen-dime- >>> feature-bits >>> or just remove the bit all together. Since the difference between >>> conventional IKEv2 IPsec VPN gateway part and HA's IKEv2 IPsec >>> functionality >>> is rather small, I would keep the feature bit and enhance the text >>> instead. >> >> It is not "rather small" in my opinion. I don't understand how >> supporting plain IPsec clients can be a feature on a Mobile IPv6 home >> agent. :) > > Well.. feature in a sense that you have both functionalities in the > same box anyway. Stretching my memory on the requirements, this came > from the cases where an I-WLAN PDG and a HA were to be bundled > together. > > Jouni > > >> >> >> Vijay >> >>> >>> Jouni >>> >>> >>>> >>>> >>>> Vijay >>>> >>>> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen>>> > >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I have updated the additional feature bits draft. I did remove >>>>> some stuff >>>>> so >>>>> that the draft now only reserves MIP6-Feature-Vector flag bits and >>>>> nothing >>>>> more. I'll forward the draft soon to RFC editor so if anyone has >>>>> comments, >>>>> please be quick :) >>>>> >>>>> Cheers, >>>>> Jouni >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: IETF I-D Submission Tool >>>>>> Date: June 10, 2009 12:26:53 PM GMT+03:00 >>>>>> To: jouni.nospam@gmail.com >>>>>> Subject: New Version Notification for >>>>>> draft-korhonen-dime-mip6-feature-bits-01 >>>>>> >>>>>> >>>>>> A new version of I-D, draft-korhonen-dime-mip6-feature- >>>>>> bits-01.txt has >>>>>> been successfuly submitted by Jouni Korhonen and posted to the >>>>>> IETF >>>>>> repository. >>>>>> >>>>>> Filename: draft-korhonen-dime-mip6-feature-bits >>>>>> Revision: 01 >>>>>> Title: Diameter MIP6 Feature Vector Additional Bit >>>>>> Allocations >>>>>> Creation_date: 2009-06-10 >>>>>> WG ID: Independent Submission >>>>>> Number_of_pages: 5 >>>>>> >>>>>> Abstract: >>>>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile >>>>>> IPv6 >>>>>> Home Agent and the Authentication, Authorization, and Accounting >>>>>> server may exchange a set of authorized mobility capabilities. >>>>>> This >>>>>> document defines new mobility capability flags that are used to >>>>>> authorize per Mobile Node route optimization, Multiple Care-of >>>>>> Address and user plane traffic encryption support. >>>>>> Furthermore, this >>>>>> document also defines a capability flag of indicating whether the >>>>>> Home Agent is authorized to act as a stand alone Virtual Private >>>>>> Network gateway. >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat. >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>> >>> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > From tena@huawei.com Wed Jun 17 23:45:44 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16163A6EA0 for ; Wed, 17 Jun 2009 23:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWGgtC7FCrWU for ; Wed, 17 Jun 2009 23:45:43 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F0B713A6A38 for ; Wed, 17 Jun 2009 23:45:42 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLF0038Q9G82P@szxga02-in.huawei.com> for dime@ietf.org; Thu, 18 Jun 2009 14:45:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLF00CC19G8Z9@szxga02-in.huawei.com> for dime@ietf.org; Thu, 18 Jun 2009 14:45:44 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLF00KMG9G7CY@szxml04-in.huawei.com> for dime@ietf.org; Thu, 18 Jun 2009 14:45:44 +0800 (CST) Date: Thu, 18 Jun 2009 14:45:43 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <034401c9efe0$67274770$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_s941ettW0UdmdGdFXjymsQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Dime] comments on draft-ietf-dime-diameter-base-protocol-mib-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 06:45:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_s941ettW0UdmdGdFXjymsQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, Some comments on draft-ietf-dime-diameter-base-protocol-mib-00.txt are below. In the first paragraph of section 3, there is a statement saying "four standard applications have been defined to date, ...; others may be defined in the future". This doesn't seem to be not very accurate. There are many diameter applications defined in 3GPP, ITU-T, and ETSI TISPAN. So I suggest to remove this paragraph or at least this statement fromthis paragraph. In the second paragraph of section 3, it says "This MIB defines objects supporting the management of the Diameter base protocol as described in [RFC3588]." Just for clarification, is this MIB applicable to RFC3588bis or RFC3588? Or both? B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_s941ettW0UdmdGdFXjymsQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,
Some comments on draft-ietf-dime-diameter-base-protocol-mib-00.txt are below.
 
In the first paragraph of section 3, there is a statement saying "four standard applications have been defined to date, ...; others may be defined in the future".
This doesn't seem to be not very accurate. There are many diameter applications defined in 3GPP, ITU-T, and ETSI TISPAN. So I suggest to remove this paragraph or at least this statement fromthis paragraph.
 
In the second paragraph of section 3, it says "This MIB defines objects supporting the management of the Diameter base protocol as described in [RFC3588]."
Just for clarification, is this MIB applicable to RFC3588bis or RFC3588? Or both?
 
 
B. R.
Tina
--Boundary_(ID_s941ettW0UdmdGdFXjymsQ)-- From gwz@net-zen.net Thu Jun 18 00:24:04 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CAB03A67EB for ; Thu, 18 Jun 2009 00:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcyweIahoZMj for ; Thu, 18 Jun 2009 00:24:03 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id 5C6AE3A690D for ; Thu, 18 Jun 2009 00:24:03 -0700 (PDT) Received: (qmail 21885 invoked from network); 18 Jun 2009 07:24:13 -0000 Received: from unknown (124.122.163.140) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 18 Jun 2009 07:24:12 -0000 From: "Glen Zorn" To: "'Tina TSOU'" References: <034401c9efe0$67274770$8e27460a@china.huawei.com> In-Reply-To: <034401c9efe0$67274770$8e27460a@china.huawei.com> Date: Thu, 18 Jun 2009 14:20:37 +0700 Organization: Network Zen Message-ID: <00aa01c9efe5$4a400a70$dec01f50$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01C9F01F.F69EE270" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnv4HYbdSWEPI0LQLmna06JznNi5QABEBaw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-ietf-dime-diameter-base-protocol-mib-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 07:24:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AB_01C9F01F.F69EE270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tina Tsou [mailto://tena@huawei.com] writes: Hi, Some comments on draft-ietf-dime-diameter-base-protocol-mib-00.txt are below. In the first paragraph of section 3, there is a statement saying "four standard applications have been defined to date, ...; others may be defined in the future". This doesn't seem to be not very accurate. There are many diameter applications defined in 3GPP, ITU-T, and ETSI TISPAN. So I suggest to remove this paragraph or at least this statement fromthis paragraph. OK. In the second paragraph of section 3, it says "This MIB defines objects supporting the management of the Diameter base protocol as described in [RFC3588]." Just for clarification, is this MIB applicable to RFC3588bis or RFC3588? Or both? The MIB was developed a long time ago to support RFC 3588. Presumably, since rfc3588bis is claimed to be backward-compatible w/RFC 3588, it should be applicable to both. B. R. Tina http://tinatsou.weebly.com/contact.html ------=_NextPart_000_00AB_01C9F01F.F69EE270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Some comments on draft-ietf-dime-diameter-base-protocol-mib-00.txt are below. =

 

In the first paragraph of section 3, there is a statement saying "four standard applications have been defined to date, ...; others may be = defined in the future".

This doesn't seem to be not very accurate. There are many diameter = applications defined in 3GPP, ITU-T, and ETSI TISPAN. So I suggest to remove this = paragraph or at least this statement fromthis paragraph.

OK.

 

In the second paragraph of section 3, it says "This MIB defines = objects supporting the management of the Diameter base protocol as described in [RFC3588]."

Just for clarification, is this MIB applicable to RFC3588bis or = RFC3588? Or both?

The MIB was developed a long time ago to support RFC = 3588.  Presumably, since rfc3588bis is claimed to be backward-compatible w/RFC = 3588, it should be applicable to both. 

 

B. R.
Tina
------=_NextPart_000_00AB_01C9F01F.F69EE270-- From sunseawq@huawei.com Thu Jun 18 03:36:29 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BA23A6A25 for ; Thu, 18 Jun 2009 03:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md24+DlVQgaA for ; Thu, 18 Jun 2009 03:36:28 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 744A83A6834 for ; Thu, 18 Jun 2009 03:36:28 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLF00D9LK4874@szxga03-in.huawei.com> for dime@ietf.org; Thu, 18 Jun 2009 18:36:08 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLF00E59K47PZ@szxga03-in.huawei.com> for dime@ietf.org; Thu, 18 Jun 2009 18:36:07 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLF005DDK0GJG@szxml06-in.huawei.com> for dime@ietf.org; Thu, 18 Jun 2009 18:33:52 +0800 (CST) Date: Thu, 18 Jun 2009 18:33:51 +0800 From: Qin Wu To: dime@ietf.org Message-id: <031a01c9f000$460eefa0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <016501c9e5c8$9e730dd0$db592970$@net> Subject: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 10:36:29 -0000 Hi, May I have some comments on draft-ietf-dime-rfc3588bis-17? Regards! -Qin [snip] " 1. Introduction ............. Server-initiated messages While RADIUS server-initiated messages are defined in [RFC5176], support is optional. This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization " [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated? e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP) ", EAP Re-authentication is host/peer initiated, isn't it? So it is not very accurate to say the reauthentcation is server-initiated . " on demand across a heterogeneous deployment. Support for server-initiated messages is mandatory in " [Qin]: The last sentence is not complete. I guess we should say " To tackle this issue, support for server-initiated message is mandaroty in Diameter. " [snip] " Peer discovery and configuration RADIUS implementations typically require that the name or address of servers or clients be manually configured, along with the corresponding shared secrets. This results in a large administrative burden, and creates the temptation to reuse the RADIUS shared secret, which can result in major security vulnerabilities if the Request Authenticator is not globally and temporally unique as required in [RFC2865]. Through DNS, Diameter enables dynamic discovery of peers. " [Qin]: In order to align the contents in this paragraph with other paragraphs, the similar anchor point should be appended, i.e., s/ " Diameter enables dynamic discovery of peers. " / " Diameter enables dynamic discovery of peers (section 5.2). " [snip] " 1.1.1. Description of the Document Set [snip] " The Mobile IPv4 [RFC4004] application defines a Diameter application that allows a Diameter server to perform AAA functions for Mobile IPv4 services to a mobile node. " [Qin]: Do we need to add some references to Diameter support for Mobile IPv6 and Diameter support for Proxy Mobile IPv6? [snip] " 2.9. Diameter Path Authorization As noted in Section 2.2, Diameter provides transmission level security for each connection using TLS. Therefore, each connection can be authenticated, replay and integrity protected. " [Qin]: In which situation the Diameter Path Authorization will be used? Diameter Path Authoirzation will be performed between the Diameter Client and server? or between different Proxys or Relays? What is the main difference between Path authorization and service authorization? " In addition to authenticating each connection, each connection as well as the entire session MUST also be authorized. Before initiating a connection, a Diameter Peer MUST check that its peers are authorized to act in their roles. For example, a Diameter peer may be authentic, but that does not mean that it is authorized to act as a Diameter Server advertising a set of Diameter applications. Prior to bringing up a connection, authorization checks are performed at each connection along the path. Diameter capabilities negotiation (CER/CEA) also MUST be carried out, in order to determine what Diameter applications are supported by each peer. " [Qin]: What's the relationship between capabilities negotiation and Path Authorization? Why we mention capability negotation in this section? [snip] " 8. Diameter User Sessions [snip] " An access device that does not expect to send a re-authorization or a session termination request to the server MAY include the Auth- Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint to the server. " [Qin] What does the re-authorization means here? What's the difference between re-authorization and re-authentication? [Qin] Why does the server not maintain the state for Diameter User session in some situation mentioned above? [snip] " 8.3. Server-Initiated Re-Auth A Diameter server may initiate a re-authentication and/or re- authorization service for a particular session by issuing a Re-Auth- Request (RAR). " [Qin] Can you provide some reference as regarding this mechanism? " For example, for pre-paid services, the Diameter server that originally authorized a session may need some confirmation that the user is still using the services. " [Qin] If the security information(e.g., keys) is expired, do we need to depend on Server-Initiated Re-auth to renew the security information? In this case, it seems that the Client also can initiate this Re-auth? " An access device that receives a RAR message with Session-Id equal to a currently active session MUST initiate a re-auth towards the user, if the service supports this particular feature. Each Diameter application MUST state whether service-initiated re-auth is " [Qin]: s/service-initiated/server-initiated " supported, since some applications do not allow access devices to prompt the user for re-auth. " From vfajardo@tari.toshiba.com Thu Jun 18 06:22:20 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D483A6BEB for ; Thu, 18 Jun 2009 06:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0prUrSnLVXev for ; Thu, 18 Jun 2009 06:22:19 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id D82163A6B4C for ; Thu, 18 Jun 2009 06:22:18 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n5IDLpqu019079; Thu, 18 Jun 2009 22:21:51 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n5IDLpKD020714; Thu, 18 Jun 2009 22:21:51 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA20713; Thu, 18 Jun 2009 22:21:51 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n5IDLogb012194; Thu, 18 Jun 2009 22:21:50 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n5IDLocP024206; Thu, 18 Jun 2009 22:21:50 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n5IDLnPY019676; Thu, 18 Jun 2009 22:21:50 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n5IDLmk2022577; Thu, 18 Jun 2009 22:21:48 +0900 (JST) 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 n5IDSIFh011478; Thu, 18 Jun 2009 09:28:18 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4A3A3F6B.804@tari.toshiba.com> Date: Thu, 18 Jun 2009 09:21:47 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Qin Wu References: <016501c9e5c8$9e730dd0$db592970$@net> <031a01c9f000$460eefa0$260ca40a@china.huawei.com> In-Reply-To: <031a01c9f000$460eefa0$260ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 13:22:20 -0000 Hi Qin, Thanks for the review. > Hi, > May I have some comments on draft-ietf-dime-rfc3588bis-17? > > Regards! > -Qin > [snip] > " > 1. Introduction > ............. > Server-initiated messages > > While RADIUS server-initiated messages are defined in [RFC5176], > support is optional. This makes it difficult to implement > features such as unsolicited disconnect or reauthentication/ > reauthorization > " > [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated? > > e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP) > ", EAP Re-authentication is host/peer initiated, isn't it? > So it is not very accurate to say the reauthentcation is server-initiated . > > " > mmm ... the statement above is just giving an example of server-initiated messages. i don't think it stating that re-authz are server-initiated only. > on demand across a heterogeneous deployment. > Support for server-initiated messages is mandatory in > " > [Qin]: The last sentence is not complete. I guess we should say > " > To tackle this issue, support for server-initiated message is mandaroty in Diameter. > " > Ok. > [snip] > " > Peer discovery and configuration > > RADIUS implementations typically require that the name or address > of servers or clients be manually configured, along with the > corresponding shared secrets. This results in a large > administrative burden, and creates the temptation to reuse the > RADIUS shared secret, which can result in major security > vulnerabilities if the Request Authenticator is not globally and > temporally unique as required in [RFC2865]. Through DNS, Diameter > enables dynamic discovery of peers. > " > > [Qin]: In order to align the contents in this paragraph with other paragraphs, the similar anchor point should be appended, i.e., > s/ > " > Diameter enables dynamic discovery of peers. > " > / > " > Diameter enables dynamic discovery of peers (section 5.2). > " > Ok. > [snip] > " > 1.1.1. Description of the Document Set > [snip] > " > The Mobile IPv4 [RFC4004] application defines a Diameter application > that allows a Diameter server to perform AAA functions for Mobile > IPv4 services to a mobile node. > " > [Qin]: Do we need to add some references to Diameter support for Mobile IPv6 > and Diameter support for Proxy Mobile IPv6? > In reference to Glen's comments, I actually would like to trim down this section so that it does not refer to any diameter applications. There are and will be very many diameter applications and I don't think it's useful to iterate them. I think its best just to describe a general relationship of diameter to the transport profile. > [snip] > " > 2.9. Diameter Path Authorization > > As noted in Section 2.2, Diameter provides transmission level > security for each connection using TLS. Therefore, each connection > can be authenticated, replay and integrity protected. > " > [Qin]: In which situation the Diameter Path Authorization will be used? > Diameter Path Authoirzation will be performed between the Diameter Client and server? > or between different Proxys or Relays? What is the main difference between Path authorization and service authorization? > " > path authorization can be performed between any diameter peers (clients, servers, proxy/relay) to verify if they can do what they claim to do; i.e. through authorization cerficates. so path authorization can also deal with validating the application a diameter node supports and possibly its role for that application. AFAIK, service authorization is a concept used within the diameter application itself and is independent of path authorization. > In addition to authenticating each connection, each connection as > well as the entire session MUST also be authorized. Before > initiating a connection, a Diameter Peer MUST check that its peers > are authorized to act in their roles. For example, a Diameter peer > may be authentic, but that does not mean that it is authorized to act > as a Diameter Server advertising a set of Diameter applications. > > Prior to bringing up a connection, authorization checks are performed > at each connection along the path. Diameter capabilities negotiation > (CER/CEA) also MUST be carried out, in order to determine what > Diameter applications are supported by each peer. > " > > [Qin]: What's the relationship between capabilities negotiation and Path Authorization? > Why we mention capability negotation in this section? > see above. we mention it here because the capabilities exchange tells you the applications a peer support and the part of the path authorization helps you verify whether the peer can really do what it claim to do; i.e. through authorization certificates. > [snip] > " > 8. Diameter User Sessions > [snip] > " > An access device that does not expect to send a re-authorization or a > session termination request to the server MAY include the Auth- > Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint > to the server. > " > [Qin] > What does the re-authorization means here? What's the difference between re-authorization and re-authentication? > In this case, re-authorization is tied to a session. if a user is not expected to ask for re-authorization, then the server may not need to keep state. re-authorization and re-authentication are two(2) different concepts ... one deals with policing and the other deals with proving your identity again. > [Qin] > Why does the server not maintain the state for Diameter User session in some situation mentioned above? > see above. > [snip] > " > 8.3. Server-Initiated Re-Auth > > A Diameter server may initiate a re-authentication and/or re- > authorization service for a particular session by issuing a Re-Auth- > Request (RAR). > " > [Qin] Can you provide some reference as regarding this mechanism? > I'm guessing diameter credit-control has server-initiated RAR ... > " > For example, for pre-paid services, the Diameter server that > originally authorized a session may need some confirmation that the > user is still using the services. > " > [Qin] If the security information(e.g., keys) is expired, do we need to depend on > Server-Initiated Re-auth to renew the security information? In this case, it seems > that the Client also can initiate this Re-auth? > Yes the client can perform re-auth in this scenario. The base protocol does not limit what the diameter applications can do. it simply provides a framework for it. > " > An access device that receives a RAR message with Session-Id equal to > a currently active session MUST initiate a re-auth towards the user, > if the service supports this particular feature. Each Diameter > application MUST state whether service-initiated re-auth is > " > [Qin]: s/service-initiated/server-initiated > " > supported, since some applications do not allow access devices to > prompt the user for re-auth. > " > Ok. regards, victor From vfajardo@tari.toshiba.com Thu Jun 18 06:23:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EEF28C32A for ; Thu, 18 Jun 2009 06:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg4xHzlg4oTp for ; Thu, 18 Jun 2009 06:23:01 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 21FE628C327 for ; Thu, 18 Jun 2009 06:23:01 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n5IDNCj7019314; Thu, 18 Jun 2009 22:23:12 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n5IDNCNq021129; Thu, 18 Jun 2009 22:23:12 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA21127; Thu, 18 Jun 2009 22:23:12 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n5IDNCmk012933; Thu, 18 Jun 2009 22:23:12 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n5IDNBlQ021577; Thu, 18 Jun 2009 22:23:11 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n5IDNBYU021013; Thu, 18 Jun 2009 22:23:11 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n5IDN96s022778; Thu, 18 Jun 2009 22:23:10 +0900 (JST) 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 n5IDTeje011486; Thu, 18 Jun 2009 09:29:40 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4A3A3FBD.1030604@tari.toshiba.com> Date: Thu, 18 Jun 2009 09:23:09 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Glen Zorn References: <001201c9ebf7$5e0f72d0$1a2e5870$@net> In-Reply-To: <001201c9ebf7$5e0f72d0$1a2e5870$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WGLC comment on rfc3588bis: section 11 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 13:23:02 -0000 Hi Glen, > Section 11.4, Paragraph 2 says > > IANA [RFC5226] has assigned the range 0x00000001 to 0x00ffffff for > standards-track applications; and 0x01000000 - 0xfffffffe for vendor > specific applications, on a first-come, first-served basis. The > following values are allocated. > > RFC 5226 is not a definition of IANA, it contains guidelines regarding > policies for namespaces managed by the IANA. Suggest changing this to: > > IANA has allocated the range 0x00000001 to 0x00ffffff for > standards-track applications; and 0x01000000 - 0xfffffffe for vendor- > specific applications, on a first-come, first-served basis. The > following values are assigned in this document: > thanks for catching this. > Also, I can't see why the reference to BCP 26 in section 11. isn't > sufficient for the whole section; the constant referencing of RFC 5226 seems > redundant and distracting to me. > Ok. we can clean that up. I'll try posting a new bis version once the last call completes. regards, victor > ~gwz > > Play assigns meaning to human activity--work erases it. > -- P.L. Wilson > > > > > From dromasca@avaya.com Thu Jun 18 09:27:26 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C52128C3FB for ; Thu, 18 Jun 2009 09:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpDCOfoN0coa for ; Thu, 18 Jun 2009 09:27:25 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9930028C142 for ; Thu, 18 Jun 2009 09:27:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,245,1243828800"; d="scan'208";a="174369492" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Jun 2009 12:27:37 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Jun 2009 12:27:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 18:27:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-diameter-api in AD-Follow-Up Thread-Index: AcnwHouYJplfBRLsQSaM0SGnNTIgOgAEnJsw From: "Romascanu, Dan (Dan)" To: Subject: [Dime] draft-ietf-dime-diameter-api in AD-Follow-Up X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 16:27:26 -0000 =20 The IESG did not approve in the telechat today draft-ietf-dime-diameter-api.=20 There are several DISCUSSes on this I-D, but the most fundamental question was asked by Pasi Eronen. Pasi questions whether the publication of this document is useful at all, and suggests publication as Historic or no publication as possible options.=20 Pasi writes:=20 > The writeup mentions there being two implementations, but apparently both of them are prototype code from around 2001 that have been abandoned >5 years ago. OpenDiameter (an open source Diameter implementation by the main author of this draft) does not use this API, and to me it looks very unlikely that anyone would ever implement this (and it's questionable whether anyone should even attempt). I would like to get feedback from the authors and the WG. Is the document useful? If yes, for what? Who will use it? Do today's implementations and deployments follow the API that this document describes? Dan From sunseawq@huawei.com Sat Jun 20 20:32:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E1B3A68D0 for ; Sat, 20 Jun 2009 20:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K25DCeAfe0OK for ; Sat, 20 Jun 2009 20:32:58 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E2BDE3A67D4 for ; Sat, 20 Jun 2009 20:32:57 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLK004VHKJAPR@szxga03-in.huawei.com> for dime@ietf.org; Sun, 21 Jun 2009 11:33:10 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLK00DK8KJAK1@szxga03-in.huawei.com> for dime@ietf.org; Sun, 21 Jun 2009 11:33:10 +0800 (CST) Received: from 756BFB16836341A ([221.6.45.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLK000YSKJ966@szxml01-in.huawei.com>; Sun, 21 Jun 2009 11:33:10 +0800 (CST) Date: Sun, 21 Jun 2009 11:33:19 +0800 From: Qin Wu To: Victor Fajardo Message-id: <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <016501c9e5c8$9e730dd0$db592970$@net> <031a01c9f000$460eefa0$260ca40a@china.huawei.com> <4A3A3F6B.804@tari.toshiba.com> Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 03:32:59 -0000 Hi, Vicotor: Thank for your feedback. I have a few more followup comments below, Please see inline. Regards! -Qin ----- Original Message ----- From: "Victor Fajardo" To: "Qin Wu" Cc: Sent: Thursday, June 18, 2009 9:21 PM Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 > Hi Qin, > > Thanks for the review. >> [snip] >> " >> 1. Introduction >> ............. >> Server-initiated messages >> >> While RADIUS server-initiated messages are defined in [RFC5176], >> support is optional. This makes it difficult to implement >> features such as unsolicited disconnect or reauthentication/ >> reauthorization >> " >> [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated? >> > > >> e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP) >> ", EAP Re-authentication is host/peer initiated, isn't it? >> So it is not very accurate to say the reauthentcation is server-initiated . >> >> " >> > > mmm ... the statement above is just giving an example of > server-initiated messages. i don't think it stating that re-authz are > server-initiated only. [Qin]: As described in draft-ietf-dime-rfc3588bis-17, " This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization " It seems reauthentication/reauthorization is a generic feature used here which, I am afraid, does not include EAP re-authentification case described in RFC5296. In this sense, I would like to suggest reword as: " This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization for Credit control. " [snip] >> " >> 8.3. Server-Initiated Re-Auth >> >> A Diameter server may initiate a re-authentication and/or re- >> authorization service for a particular session by issuing a Re-Auth- >> Request (RAR). >> " >> [Qin] Can you provide some reference as regarding this mechanism? >> > > I'm guessing diameter credit-control has server-initiated RAR ... [Qin] Does it seem confusion to use the terminology "Re-Auth" in Credit Control which conflicts with the terminology "Re authentication" used in the RFC5296 or Diameter Re-authentication WG draft? i.e, Does Re-auth in Credit control has the same meaning as the Re-auth in the EAP reauthentication described in the RFC5296? >> " >> For example, for pre-paid services, the Diameter server that >> originally authorized a session may need some confirmation that the >> user is still using the services. >> " >> [Qin] If the security information(e.g., keys) is expired, do we need to depend on >> Server-Initiated Re-auth to renew the security information? In this case, it seems >> that the Client also can initiate this Re-auth? >> > > Yes the client can perform re-auth in this scenario. The base protocol > does not limit what the diameter applications can do. it simply provides > a framework for it. [Qin] As you mentioned above, the credit-control has server-initiated RAR, it seems the server-initiated RAR has different meaning from what I examplified above, hasn't it? > regards, > victor > > From Lothar.Reith@detecon.com Sun Jun 21 14:54:04 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B3B3A6C5D; Sun, 21 Jun 2009 14:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N6QM+Z6gY+v; Sun, 21 Jun 2009 14:54:03 -0700 (PDT) Received: from dtc034.detecon.net (dtc034.detecon.net [194.25.60.134]) by core3.amsl.com (Postfix) with ESMTP id 429E53A6A4D; Sun, 21 Jun 2009 14:54:01 -0700 (PDT) Received: from unknown (HELO dc00357.detecon.com) ([172.16.10.107]) by relay.dtc034.detecon.net with ESMTP; 21 Jun 2009 23:54:14 +0200 Received: from DC00331.detecon.com ([172.16.10.78]) by dc00357.detecon.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Jun 2009 23:54:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Jun 2009 23:54:06 +0200 Message-ID: In-reply-to: <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard Thread-Index: AcnyIyBlhwCA0wyYT8+j1vTCsLFDMAAlEIgQ References: <016501c9e5c8$9e730dd0$db592970$@net><031a01c9f000$460eefa0$260ca40a@china.huawei.com><4A3A3F6B.804@tari.toshiba.com> <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> From: "Reith, Lothar" To: X-OriginalArrivalTime: 21 Jun 2009 21:54:14.0726 (UTC) FILETIME=[D15ECE60:01C9F2BA] Cc: iesg-secretary@ietf.org Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 21:54:04 -0000 =20 Dear all, please find below a list of comments regarding the Last Call on: = draft-ietf-dime-qos-attributes (Quality of Service Attributes for = Diameter) to Proposed Standard Where applicable, I have stated the issue and a proposed solution to fix = the issue. 1. issue: in Section 3.1 it is stated that "QoS Resources AVP .......describes a list of policies"=20 however, the ABNF definition in the line below specifies that the QoS = Resource AVP contains a list of QoS-Rules.=20 proposed solution: replace "describes a list of policies" by "contains = a list of QoS-Rules" Background: The question is if the term policies and QoS-Rules are meant synonymous = in the context of the document. If that is the case, I suggest to = replace the term "policies" with "Qos-Rules", as it is the only = occurance of that term within the document. If that is not the case, = the meaning of the term policy in this document needs be defined, given = that the term "policy" is somewhat overloaded. For example, one could = define, that the terms "policy" and "QoS-Rule" are being used = synonymously in the context of the document, except when referring to = RFC5226 as a policy. Or one could state that a "QoS-Rule" is a type of = "policy".=20 Alternative Solution: replace "describes a list of policies" by = "contains a list of policy rules"=20 2. issue: section 4.1.8.23 discusses Ethernet "user-priority". I would = recommend to review with IEEE on this to verify if "user-priority" or = "P-bits" would be the most appropriate term. In addition, there seems to = no consideration yet for the "drop eligibility indicator" contained in = an S-Tag with Ethertype 0x88a8. It should be possible to formulate a = QoS-Rule which considers the "drop eligibility indicator". Also it = should be possible to formulate a mark action, which sets the value of = the "drop eligibility indicator" bit to 1. Along these lines, it should = also be possible to formulate a QoS-Rule which considers MPLS EXP Bits = of an incoming packet. And it should be possible to mark MPLS EXP bits. 3. issue in section 4.2.1: charging granularity not compliant with = consumer protection legislation (at least in Germany) Proposed Solution: I would recommend to multiply the values by 10, in = order to arrive at a granularity of one tenth of a second = (split-second). This would allow to comply with some consumer protection = regulations in the area of charging accuracy, such as a = "telecommunication customer protection law" effective in Germany. I know = of one voice switch vendor, who had to reprogramm his voice-switch = accounting software because of that law, as a metering granularity of = one second was not good enough to meet the legal demands in all cases. = This was due to the possible errors in measuring the time at the start = of a call and at the end of a call could add up to more than one second, = even though the time measurement itself had a granularity of one second. = As a minimum, the range must be doubled to a measurement granularity of = a half-second, in order to be on the safe side regarding compliance with = this law. 4.issues in section 5.1 the actions drop, shape and mark may require = some further scrutiny and refinement 4.1 Issue regarding the drop action: Drop action does not differentiate, = if the dropped packet shall get accounted. one possible solution (not necessary the proposed solution): = differentiate between - drop without counting, i.e. drop without charging for the delivery to = the point, where the packet gets dropped, because the packet did not get = delivered to the customer, such as discarding unsolicited out of profile = downstream traffic from some source in the Internet. - drop after counting, i.e. drop with charging for the delivery of the = packet to the point where it got discarded (if legally allowed). This = may be applicable to out of profile upstream traffic. 4.2 Issue regarding a lack of unambiguity of the definition of the shape = action: - shape to which token bucket size and depletion rate? - which bytes of the incoming packet count for depleting the token = bucket? All bytes of the layer 2 Frame in case of a QoS-Rule at the = Ethernet layer, where an IP header may not even be present? In this = context: Is the term bandwidth in the "bandwidth AVP" defined as "net = data rate" as in ANCP, or differently defined or undefined?=20 4.3. Issue regarding the completeness of the scope of the mark action: - only TOS byte, or also MPLS EXP bits and Ethernet P-bits ? - only absolute mark, or also remarking rule that depends on the = previous setting the field? Proposed solution regarding the first item: split the mark action into 3 = different mark actions, mark-TOS byte, mark-MPLS_EXP-bit and = mark-P-bits. Consider to allow the presence of multiple mark actions in = a single QoS-Rule.=20 Proposed solution regarding the second item: Add actions for re-mark-TOS = byte, re-mark-MPLS_EXP-bit and re-mark-P-bits, where the result of the = re-mark-action depends on the former setting of the field being = re-marked. 5. Issue in section 5.4 I do not quite understand the semantic = differences between QoS Available, QoS Authorized and QoS Reserved, in = particular if QoS Reserved is already accounting relevant.=20 Solution: Verify and make sure that there is indeed a semantic = difference, and that accounting for QoS Reserved is compliant with = consumer protection laws. 6. issue in section 7.5 there is an example on how this may apply in = combination with Diameter Credit Control, and it is stated there that " = In this case the User is charged as soon as the Service Element (CC = client) receives the service request. " Proposed solution: Verify if a procedure which starts charging without = knowing, if the the QoS-Resource can actually be allocated does not = violate consumer protection laws. 7. reading further on in this short section 7.5 it states the following: "In this case the client uses the "QoS-Desired" QoS-Semantics parameter = in the QoS-Resources AVP that it sends to the Accounitng server. The = server responds with a "QoS-Available" QoS-Semantics parameter in the = QoS-Resources AVP" This raises some doubts if the "accounting server" acts as an = authorization server. There should be clear separation of accounting and = authorization. Proposed solution: Change the wording to make clear, that the accounting = server does not authorize anything, otherwise, do not call it an = accounting server, but rather an authorization and accounting server, = which would imply that both functions are combined in one server (which = in large implementations is usually not the case).=20 8. reading further on, there is a Message shown "CCA (Granted-Units, = QoS-Resources(QoS-Authorized))" which makes me wonder, what is being = authorized here with DCC. Is it an authorization for a certain number of = granted-Units delivered with a higher QoS and charged extra using a one = time charge because of delivering these granted units with higher QoS? If that would be the case, it would in my view be a bad practice, as = the one-time charge mechanism would effectively be used for session = based charging, but without the reservation mechanism. What happens, if = the Granted-Units cannot be delivered with the higher QoS, say in case = of an outage? Session based charging can handle this by means of not = confirming the reservation within a time limit. It would require extra = complex logic to handle this situation, where the One-Time charge would = have to be cancelled or compensated by a one-time bonus of same amount. Proposed solution for issue 8: Use another example, which does not = suggest to re-invent session based online charging using one-time = charging events. Best Regards, Lothar Reith Competence Practice Communications Technology Detecon International GmbH=A0 Oberkasseler Str. 2=A0 53227 Bonn - Germany =A0 Phone:=A0+49 228 700 2958 Mobile: +49 175 580 4892 Fax: +49 228 700 2107 mailto:lothar.reith@detecon.com=20 http://www.detecon.com=20 Detecon International GmbH Aufsichtsrat: Hans-J=FCrgen Wickenh=F6fer (acting) Gesch=E4ftsf=FChrung: Dr. Klaus Hofmann, Andreas Baumann Handelsregister: Amtsgericht Bonn HRB 2093 Sitz der Gesellschaft: Bonn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Dime]Last Call: draft-ietf-dime-qos-attributes (Quality of Service = Attributes for Diameter) to Proposed Standard * To: IETF-Announce * Subject: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality = of Service Attributes for Diameter) to Proposed Standard * From: The IESG * Date: Mon, 8 Jun 2009 07:08:51 -0700 (PDT) * Cc: dime at ietf.org * Delivered-to: dime at core3.amsl.com * List-archive: * List-help: * List-id: Diameter Maintanence and Extentions Working Group = * List-post: * List-subscribe: , = * List-unsubscribe: , = * Reply-to: ietf at ietf.org The IESG has received a request from the Diameter Maintenance and=20 Extensions WG (dime) to consider the following document: - 'Quality of Service Attributes for Diameter ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2009-06-22. Exceptionally,=20 comments may be sent to iesg at ietf.org instead. In either case, please = retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-12.txt= IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D16192&rfc_flag=3D0 * Prev by Date: [Dime] WGLC Comments on = draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20 * Next by Date: Re: [Dime] New draft for Diameter ERP: poll for = adoption * Previous by thread: [Dime] WGLC Comments on = draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20 * Next by thread: [Dime] Fwd: New Version Notification for = draft-korhonen-dime-mip6-feature-bits-01 * Index(es): o Date o Thread Note: Messages sent to this list are the opinions of the senders and do = not imply endorsement by the IETF.=20 From vfajardo@tari.toshiba.com Mon Jun 22 06:46:48 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A363A67D2 for ; Mon, 22 Jun 2009 06:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo3QYLRGxbao for ; Mon, 22 Jun 2009 06:46:47 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 159CC3A67F2 for ; Mon, 22 Jun 2009 06:46:46 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n5MDkVL0020869; Mon, 22 Jun 2009 22:46:31 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n5MDkU3a003433; Mon, 22 Jun 2009 22:46:30 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA03432; Mon, 22 Jun 2009 22:46:30 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n5MDkU9f020161; Mon, 22 Jun 2009 22:46:30 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n5MDkUub006001; Mon, 22 Jun 2009 22:46:30 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n5MDkTx3025337; Mon, 22 Jun 2009 22:46:29 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n5MDkScu023349; Mon, 22 Jun 2009 22:46:29 +0900 (JST) 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 n5MDqj2G027319; Mon, 22 Jun 2009 09:52:46 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4A3F8B32.3020205@tari.toshiba.com> Date: Mon, 22 Jun 2009 09:46:26 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Qin Wu References: <016501c9e5c8$9e730dd0$db592970$@net> <031a01c9f000$460eefa0$260ca40a@china.huawei.com> <4A3A3F6B.804@tari.toshiba.com> <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> In-Reply-To: <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 13:46:48 -0000 Hi Qin, Thanks. Comments inline: > Hi, Vicotor: > Thank for your feedback. I have a few more followup comments below, Please see inline. > > Regards! > -Qin > ----- Original Message ----- > From: "Victor Fajardo" > To: "Qin Wu" > Cc: > Sent: Thursday, June 18, 2009 9:21 PM > Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 > > > >> Hi Qin, >> >> Thanks for the review. >> >>> [snip] >>> " >>> 1. Introduction >>> ............. >>> Server-initiated messages >>> >>> While RADIUS server-initiated messages are defined in [RFC5176], >>> support is optional. This makes it difficult to implement >>> features such as unsolicited disconnect or reauthentication/ >>> reauthorization >>> " >>> [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated? >>> >>> >> >>> e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP) >>> ", EAP Re-authentication is host/peer initiated, isn't it? >>> So it is not very accurate to say the reauthentcation is server-initiated . >>> >>> " >>> >>> >> mmm ... the statement above is just giving an example of >> server-initiated messages. i don't think it stating that re-authz are >> server-initiated only. >> > [Qin]: As described in draft-ietf-dime-rfc3588bis-17, > " > This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization > " > It seems reauthentication/reauthorization is a generic feature used here which, I am afraid, does not include EAP re-authentification case > described in RFC5296. In this sense, I would like to suggest reword as: > " > This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization for Credit control. > " > I'm not sure I fully understand. Do you mean you don't want a generic statement because it would not include EAP ? I was thinking the opposite. A generic statement would encompass a broader scope right ? > [snip] > > >>> " >>> 8.3. Server-Initiated Re-Auth >>> >>> A Diameter server may initiate a re-authentication and/or re- >>> authorization service for a particular session by issuing a Re-Auth- >>> Request (RAR). >>> " >>> [Qin] Can you provide some reference as regarding this mechanism? >>> >>> >> I'm guessing diameter credit-control has server-initiated RAR ... >> > > [Qin] > Does it seem confusion to use the terminology "Re-Auth" in Credit Control which conflicts with > the terminology "Re authentication" used in the RFC5296 or Diameter Re-authentication WG draft? > i.e, Does Re-auth in Credit control has the same meaning as the Re-auth in the EAP reauthentication described in the RFC5296? > I'm not too sure about the history for Diameter CC nor the reasoning for its terminology. I guess the more pertinent question is how this relates to bis. At least for bis the term "Re-Auth" can indicate authorization and/or authentication. > >>> " >>> For example, for pre-paid services, the Diameter server that >>> originally authorized a session may need some confirmation that the >>> user is still using the services. >>> " >>> [Qin] If the security information(e.g., keys) is expired, do we need to depend on >>> Server-Initiated Re-auth to renew the security information? In this case, it seems >>> that the Client also can initiate this Re-auth? >>> >>> >> Yes the client can perform re-auth in this scenario. The base protocol >> does not limit what the diameter applications can do. it simply provides >> a framework for it. >> > > [Qin] As you mentioned above, the credit-control has server-initiated RAR, it seems the > server-initiated RAR has different meaning from what I examplified above, hasn't it? > Ok. Then I'm not really sure what your comparing re-auth againts. Are you comparing client vs. server re-auth ? In that case, is there anything broken in the bis that relates to this ? regards, victor From sdecugis@nict.go.jp Tue Jun 23 00:34:30 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CBF3A6E41 for ; Tue, 23 Jun 2009 00:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.213 X-Spam-Level: X-Spam-Status: No, score=-0.213 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_05=-1.11, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVf8hC8tTTZe for ; Tue, 23 Jun 2009 00:34:29 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 86C783A6922 for ; Tue, 23 Jun 2009 00:34:28 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n5N7YRdB026435; Tue, 23 Jun 2009 16:34:27 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n5N7YR47028965; Tue, 23 Jun 2009 16:34:27 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n5N7YRMS028961; Tue, 23 Jun 2009 16:34:27 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1CDE31647D; Tue, 23 Jun 2009 16:34:27 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1585E1646D; Tue, 23 Jun 2009 16:34:27 +0900 (JST) Message-ID: <4A408565.6000106@nict.go.jp> Date: Tue, 23 Jun 2009 16:33:57 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-diameter-api in AD-Follow-Up X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 07:34:30 -0000 Hello, > I would like to get feedback from the authors and the WG. Is the > document useful? If yes, for what? Who will use it? Do today's > implementations and deployments follow the API that this document > describes? > As far as I am concerned, I don't follow this API in my implementation. I studied the API when I started this work and came to the conclusion that it is not appropriate for general-purpose implementations (not easy to implement agents functions for example). Anyway, people with different requirements might find it useful for other situations. I personally believe that this API can only be used for "simple" client-sides of applications, but I may be mistaken. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Tue Jun 23 00:51:06 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272313A68A5 for ; Tue, 23 Jun 2009 00:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLP15bro48LE for ; Tue, 23 Jun 2009 00:51:05 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E2C243A63EC for ; Tue, 23 Jun 2009 00:51:04 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLO00DOFLR6D4@szxga04-in.huawei.com> for dime@ietf.org; Tue, 23 Jun 2009 15:49:54 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLO007WULR606@szxga04-in.huawei.com> for dime@ietf.org; Tue, 23 Jun 2009 15:49:54 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLO00FLALR53K@szxml06-in.huawei.com> for dime@ietf.org; Tue, 23 Jun 2009 15:49:54 +0800 (CST) Date: Tue, 23 Jun 2009 15:49:53 +0800 From: Qin Wu To: Victor Fajardo Message-id: <04ea01c9f3d7$322df280$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <016501c9e5c8$9e730dd0$db592970$@net> <031a01c9f000$460eefa0$260ca40a@china.huawei.com> <4A3A3F6B.804@tari.toshiba.com> <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> <4A3F8B32.3020205@tari.toshiba.com> Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 07:51:06 -0000 Hi, Victor: Please see inline. ----- Original Message ----- From: "Victor Fajardo" To: "Qin Wu" Cc: Sent: Monday, June 22, 2009 9:46 PM Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 > Hi Qin, > > Thanks. Comments inline: > >> Hi, Vicotor: >> Thank for your feedback. I have a few more followup comments below, Please see inline. >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Victor Fajardo" >> To: "Qin Wu" >> Cc: >> Sent: Thursday, June 18, 2009 9:21 PM >> Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 >> >> >> >>> Hi Qin, >>> >>> Thanks for the review. >>> >>>> [snip] >>>> " >>>> 1. Introduction >>>> ............. >>>> Server-initiated messages >>>> >>>> While RADIUS server-initiated messages are defined in [RFC5176], >>>> support is optional. This makes it difficult to implement >>>> features such as unsolicited disconnect or reauthentication/ >>>> reauthorization >>>> " >>>> [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated? >>>> >>>> >>> >>>> e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP) >>>> ", EAP Re-authentication is host/peer initiated, isn't it? >>>> So it is not very accurate to say the reauthentcation is server-initiated . >>>> >>>> " >>>> >>>> >>> mmm ... the statement above is just giving an example of >>> server-initiated messages. i don't think it stating that re-authz are >>> server-initiated only. >>> >> [Qin]: As described in draft-ietf-dime-rfc3588bis-17, >> " >> This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization >> " >> It seems reauthentication/reauthorization is a generic feature used here which, I am afraid, does not include EAP re-authentification case >> described in RFC5296. In this sense, I would like to suggest reword as: >> " >> This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization for Credit control. >> " >> > > > I'm not sure I fully understand. Do you mean you don't want a generic > statement because it would not include EAP ? I was thinking the > opposite. A generic statement would encompass a broader scope right ? [Qin]: Surely we need the generic statement here. However as described in the section 5.5 of RFC4006, the reauthentication/ reauthorization mentioned in the section 8.3 of draft-ietf-dime-rfc3588bis-17 is initiated by the server and only applicable for real-time credit control and can not be applicable for EAP Re-authentication described in RFC5296 or Diameter Support for EAP Re-authentication Protocol. Because EAP Re-authentication is initiated by the Client/Peer. That's my difficulty. What am I missing? >> [snip] >> >> >>>> " >>>> 8.3. Server-Initiated Re-Auth >>>> >>>> A Diameter server may initiate a re-authentication and/or re- >>>> authorization service for a particular session by issuing a Re-Auth- >>>> Request (RAR). >>>> " >>>> [Qin] Can you provide some reference as regarding this mechanism? >>>> >>>> >>> I'm guessing diameter credit-control has server-initiated RAR ... >>> >> >> [Qin] >> Does it seem confusion to use the terminology "Re-Auth" in Credit Control which conflicts with >> the terminology "Re authentication" used in the RFC5296 or Diameter Re-authentication WG draft? >> i.e, Does Re-auth in Credit control has the same meaning as the Re-auth in the EAP reauthentication described in the RFC5296? >> > > I'm not too sure about the history for Diameter CC nor the reasoning for > its terminology. I guess the more pertinent question is how this relates > to bis. At least for bis the term "Re-Auth" can indicate authorization > and/or authentication. [Qin]: I agree. However the "Re-Auth" is also used in the Diameter Support for EAP Re-authentication Protocol. It seems they have different meanings and scope. >>>> " >>>> For example, for pre-paid services, the Diameter server that >>>> originally authorized a session may need some confirmation that the >>>> user is still using the services. >>>> " >>>> [Qin] If the security information(e.g., keys) is expired, do we need to depend on >>>> Server-Initiated Re-auth to renew the security information? In this case, it seems >>>> that the Client also can initiate this Re-auth? >>>> >>>> >>> Yes the client can perform re-auth in this scenario. The base protocol >>> does not limit what the diameter applications can do. it simply provides >>> a framework for it. >>> >> >> [Qin] As you mentioned above, the credit-control has server-initiated RAR, it seems the >> server-initiated RAR has different meaning from what I examplified above, hasn't it? >> > > Ok. Then I'm not really sure what your comparing re-auth againts. Are > you comparing client vs. server re-auth ? In that case, is there > anything broken in the bis that relates to this ? [Qin]: See above. Since Re-authentication is defined in the credit control in the RFC 4006, I am just confused if the same terms"Re-authentication" is used in the Diameter ERP as well If the folks have no difficulty to distinguish the Re-authentication in the Diameter ERP from the Reauthentication in the Credit control application, then I have no strong feeling against it. If my understanding is not right, please correct me. > regards, > victor > From sdecugis@nict.go.jp Tue Jun 23 01:33:36 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498E73A6C34 for ; Tue, 23 Jun 2009 01:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SonB8eeMKKeX for ; Tue, 23 Jun 2009 01:33:33 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 23AFF3A6B1F for ; Tue, 23 Jun 2009 01:33:32 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n5N8XhX7024771; Tue, 23 Jun 2009 17:33:43 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n5N8Xh6P012702; Tue, 23 Jun 2009 17:33:43 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n5N8Xh84012699; Tue, 23 Jun 2009 17:33:43 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 9299E1648E; Tue, 23 Jun 2009 17:33:43 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 8BA191648A; Tue, 23 Jun 2009 17:33:43 +0900 (JST) Message-ID: <4A409349.8030808@nict.go.jp> Date: Tue, 23 Jun 2009 17:33:13 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Julien Bournelle References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> In-Reply-To: <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 08:33:36 -0000 Hello Julien, Please find my answers inline. > > This document specifies how Diameter is used to carry the re- > > authentication exchange (second step). For this purpose, we define a > > new Application Id for ERP, and re-use the Diameter EAP commands > > (DER/DEA). > > We need a justification here. Do you mean a justification for defining a new application ID? > > We also discuss the key distribution (first step, bootstrapping) and > > propose some solutions for different architectures. Anyway, > > implementors are free to choose a different mechanism for key > > distribution, as for example using RADIUS [I-D.ietf-hokey-key-mgm]. > > Rafa sent an email on this draft and I agree with him i.e. the draft > should > not mention RADIUS, only AAA. I also agree with this proposed change. If the referenced draft is updated, then this sentence will have to be rewritten accordingly, for example as: "We also discuss the key distribution (first step, bootstrapping) and propose some solutions for different architectures, following the principles of [I-D.ietf-hokey-key-mgm]. Anyway, implementors are free to choose a different mechanism for key distribution." Of course, we might choose to restrict the choice on the key distribution mechanism if people think it is better. > > This simplifies the routing of Diameter messages to the > > appropriate server, and allows more flexibility in the deployment of > > ERP. > > in which scenario does it simplify the routing process ? in case of > HO to a new authenticator ? > If this is the case, I don't really understand how it solves the > problem because we may have deployed > 2 ERPs servers. It was presented during Virtual Interim meeting last February. You can still find the slides there: http://trac.tools.ietf.org/wg/dime/trac/attachment/wiki/ConferenceBridge/diameter-erp.pdf The advantages of a separate Diameter application ID are highlighted in slide #8. > > The scope of previous documents ([I-D.ietf-dime-erp] and > > [I-D.wu-dime-local-keytran]) was focused on the bootstrapping of the > > mechanism. > > this is not really true. The goal of our document was to define how > to use Diameter > for ERP for bootstrapping and reauthentication. That is right, and I simplified too much the phrasing in the new draft, sorry. The general guidelines are exposed in the "Protocol overview" section. Anyway, there is no consideration about the message routing and Diameter deployment. This is what I wanted to express. For example, after a first re-authentication, the message is sent with local Destination-Realm and EAP application, but it must reach the ER local server. I know that this was in the scope of the document (and in the todo-list), but it was just missing in the current version. Anyway, if this new design for Diameter ERP is to be accepted, this section would disappear when the document becomes the WG document. > > In particular, these documents did not consider the > > routing of Diameter message for re-authentication exchanges (ERP > > exchange, and also [RFC4187] for the second document). By re-using > > the Diameter EAP application, they create implicit constraints on > > routing of messages that cannot be met by standard Diameter routing > > algorithm, as defined in the Diameter Base Protocol [RFC3588]. > > > > A separate Diameter application solves this routing issue, and can > > also allow the authenticator to dynamically discover if the local > > domain supports re-authentication or not. > > I think that it is important to highlight what was the issue and how the > Application-Id solve it. I don't think that we can go in this new > direction > without a clear understanding of the issue and of course of the proposed > solution. > > So, could you send an email explaining the Issue and the proposed > solution ? Do the slides of the Interim meeting answer your questions? Otherwise, I can try to re-summarize all the discussion in a new mail if needed. I thought that the routing issue was already accepted, but I realize now that it does not seem to be the case... Do you think this discussion should be written in the draft? I was not sure if the RFC(-to-be) is a right place for design discussions... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From dromasca@avaya.com Tue Jun 23 02:17:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54BCB3A68AB for ; Tue, 23 Jun 2009 02:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCY-n3o7jT9W for ; Tue, 23 Jun 2009 02:17:56 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C9AD43A6AFE for ; Tue, 23 Jun 2009 02:17:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,274,1243828800"; d="scan'208";a="174765071" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Jun 2009 05:18:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Jun 2009 05:18:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2009 11:17:50 +0200 Message-ID: In-Reply-To: <4A408565.6000106@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-diameter-api in AD-Follow-Up thread-index: Acnz1RP1+oWld6MoRHuh379nnBsbYQADle1g References: <4A408565.6000106@nict.go.jp> From: "Romascanu, Dan (Dan)" To: "Sebastien Decugis" Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-diameter-api in AD-Follow-Up X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 09:17:58 -0000 Thank you, Sebastien.=20 Other opinions?=20 Dan =20 > -----Original Message----- > From: Sebastien Decugis [mailto:sdecugis@nict.go.jp]=20 > Sent: Tuesday, June 23, 2009 10:34 AM > To: Romascanu, Dan (Dan) > Cc: dime@ietf.org > Subject: Re: [Dime] draft-ietf-dime-diameter-api in AD-Follow-Up >=20 > Hello, >=20 > > I would like to get feedback from the authors and the WG. Is the=20 > > document useful? If yes, for what? Who will use it? Do today's=20 > > implementations and deployments follow the API that this document=20 > > describes? > > =20 > As far as I am concerned, I don't follow this API in my=20 > implementation. > I studied the API when I started this work and came to the=20 > conclusion that it is not appropriate for general-purpose=20 > implementations (not easy to implement agents functions for=20 > example). Anyway, people with different requirements might=20 > find it useful for other situations. I personally believe=20 > that this API can only be used for "simple" > client-sides of applications, but I may be mistaken. >=20 > Best regards, > Sebastien. >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 >=20 From Wolfgang.Steigerwald@t-systems.com Tue Jun 23 03:44:07 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341883A6A9A for ; Tue, 23 Jun 2009 03:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIuOi41ZzRwC for ; Tue, 23 Jun 2009 03:44:06 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 6A6633A6E99 for ; Tue, 23 Jun 2009 03:43:57 -0700 (PDT) From: Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 23 Jun 2009 12:43:48 +0200 Received: from S4DE9JSAANH.ost.t-com.de ([10.125.177.222]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 12:43:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 23 Jun 2009 12:43:48 +0200 Message-ID: <5DB86FE558C707408F58C3772801C2CA993E5B@S4DE9JSAANH.ost.t-com.de> In-reply-to: <3D3C75174CB95F42AD6BCC56E5555B4501711EDC@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] HUM regarding draft-tsou-dime-realm-based-redirect-00.txt Thread-Index: AcnrINsCKkzvXRhiR12SCJLJN+1dFQIQoIgg References: <3D3C75174CB95F42AD6BCC56E5555B4501711EDC@FIESEXC015.nsn-intra.net> To: X-OriginalArrivalTime: 23 Jun 2009 10:43:48.0524 (UTC) FILETIME=[7D82FEC0:01C9F3EF] Cc: dime@ietf.org Subject: Re: [Dime] HUM regarding draft-tsou-dime-realm-based-redirect-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 10:44:07 -0000 Hi Hannes, I think the theme is interesting, so I'm in favor for the draft. As far as I understood the propost solution I see some problems - discovery of the diameter node - which security problems occures if requests can be send to a specific = realm Regards Wolfgang >-----Urspr=FCngliche Nachricht----- >Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im=20 >Auftrag von Tschofenig, Hannes (NSN - FI/Espoo) >Gesendet: Freitag, 12. Juni 2009 07:45 >An: dime@ietf.org >Betreff: [Dime] HUM regarding=20 >draft-tsou-dime-realm-based-redirect-00.txt > >Hi all,=20 > >Tina had been repeately been asking whether the functionality=20 >of realm-based redirect can become a chartered working group=20 >item. Now, an independent I-D describing the problem and the=20 >solution is available, see "Realm-Based Redirection In Diameter": >http://www.ietf.org/internet-drafts/draft-tsou-dime-realm-based >-redirect >-00.txt > >Please let us know whether you would want=20 >draft-tsou-dime-realm-based-redirect-00.txt to become a=20 >working group item in DIME or whether you have objections.=20 > >Deadline: June 26th.=20 > >Ciao >Hannes & Victor > >PS: Comments to the draft are also welcome! >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From frascone@gmail.com Tue Jun 23 05:24:07 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0CA3A6999 for ; Tue, 23 Jun 2009 05:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTclkKzsSqxQ for ; Tue, 23 Jun 2009 05:24:06 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 7F69B28C2DE for ; Tue, 23 Jun 2009 05:23:42 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id d26so3958eyd.31 for ; Tue, 23 Jun 2009 05:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=mYjuE5wybwnl8uNS9xvpG/1ZgOLTVRnQWtIoIO9E/AQ=; b=bltwsmB2nAC4hh1TlyLEV6ruSDS+i7KLEH6/QPklzA44P29iZrlB43fVxSMaf3G3Kr tDkw77QEVZMEZr7IT6fMyIJ+JEwzKSS1rV42Cq6xhWMmO6fKFgel6DuDLygugY45jIFB X10ZjCpYTNsap6F8RfLj2jipE5v1rwasTYn2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=THaSbVtjJJBmKxC+rlH5/IfVz6HuKyKLGGYYOxlHI3ptMQCCbfABlkyPPykbKTyBk2 xlRT5NmkZjn0feP624JrVst0gvBS2fSy5D/HJIVraea80QnJ89UkJY2qUE0W9fQQo0C5 Jpg9ABXdfOobVenKqQNDH5IMtT/DJ0aEZ4a1I= MIME-Version: 1.0 Sender: frascone@gmail.com Received: by 10.216.72.85 with SMTP id s63mr8406wed.0.1245759835483; Tue, 23 Jun 2009 05:23:55 -0700 (PDT) In-Reply-To: References: <4A408565.6000106@nict.go.jp> Date: Tue, 23 Jun 2009 08:23:55 -0400 X-Google-Sender-Auth: c30e28812dc5fb8a Message-ID: <9cf5ced20906230523i42cac3dep64a004e94fdccde5@mail.gmail.com> From: David Frascone To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-diameter-api in AD-Follow-Up X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 12:24:07 -0000 The API was derived from the Sun implementation of a diameter stack. They had released the stack for applications developers to write applications, using the API. So, while there may be compilation errors in the draft -- the API does (or did) exist, and was functional. However, I do not think the Sun implementation has been kept up to date. I can not find it, even on their research site. So, as a biased author :) , I do still think there is some benefit in the API. I think it is an example of how a diameter application can be implemented, even with a closed-source stack. Since it is C, it is lightweight, and could probably be used on embedded devices. But, since it seems that the only working implementation is no longer available, I would certainly understand it if the WG decides not to pursue the API further. Just my $.02 worth, -Dave On Tue, Jun 23, 2009 at 5:17 AM, Romascanu, Dan (Dan) wrote: > Thank you, Sebastien. > > Other opinions? > > Dan > > >> -----Original Message----- >> From: Sebastien Decugis [mailto:sdecugis@nict.go.jp] >> Sent: Tuesday, June 23, 2009 10:34 AM >> To: Romascanu, Dan (Dan) >> Cc: dime@ietf.org >> Subject: Re: [Dime] draft-ietf-dime-diameter-api in AD-Follow-Up >> >> Hello, >> >> > I would like to get feedback from the authors and the WG. Is the >> > document useful? If yes, for what? Who will use it? Do today's >> > implementations and deployments follow the API that this document >> > describes? >> > >> As far as I am concerned, I don't follow this API in my >> implementation. >> I studied the API when I started this work and came to the >> conclusion that it is not appropriate for general-purpose >> implementations (not easy to implement agents functions for >> example). Anyway, people with different requirements might >> find it useful for other situations. I personally believe >> that this API can only be used for "simple" >> client-sides of applications, but I may be mistaken. >> >> Best regards, >> Sebastien. >> >> -- >> Sebastien Decugis >> Research fellow >> Network Architecture Group >> NICT (nict.go.jp) >> >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From julien.bournelle@gmail.com Tue Jun 23 09:35:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2E528C3AD for ; Tue, 23 Jun 2009 09:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3jN28k61lIv for ; Tue, 23 Jun 2009 09:35:35 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 30D613A6BD6 for ; Tue, 23 Jun 2009 09:35:35 -0700 (PDT) Received: by ewy6 with SMTP id 6so298021ewy.37 for ; Tue, 23 Jun 2009 09:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=l0wdIVOQbRNxnUBeJooafW/aRvdeTJ7Bo1/T11bOsKY=; b=Hs2CGb+Bw5909D5ngpku4pwiZkum7NFnxHizoIkZB0Stf25byZKrCyyTqhFFTPiONS Sxm6p+/01sutwawqSzdNuxwrh/Ja/mlBQkiBZC08jjPSU9pX3O5rI8CcKUzvUJ4+nHzH Y6cM0pRlNtxZVqk2NSVIhsLnlCvY/XHNHSriQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l4iybAvEPqaRTXEQb6BfFgJfRBgmpxV87jlm4+n9BGDR/p1I8ZXsrKD+qLCwi5i8fL +/0Z2e0063GoyDmCBhGOYwWWKjo5JsfQVTpqvuQxb58wg7GFTBeKAAxrKuFRHxs80Q/7 ighU0QSgNdYMyduJ+4DkeoUxNJ1CpBTrrEPcM= MIME-Version: 1.0 Received: by 10.216.46.83 with SMTP id q61mr90424web.71.1245774948532; Tue, 23 Jun 2009 09:35:48 -0700 (PDT) In-Reply-To: <4A409349.8030808@nict.go.jp> References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> <4A409349.8030808@nict.go.jp> Date: Tue, 23 Jun 2009 18:35:48 +0200 Message-ID: <5e2406980906230935l6719309fj3ea3d07017d43e51@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016e64c39dc4702a2046d069592 Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 16:35:37 -0000 --0016e64c39dc4702a2046d069592 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, Response inline On Tue, Jun 23, 2009 at 10:33 AM, Sebastien Decugis wrote: > Hello Julien, > > Please find my answers inline. > > > > This document specifies how Diameter is used to carry the re- > > > authentication exchange (second step). For this purpose, we define a > > > new Application Id for ERP, and re-use the Diameter EAP commands > > > (DER/DEA). > > > > We need a justification here. > Do you mean a justification for defining a new application ID? yes > > > > > We also discuss the key distribution (first step, bootstrapping) and > > > propose some solutions for different architectures. Anyway, > > > implementors are free to choose a different mechanism for key > > > distribution, as for example using RADIUS [I-D.ietf-hokey-key-mgm]. > > > > Rafa sent an email on this draft and I agree with him i.e. the draft > > should > > not mention RADIUS, only AAA. > I also agree with this proposed change. > If the referenced draft is updated, then this sentence will have to be > rewritten accordingly, for example as: > "We also discuss the key distribution (first step, bootstrapping) and > propose some solutions for different architectures, following the > principles of [I-D.ietf-hokey-key-mgm]. Anyway, > implementors are free to choose a different mechanism for key > distribution." > > Of course, we might choose to restrict the choice on the key > distribution mechanism if people think it is better. > > > > This simplifies the routing of Diameter messages to the > > > appropriate server, and allows more flexibility in the deployment of > > > ERP. > > > > in which scenario does it simplify the routing process ? in case of > > HO to a new authenticator ? > > If this is the case, I don't really understand how it solves the > > problem because we may have deployed > > 2 ERPs servers. > It was presented during Virtual Interim meeting last February. You can > still find the slides there: > > http://trac.tools.ietf.org/wg/dime/trac/attachment/wiki/ConferenceBridge/diameter-erp.pdf > The advantages of a separate Diameter application ID are highlighted in > slide #8. ok, so I guess we are talking about the routing issue in case of a handover. Then, I still don't see what a new application id solves here. If I have multiple ERP servers in the visited or home, how does the target authenticator knows to which ERP servers it shall send its request ?? > > > > > The scope of previous documents ([I-D.ietf-dime-erp] and > > > [I-D.wu-dime-local-keytran]) was focused on the bootstrapping of the > > > mechanism. > > > > this is not really true. The goal of our document was to define how > > to use Diameter > > for ERP for bootstrapping and reauthentication. > That is right, and I simplified too much the phrasing in the new draft, > sorry. The general guidelines are exposed in the "Protocol overview" > section. Anyway, there is no consideration about the message routing and > Diameter deployment. This is what I wanted to express. For example, > after a first re-authentication, the message is sent with local > Destination-Realm and EAP application, but it must reach the ER local > server. I know that this was in the scope of the document (and in the > todo-list), but it was just missing in the current version. > > Anyway, if this new design for Diameter ERP is to be accepted, this > section would disappear when the document becomes the WG document. ok > > > > > In particular, these documents did not consider the > > > routing of Diameter message for re-authentication exchanges (ERP > > > exchange, and also [RFC4187] for the second document). By re-using > > > the Diameter EAP application, they create implicit constraints on > > > routing of messages that cannot be met by standard Diameter routing > > > algorithm, as defined in the Diameter Base Protocol [RFC3588]. > > > > > > A separate Diameter application solves this routing issue, and can > > > also allow the authenticator to dynamically discover if the local > > > domain supports re-authentication or not. > > > > I think that it is important to highlight what was the issue and how the > > Application-Id solve it. I don't think that we can go in this new > > direction > > without a clear understanding of the issue and of course of the proposed > > solution. > > > > So, could you send an email explaining the Issue and the proposed > > solution ? > Do the slides of the Interim meeting answer your questions? Unfortunately not totally. > Otherwise, I > can try to re-summarize all the discussion in a new mail if needed. I > thought that the routing issue was already accepted, but I realize now > that it does not seem to be the case... I guess we all agree that we have a routing issue. But it could be good to summarize clearly the routing issue in case of ERP. And then to explain how Application-Id solves it. > Do you think this discussion should be written in the draft? I was not > sure if the RFC(-to-be) is a right place for design discussions... > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --0016e64c39dc4702a2046d069592 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

=A0Response inline

On Tue, = Jun 23, 2009 at 10:33 AM, Sebastien Decugis <sdecugis@nict.go.jp> wrote:
Hello Julien,

Please find my answers inline.

> > =A0 This document specifies how Diameter is used to carry the re-=
> > =A0 authentication exchange (second step). =A0For this purpose, w= e define a
> > =A0 new Application Id for ERP, and re-use the Diameter EAP comma= nds
> > =A0 (DER/DEA).
>
> We need a justification here.
Do you mean a justification for defining a new application ID?

=A0yes
=A0


> > =A0 We also discuss the key distribution (first step, bootstrappi= ng) and
> > =A0 propose some solutions for different architectures. =A0Anyway= ,
> > =A0 implementors are free to choose a different mechanism for key=
> > =A0 distribution, as for example using RADIUS [I-D.ietf-hokey-key= -mgm].
>
> =A0Rafa sent an email on this draft and I agree with him i.e. the draf= t
> should
> not mention RADIUS, only AAA.
I also agree with this proposed change.
If the referenced draft is updated, then this sentence will have to be
rewritten accordingly, for example as:
"We also discuss the key distribution (first step, b= ootstrapping) and
propose some solutions for different architectures, following the
principles of [I-D.ietf-hokey-key-mgm]. Anyway,
implementors are free to choose a different mechanism for= key
distribution."

Of course, we might choose to restrict the choice on the key
distribution mechanism if people think it is better.

> > =A0 This simplifies the routing of Diameter messages to the
> > =A0 appropriate server, and allows more flexibility in the deploy= ment of
> > =A0 ERP.
>
> =A0in which scenario does it simplify the routing process ? in case of=
> HO to a new authenticator ?
> =A0If this is the case, I don't really understand how it solves th= e
> problem because we may have deployed
> 2 ERPs servers.
It was presented during Virtual Interim meeting last February. You ca= n
still find the slides there:
http://trac.tools.ietf.org/wg/= dime/trac/attachment/wiki/ConferenceBridge/diameter-erp.pdf
The advantages of a separate Diameter application ID are highlighted in
slide #8.

=A0ok, so I guess we are talking about the r= outing issue in case of a handover.

=A0Then, I still don't see w= hat a new application id solves here. If I have multiple ERP servers in the= visited or home, how does the target authenticator knows to which ERP serv= ers it shall send its request ??
=A0


> > =A0 The scope of previous documents ([I-D.ietf-dime-erp] and
> > =A0 [I-D.wu-dime-local-keytran]) was focused on the bootstrapping= of the
> > =A0 mechanism.
>
> =A0this is not really true. The goal of our document was to define how=
> to use Diameter
> for ERP for bootstrapping and reauthentication.
That is right, and I simplified too much the phrasing in the new draf= t,
sorry. The general guidelines are exposed in the "Protocol overview&qu= ot;
section. Anyway, there is no consideration about the message routing and Diameter deployment. This is what I wanted to express. For example,
after a first re-authentication, the message is sent with local
Destination-Realm and EAP application, but it must reach the ER local
server. I know that this was in the scope of the document (and in the
todo-list), but it was just missing in the current version.

Anyway, if this new design for Diameter ERP is to be accepted, this
section would disappear when the document becomes the WG document.

ok
=A0


> > =A0In particular, these documents did not consider the
> > =A0 routing of Diameter message for re-authentication exchanges (= ERP
> > =A0 exchange, and also [RFC4187] for the second document). =A0By = re-using
> > =A0 the Diameter EAP application, they create implicit constraint= s on
> > =A0 routing of messages that cannot be met by standard Diameter r= outing
> > =A0 algorithm, as defined in the Diameter Base Protocol [RFC3588]= .
> >
> > =A0 A separate Diameter application solves this routing issue, an= d can
> > =A0 also allow the authenticator to dynamically discover if the l= ocal
> > =A0 domain supports re-authentication or not.
>
> =A0I think that it is important to highlight what was the issue and ho= w the
> Application-Id solve it. I don't think that we can go in this new<= br> > direction
> without a clear understanding of the issue and of course of the propos= ed
> solution.
>
> =A0So, could you send an email explaining the Issue and the proposed > solution ?
Do the slides of the Interim meeting answer your questions?

Unfortunately not totally.
=A0
Otherwise, I
can try to re-summarize all the discussion in a new mail if needed. I
thought that the routing issue was already accepted, but I realize now
that it does not seem to be the case...

I guess we all= agree that we have a routing issue. But it could be good to summarize
= clearly the routing issue in case of ERP. And then to explain how Applicati= on-Id solves it.
=A0



Do you think this discussion should be written in the draft? I was not
sure if the RFC(-to-be) is a right place for design discussions...

Best regards,
Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)


--0016e64c39dc4702a2046d069592-- From julien.bournelle@gmail.com Tue Jun 23 09:40:49 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A715128C3AD for ; Tue, 23 Jun 2009 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oszyEjwfNLGB for ; Tue, 23 Jun 2009 09:40:48 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 54AAC28C3C0 for ; Tue, 23 Jun 2009 09:40:48 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id d26so20954eyd.31 for ; Tue, 23 Jun 2009 09:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cefps2c7NYK6MVlUc/Q6gbJ11A185eq3Aawdyrvw8S8=; b=i1EI6EVGUodey86t0wPhTYiL+f0uDFh6cFdTvQzJmYfpkiySAsGROosv0HrtgcRnIM +VPoV1FaVE7Afp3Gz2YzopYrPpo2I73UAzC1gmx3W8w28qJMX5PISLZYPnNEApBSGzs1 qn4c2eRVAongfZOKVuzBRLvRAc68ljkZO/tPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AYk2H8+VZmEMkDlo6j0ih41bVPPF8LMVNdCzae4t69pFNuDJexIY0LQJqT8ICiANoh kbSj22lm/WZvzEssfxE9adhe4esPzmEz6SlFjWbzQAoj/y27QoZDff/v2vxBVWWIGA1w NVhgglwFqj6pa+HXU7nXiXGBy1ryVT7Td1i88= MIME-Version: 1.0 Received: by 10.216.71.83 with SMTP id q61mr101569wed.14.1245775261516; Tue, 23 Jun 2009 09:41:01 -0700 (PDT) In-Reply-To: <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> Date: Tue, 23 Jun 2009 18:41:01 +0200 Message-ID: <5e2406980906230941x7c74915eqe754c30d335d04f0@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis , dime@ietf.org Content-Type: multipart/alternative; boundary=00504502d159eec515046d06a708 Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 16:40:49 -0000 --00504502d159eec515046d06a708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, What about the end of my previous mail (see below) ??? On Wed, Jun 17, 2009 at 3:18 PM, Julien Bournelle < julien.bournelle@gmail.com> wrote: > > > > The bootstrapping of the ER server has to occur sometime between the > > initial EAP authentication and the first ERP re-authentication with > > this ER server. See section Section 7 for detail on this process. > > Then, the peer re-authenticates, for example after a movement that > > makes it attach to a new authenticator. The following figure > > describes this re-authentication, and shows how Diameter is used in > > this context. See section Section 8 for a detailed description, and > > following sections for details on the Diameter messages format. > > > > ER server > > (bootstrapped) > > Peer Authenticator (local or home domain) > > ==== ============= ====================== > > [ <------------------------ ] > > [optional EAP-Initiate/Re-auth-start] > > > > -----------------------> > > EAP-Initiate/Re-auth > > ==================================> > > Diameter ERP, cmd code DER > > User-Name: Keyname-NAI > > EAP-Payload: EAP-Initiate/Re-auth > > > > <================================== > > Diameter ERP, cmd code DEA > > EAP-Payload: EAP-Finish/Re-auth > > EAP-Master-Session-Key: rMSK > > <---------------------- > > EAP-Finish/Re-auth > > > > Figure 2. Diameter ERP exchange. > > > Just wondering: what happens with the originial AAA/EAP server which is > supposed to handle in particular lifetime session ? Do we need to inform > him of the HO ? what happens to its AAA session with the first > authenticator ? > > and that's all for the moment. > > Regards, > > Julien > > > --00504502d159eec515046d06a708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

=A0What about the end of my previous mail (see below) ???
On Wed, Jun 17, 2009 at 3:18 PM, Julien Bou= rnelle <= julien.bournelle@gmail.com> wrote:
>
> =A0 The bootstrapping of the ER server has to occur sometime = between the
> =A0 initial EAP authentication and the first ERP re-authentication wit= h
> =A0 this ER server. =A0See section Section 7 for detail on this proces= s.
> =A0 Then, the peer re-authenticates, for example after a movement that=
> =A0 makes it attach to a new authenticator. =A0The following figur= e
> =A0 describes this re-authentication, and shows how Diameter is u= sed in
> =A0 this context. =A0See section Section 8 for a detailed description,= and
> =A0 following sections for details on the Diameter messages fo= rmat.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ER server
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(bootstrapped)
> =A0Peer =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Authenticator =A0 =A0 =A0 =A0 =A0 =A0 =A0 (loca= l or home domain)
> =A0=3D=3D=3D=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =A0[ <------------------------ =A0 =A0 =A0 =A0 ]
> =A0[option= al EAP-Initiate/Re-auth-start]
>
> =A0 -----------------------&= gt;
> =A0 =A0 EAP-Initiate/Re-auth
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Diamete= r ERP, cmd code DER
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0User-Name: Keyname-NAI
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0EAP-Payload: EAP-Initiate/Re-auth
>= ;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Diamete= r ERP, cmd code DEA
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0EAP-Payload: EAP-Finish/Re-auth
> =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EAP-Master-Session-Key: rMSK
> = =A0 =A0<----------------------
> =A0 =A0 =A0EAP-Finish/Re-auth
>
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Figure 2. Diameter ERP exchange.


=A0Just w= ondering: what happens with the originial AAA/EAP server which is
suppos= ed to handle in particular lifetime session ? Do we need to inform
him of the HO ? what happens to its AAA session with the first authenticato= r ?

=A0and that's all for the moment.

=A0Regards,

=A0Julien



--00504502d159eec515046d06a708-- From root@core3.amsl.com Tue Jun 23 13:30:02 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ACE0C3A6D27; Tue, 23 Jun 2009 13:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090623203001.ACE0C3A6D27@core3.amsl.com> Date: Tue, 23 Jun 2009 13:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 20:30:02 -0000 A modified charter has been submitted for the Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. Diameter Maintenance and Extensions (dime) =========================================== Last Modified: 2009-06-10 Current Status: Working Group Chair(s): Hannes Tschofenig Victor Fajardo Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Goals and Milestones: Done Submit 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Nov 2009 Submit 'Revision of Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Aug 2009 Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Jun 2009 Submit new DIME charter to the IESG Jun 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME working group item Nov 2009 Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard From tom.taylor@rogers.com Tue Jun 23 19:01:53 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7211E3A6EEE for ; Tue, 23 Jun 2009 19:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUeTIhMT07Q8 for ; Tue, 23 Jun 2009 19:01:52 -0700 (PDT) Received: from smtp110.rog.mail.re2.yahoo.com (smtp110.rog.mail.re2.yahoo.com [206.190.37.120]) by core3.amsl.com (Postfix) with SMTP id 85EAB3A6ED6 for ; Tue, 23 Jun 2009 19:01:52 -0700 (PDT) Received: (qmail 80887 invoked from network); 24 Jun 2009 02:02:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=pMI0aTkcl3WcOoVp62JFlObc2uYy3IwvUQ6J7LJFeGVro2MSG2oN0q6cLKBj/lB7/bV3I4J7Z7k7SMbBIvQ/A4ldRg5gqBhWLkZS8xh71sz3NNMMNi/rnsSy9T4ZQi44m61VnLA15/P+MwScTFW5SKuellMANekT5X6biZsYlTg= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp110.rog.mail.re2.yahoo.com with SMTP; 24 Jun 2009 02:02:06 -0000 X-YMail-OSG: pSANQJMVM1kZUutHvEFSI4Z.nktTh8Sad6aWTUG2T8pq4PGf0GvuIHpmcNDmwy.ltw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A41891F.9000804@rogers.com> Date: Tue, 23 Jun 2009 22:02:07 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] Milestone for realm-based redirection X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 02:01:53 -0000 The proposed new charter for DIME does not have a milestone for realm-based redirection. I would support adding one. I could see it falling under the work described as: "- Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions." BTW note "such" -> "such as" in the last line. Anyway, could such a milestone be added easily later as the work matures or should I be writing to the IESG about this as directed in the announcement? Tom From sdecugis@nict.go.jp Tue Jun 23 21:41:18 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D503A684E for ; Tue, 23 Jun 2009 21:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz6wblIlMAoN for ; Tue, 23 Jun 2009 21:41:16 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 2D2BC3A67A8 for ; Tue, 23 Jun 2009 21:41:15 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n5O4fThi001726; Wed, 24 Jun 2009 13:41:29 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n5O4fTih005144; Wed, 24 Jun 2009 13:41:29 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n5O4fT6s005141; Wed, 24 Jun 2009 13:41:29 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 0320216504; Wed, 24 Jun 2009 13:41:29 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id E00DA164EF; Wed, 24 Jun 2009 13:41:28 +0900 (JST) Message-ID: <4A41AE75.7090103@nict.go.jp> Date: Wed, 24 Jun 2009 13:41:25 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Julien Bournelle References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> <5e2406980906230941x7c74915eqe754c30d335d04f0@mail.gmail.com> In-Reply-To: <5e2406980906230941x7c74915eqe754c30d335d04f0@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 04:41:18 -0000 Hello, > What about the end of my previous mail (see below) ??? Oops sorry I missed that part. I'll answer this now. > Just wondering: what happens with the originial AAA/EAP server > which is > supposed to handle in particular lifetime session ? Do we need to > inform > him of the HO ? what happens to its AAA session with the first > authenticator ? > I am not sure of the impact of the handover on the EAP server. Basically, I think it doesn't have any, at least on the authentication side. In my understanding, the EAP server function is to (mutually) authenticate a peer/user and provide a lifetime to this authentication. When ERP is used, it allows the peer/user to change attachment point to the network and still use this (mutual) authentication "token" while its lifetime is not expired. Since the lifetime is not extended, the EAP server does not need to know the movement in my opinion. The impact of ERP on the authorization has to be studied. The EAP server implicitly authorizes ERP (and therefore the peer movement) when deriving an rRK / rDSRK (for a given domain) and providing it to the ER server. If you need more granularity for the authorization than the domain scale, then additional measures have to be taken, but I don't think this is required in this document. Do you think otherwise? The impact of ERP and movement on the accounting is the most problematic in my opinion. I have put my ideas in the section 9 of the draft, for open discussion and resolution. I don't have the appropriate background to understand fully the needs of accounting, so I am wanting to hear more experienced peoples thoughts. I did not check yet how it is handled in case of IP mobility, but maybe we can use similar mechanism? As for session(s) termination(s), I did not study how each AAA component should behave in case of movement. For example, when the peer leaves NAS1 to attach to NAS2, does NAS1 send a STR? This must be studied and detailed in the document (this is independent of the choice of application id for ERP). Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Tue Jun 23 22:07:46 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B593A6F34 for ; Tue, 23 Jun 2009 22:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqvlQ0+HGd44 for ; Tue, 23 Jun 2009 22:07:45 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 75D4B28C338 for ; Tue, 23 Jun 2009 22:07:44 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n5O57vIT005541; Wed, 24 Jun 2009 14:07:57 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n5O57vkc012561; Wed, 24 Jun 2009 14:07:57 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n5O57vCl012558; Wed, 24 Jun 2009 14:07:57 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 8A7E3164F0; Wed, 24 Jun 2009 14:07:57 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 84211164EF; Wed, 24 Jun 2009 14:07:57 +0900 (JST) Message-ID: <4A41B4A9.5090202@nict.go.jp> Date: Wed, 24 Jun 2009 14:07:53 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Julien Bournelle References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> <4A409349.8030808@nict.go.jp> <5e2406980906230935l6719309fj3ea3d07017d43e51@mail.gmail.com> In-Reply-To: <5e2406980906230935l6719309fj3ea3d07017d43e51@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 05:07:46 -0000 Hi again, > > > We need a justification here. > Do you mean a justification for defining a new application ID? > > > yes Ok. It can be added in a future version of the document. > > It was presented during Virtual Interim meeting last February. You can > still find the slides there: > http://trac.tools.ietf.org/wg/dime/trac/attachment/wiki/ConferenceBridge/diameter-erp.pdf > The advantages of a separate Diameter application ID are > highlighted in > slide #8. > > > ok, so I guess we are talking about the routing issue in case of a > handover. This is the main reason for this proposed change, but there may be other advantages (possibility to detect if ERP is supported during the CER/CEA exchange, for example). > Then, I still don't see what a new application id solves here. If I > have multiple ERP servers in the visited or home, how does the target > authenticator knows to which ERP servers it shall send its request ?? I don't think there is an issue here. The question should be asked in the HOKEY group, since it's an ERP concern, not Diameter, AFAICT. > > I think that it is important to highlight what was the issue > and how the > > Application-Id solve it. I don't think that we can go in this new > > direction > > without a clear understanding of the issue and of course of the > proposed > > solution. > > > > So, could you send an email explaining the Issue and the proposed > > solution ? > Do the slides of the Interim meeting answer your questions? > > > Unfortunately not totally. If you use EAP application id, your local ERP Diameter proxy have to be on the path of all EAP messages for both local and foreign realms coming from a NAS in the local domain, and also all EAP messages coming from other realms to the local EAP server. I think this requirement is very difficult to achieve, and leads to a huge load of this proxy. By having a different application ID, you can configure the routing differently for ERP messages and for "normal" EAP messages. This provides more flexibility in the deployment, which is always a good thing IMHO. I can't think of any inconvenient of having a separate application ID for ERP compared to reusing the EAP application ID. In any case the support for ERP cannot be added "transparently" since ERP requires modifications of the EAP server and the NAS (regardless of Diameter). > > Otherwise, I > can try to re-summarize all the discussion in a new mail if needed. I > thought that the routing issue was already accepted, but I realize now > that it does not seem to be the case... > > > I guess we all agree that we have a routing issue. But it could be > good to summarize > clearly the routing issue in case of ERP. And then to explain how > Application-Id solves it. Do you think this should be put in the document, or discussed on this mailing-list (or both) ? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From jouni.nospam@gmail.com Wed Jun 24 01:26:25 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3024A3A63CB for ; Wed, 24 Jun 2009 01:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cR-p+HrmeP1 for ; Wed, 24 Jun 2009 01:26:24 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 0A07C3A682D for ; Wed, 24 Jun 2009 01:26:23 -0700 (PDT) Received: by ewy6 with SMTP id 6so930304ewy.37 for ; Wed, 24 Jun 2009 01:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=A1WlifXF2VRB9zzE2lS4bMAiyRqUhEy9I4ZtKx/k7Fc=; b=DXvIZ0NUu1H+zBRy44g4OzX71bCSgUxCkHF5Ft2LFUpguWh+zyR0vISC+jsxKw1BAq vhD9lmsWeE56fKpDg+Wwt5/3o9V5cZKQZXHg8mPqnuI6wqM0d2RNQktIATACOm7WUaI4 VyJVrMNVtGRjJLZFF62mLHmupCNA8e7G5BEQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=J94xmF003ncZezO4RQQPcI5xRKjFDYD3N1O71CcEASudCblBIBLBv9CDJMCy1W1yNH Dul3h5a49OQvBp4hVg2zzbVtY3GyqxXsG78n5oCQBRZqEheV4Oj3oeZvEbLpSzKoh2WR MGJxojrfPzVEeRoiqqRvKkloxL9ohTjCx2YyY= Received: by 10.210.109.10 with SMTP id h10mr1114548ebc.89.1245831975154; Wed, 24 Jun 2009 01:26:15 -0700 (PDT) Received: from ?10.254.1.179? ([192.100.123.77]) by mx.google.com with ESMTPS id 28sm1343520eye.56.2009.06.24.01.26.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Jun 2009 01:26:14 -0700 (PDT) From: jouni korhonen To: Qin Wu In-Reply-To: <04ea01c9f3d7$322df280$260ca40a@china.huawei.com> X-Priority: 3 References: <016501c9e5c8$9e730dd0$db592970$@net> <031a01c9f000$460eefa0$260ca40a@china.huawei.com> <4A3A3F6B.804@tari.toshiba.com> <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> <4A3F8B32.3020205@tari.toshiba.com> <04ea01c9f3d7$322df280$260ca40a@china.huawei.com> Message-Id: <27E94585-6545-4C61-8FE8-77C73C6C3D75@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 11:26:11 +0300 X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:26:25 -0000 Hi, Just a quick note here.. On Jun 23, 2009, at 10:49 AM, Qin Wu wrote: [snip] >> >> Ok. Then I'm not really sure what your comparing re-auth againts. Are >> you comparing client vs. server re-auth ? In that case, is there >> anything broken in the bis that relates to this ? > > [Qin]: See above. > Since Re-authentication is defined in the credit control in the RFC > 4006, I am just confused if the same terms"Re-authentication" We are talking about RAR command here, right? That is defined in Base protocol and used in several places, including 4006, 4005, and a bunch of SDO specs defined applications. > is used in the Diameter ERP as well If the folks have no difficulty > to distinguish the Re-authentication in the Diameter ERP from the > Reauthentication in the Credit control application, > then I have no strong feeling against it. > If my understanding is not right, please correct me. Use different application-id ? Jouni > >> regards, >> victor >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sunseawq@huawei.com Wed Jun 24 01:59:39 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02FD28C2FA for ; Wed, 24 Jun 2009 01:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9PIm7e-egCs for ; Wed, 24 Jun 2009 01:59:39 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D16A23A6A38 for ; Wed, 24 Jun 2009 01:59:38 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ009NAJNHNE@szxga02-in.huawei.com> for dime@ietf.org; Wed, 24 Jun 2009 16:59:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ00CD0JNH50@szxga02-in.huawei.com> for dime@ietf.org; Wed, 24 Jun 2009 16:59:41 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLQ00DD1JNHJK@szxml04-in.huawei.com> for dime@ietf.org; Wed, 24 Jun 2009 16:59:41 +0800 (CST) Date: Wed, 24 Jun 2009 16:59:41 +0800 From: Qin Wu To: jouni korhonen Message-id: <023301c9f4aa$1c88b9f0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <016501c9e5c8$9e730dd0$db592970$@net> <031a01c9f000$460eefa0$260ca40a@china.huawei.com> <4A3A3F6B.804@tari.toshiba.com> <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> <4A3F8B32.3020205@tari.toshiba.com> <04ea01c9f3d7$322df280$260ca40a@china.huawei.com> <27E94585-6545-4C61-8FE8-77C73C6C3D75@gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:59:39 -0000 Hi, Jouni and Victor: Thank for Jouni's clarification, I guess I misunderstand this widely used terms"Re-auth" Since they have been used by different applications as command code, e.g., NASReq, Credit control, I think I am okay with the current description in the rfc3588bis. But I still want to point out the Re-auth in the EAP re-authentication is client initiated and has the meaning, quite different from the other applications, am I right? Regards! -Qin ----- Original Message ----- From: "jouni korhonen" To: "Qin Wu" Cc: "Victor Fajardo" ; Sent: Wednesday, June 24, 2009 4:26 PM Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 > Hi, > > Just a quick note here.. > > On Jun 23, 2009, at 10:49 AM, Qin Wu wrote: > > > [snip] > > >>> >>> Ok. Then I'm not really sure what your comparing re-auth againts. Are >>> you comparing client vs. server re-auth ? In that case, is there >>> anything broken in the bis that relates to this ? >> >> [Qin]: See above. >> Since Re-authentication is defined in the credit control in the RFC >> 4006, I am just confused if the same terms"Re-authentication" > > We are talking about RAR command here, right? That is defined in Base > protocol and used in several places, including 4006, 4005, and a bunch > of SDO specs defined applications. > >> is used in the Diameter ERP as well If the folks have no difficulty >> to distinguish the Re-authentication in the Diameter ERP from the >> Reauthentication in the Credit control application, >> then I have no strong feeling against it. >> If my understanding is not right, please correct me. > > Use different application-id ? > > Jouni > > > >> >>> regards, >>> victor >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From jouni.nospam@gmail.com Wed Jun 24 02:46:12 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5E03A6B1E for ; Wed, 24 Jun 2009 02:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZYKhcSnMVfv for ; Wed, 24 Jun 2009 02:46:11 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 6117C3A6B16 for ; Wed, 24 Jun 2009 02:46:11 -0700 (PDT) Received: by ewy6 with SMTP id 6so986639ewy.37 for ; Wed, 24 Jun 2009 02:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=hSdGEqqUpifu2k5B11NIEHL3Ga6NN2SpdnfF6QQELV4=; b=NMelc/STn09CssssNb0UIeuIDZPCYbMtPFZ/9koycW3MCeTnRGcMeeA10PIB30DUf8 ufysmjanAZ9V1LVaqFqH0Me2XqwvKfsYRYdZ3vypwBCyjUz6Bg3tRhBmcMziyVTZNSZM qRSmv4Oolg15EWTNO0bYPGdnTvjvIHW2Wwy8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=CWytHJXToa+zMqyG9Yqk/ubPkll9DmZrJz9D6ZwX+w6QT9LrEcwDaSFiKLX/eKGLVo qXN4iv+LkTHSY/sCxQFh5dmBsV8ZeUlf7F0bep5s76eF4M6jgk4dIKSvOzcOLMk8/wCd AvOvcahBmbs/CxVaHUpM3uFz2l7Myfjc1l2Mg= Received: by 10.210.102.9 with SMTP id z9mr1252880ebb.47.1245836778210; Wed, 24 Jun 2009 02:46:18 -0700 (PDT) Received: from ?10.254.1.179? ([192.100.123.77]) by mx.google.com with ESMTPS id 5sm1808857eyf.7.2009.06.24.02.46.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Jun 2009 02:46:17 -0700 (PDT) From: jouni korhonen To: Qin Wu In-Reply-To: <023301c9f4aa$1c88b9f0$260ca40a@china.huawei.com> X-Priority: 3 References: <016501c9e5c8$9e730dd0$db592970$@net> <031a01c9f000$460eefa0$260ca40a@china.huawei.com> <4A3A3F6B.804@tari.toshiba.com> <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> <4A3F8B32.3020205@tari.toshiba.com> <04ea01c9f3d7$322df280$260ca40a@china.huawei.com> <27E94585-6545-4C61-8FE8-77C73C6C3D75@gmail.com> <023301c9f4aa$1c88b9f0$260ca40a@china.huawei.com> Message-Id: <33B3CCBD-DF53-4B2A-BEB8-0FB7566705A3@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 12:46:14 +0300 X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 09:46:12 -0000 Hi Qin, On Jun 24, 2009, at 11:59 AM, Qin Wu wrote: > Hi, Jouni and Victor: > Thank for Jouni's clarification, I guess I misunderstand this widely > used terms"Re-auth" > Since they have been used by different applications as command code, > e.g., NASReq, Credit control, I think I am okay with > the current description in the rfc3588bis. But I still want to point > out the Re-auth in the EAP re-authentication > is client initiated and has the meaning, quite different from the > other applications, am I right? When a NAS (authenticator) receives a RAR, the NAS can initiate EAP (re-)authentication at any time just by issuing EAP-Request/Identity towards the client/peer. Cheers, Jouni > > > Regards! > -Qin > ----- Original Message ----- > From: "jouni korhonen" > To: "Qin Wu" > Cc: "Victor Fajardo" ; > Sent: Wednesday, June 24, 2009 4:26 PM > Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 > > >> Hi, >> >> Just a quick note here.. >> >> On Jun 23, 2009, at 10:49 AM, Qin Wu wrote: >> >> >> [snip] >> >> >>>> >>>> Ok. Then I'm not really sure what your comparing re-auth againts. >>>> Are >>>> you comparing client vs. server re-auth ? In that case, is there >>>> anything broken in the bis that relates to this ? >>> >>> [Qin]: See above. >>> Since Re-authentication is defined in the credit control in the RFC >>> 4006, I am just confused if the same terms"Re-authentication" >> >> We are talking about RAR command here, right? That is defined in Base >> protocol and used in several places, including 4006, 4005, and a >> bunch >> of SDO specs defined applications. >> >>> is used in the Diameter ERP as well If the folks have no difficulty >>> to distinguish the Re-authentication in the Diameter ERP from the >>> Reauthentication in the Credit control application, >>> then I have no strong feeling against it. >>> If my understanding is not right, please correct me. >> >> Use different application-id ? >> >> Jouni >> >> >> >>> >>>> regards, >>>> victor >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> From sunseawq@huawei.com Wed Jun 24 02:53:15 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F923A6B24 for ; Wed, 24 Jun 2009 02:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2eziGV38lzV for ; Wed, 24 Jun 2009 02:53:14 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2EF933A6A35 for ; Wed, 24 Jun 2009 02:53:14 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ00AORM2N96@szxga03-in.huawei.com> for dime@ietf.org; Wed, 24 Jun 2009 17:51:59 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ00DPCM2NM0@szxga03-in.huawei.com> for dime@ietf.org; Wed, 24 Jun 2009 17:51:59 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLQ00DOVM2NJK@szxml04-in.huawei.com> for dime@ietf.org; Wed, 24 Jun 2009 17:51:59 +0800 (CST) Date: Wed, 24 Jun 2009 17:51:59 +0800 From: Qin Wu To: jouni korhonen Message-id: <033a01c9f4b1$6ac601c0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <016501c9e5c8$9e730dd0$db592970$@net> <031a01c9f000$460eefa0$260ca40a@china.huawei.com> <4A3A3F6B.804@tari.toshiba.com> <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> <4A3F8B32.3020205@tari.toshiba.com> <04ea01c9f3d7$322df280$260ca40a@china.huawei.com> <27E94585-6545-4C61-8FE8-77C73C6C3D75@gmail.com> <023301c9f4aa$1c88b9f0$260ca40a@china.huawei.com> <33B3CCBD-DF53-4B2A-BEB8-0FB7566705A3@gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 09:53:15 -0000 Hi, Jouni: ----- Original Message ----- From: "jouni korhonen" To: "Qin Wu" Cc: "Victor Fajardo" ; Sent: Wednesday, June 24, 2009 5:46 PM Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 > Hi Qin, > > On Jun 24, 2009, at 11:59 AM, Qin Wu wrote: > >> Hi, Jouni and Victor: >> Thank for Jouni's clarification, I guess I misunderstand this widely >> used terms"Re-auth" >> Since they have been used by different applications as command code, >> e.g., NASReq, Credit control, I think I am okay with >> the current description in the rfc3588bis. But I still want to point >> out the Re-auth in the EAP re-authentication >> is client initiated and has the meaning, quite different from the >> other applications, am I right? > > When a NAS (authenticator) receives a RAR, the NAS can initiate EAP > (re-)authentication at any time just by issuing EAP-Request/Identity > towards the client/peer. [Qin]: It is a example which is not relected in the RFC4005 or other SDO specs, am I right? > Cheers, > Jouni > > >> >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: "jouni korhonen" >> To: "Qin Wu" >> Cc: "Victor Fajardo" ; >> Sent: Wednesday, June 24, 2009 4:26 PM >> Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17 >> >> >>> Hi, >>> >>> Just a quick note here.. >>> >>> On Jun 23, 2009, at 10:49 AM, Qin Wu wrote: >>> >>> >>> [snip] >>> >>> >>>>> >>>>> Ok. Then I'm not really sure what your comparing re-auth againts. >>>>> Are >>>>> you comparing client vs. server re-auth ? In that case, is there >>>>> anything broken in the bis that relates to this ? >>>> >>>> [Qin]: See above. >>>> Since Re-authentication is defined in the credit control in the RFC >>>> 4006, I am just confused if the same terms"Re-authentication" >>> >>> We are talking about RAR command here, right? That is defined in Base >>> protocol and used in several places, including 4006, 4005, and a >>> bunch >>> of SDO specs defined applications. >>> >>>> is used in the Diameter ERP as well If the folks have no difficulty >>>> to distinguish the Re-authentication in the Diameter ERP from the >>>> Reauthentication in the Credit control application, >>>> then I have no strong feeling against it. >>>> If my understanding is not right, please correct me. >>> >>> Use different application-id ? >>> >>> Jouni >>> >>> >>> >>>> >>>>> regards, >>>>> victor >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> > From julien.bournelle@gmail.com Wed Jun 24 09:12:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843583A6FAF for ; Wed, 24 Jun 2009 09:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgY493d8hUot for ; Wed, 24 Jun 2009 09:12:57 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id C20493A6FB2 for ; Wed, 24 Jun 2009 09:12:56 -0700 (PDT) Received: by mail-ew0-f210.google.com with SMTP id 6so1338925ewy.37 for ; Wed, 24 Jun 2009 09:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=JMaLy9DVN1hVqtqFoG4Jz5YbHh4n87fTlKfXo8bPchA=; b=CPjRnerAoKf0+kAsq5pE7tC1cPr2Q31bLjIWO4fPhyZ+YmVTEzMEzGHODkUy+UvGL4 DPlXfhAtQ9WLhdwE83koZZcj6m6ZJb6bMK6/R7eIwgzxuAe/jdXTEzZlylPhxUP9c0yI rbOrhPBB3tu29FJ56vlWev8SBq2WHOPZXqKY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jN8JLAuTu3iWyR1ORB5b8lT93dl4wpK/1zvAQKkvPaYp9m/N8VRa6vbL8+s6AsvVcX y1BdXS0Omx0R452OVy5Qxo+qz619jqDIKbwXIoc2MeHbRwkae/UnCVsZcXsRXXdCbPTm 0FFMozjlaSbjRiAKZPNv9ULGwtnrO9H9vZAPU= MIME-Version: 1.0 Received: by 10.216.13.75 with SMTP id a53mr445871wea.22.1245859993656; Wed, 24 Jun 2009 09:13:13 -0700 (PDT) In-Reply-To: <4A41AE75.7090103@nict.go.jp> References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> <5e2406980906230941x7c74915eqe754c30d335d04f0@mail.gmail.com> <4A41AE75.7090103@nict.go.jp> Date: Wed, 24 Jun 2009 18:13:13 +0200 Message-ID: <5e2406980906240913o73ba4327p614a4bfdf51e1110@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016364d23035c9e69046d1a6281 Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 16:12:58 -0000 --0016364d23035c9e69046d1a6281 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, see inline. On Wed, Jun 24, 2009 at 6:41 AM, Sebastien Decugis wrote: > Hello, > > > What about the end of my previous mail (see below) ??? > Oops sorry I missed that part. I'll answer this now. > > > Just wondering: what happens with the originial AAA/EAP server > > which is > > supposed to handle in particular lifetime session ? Do we need to > > inform > > him of the HO ? what happens to its AAA session with the first > > authenticator ? > > > I am not sure of the impact of the handover on the EAP server. > Basically, I think it doesn't have any, at least on the authentication > side. In my understanding, the EAP server function is to (mutually) > authenticate a peer/user and provide a lifetime to this authentication. > When ERP is used, it allows the peer/user to change attachment point to > the network and still use this (mutual) authentication "token" while its > lifetime is not expired. Since the lifetime is not extended, the EAP > server does not need to know the movement in my opinion. Let's make it simple: The home AAA/EAP server must know to which NAS the UE is currently attached. That's my issue. Regards, julien > > The impact of ERP on the authorization has to be studied. The EAP server > implicitly authorizes ERP (and therefore the peer movement) when > deriving an rRK / rDSRK (for a given domain) and providing it to the ER > server. If you need more granularity for the authorization than the > domain scale, then additional measures have to be taken, but I don't > think this is required in this document. Do you think otherwise? > The impact of ERP and movement on the accounting is the most problematic > in my opinion. I have put my ideas in the section 9 of the draft, for > open discussion and resolution. I don't have the appropriate background > to understand fully the needs of accounting, so I am wanting to hear > more experienced peoples thoughts. I did not check yet how it is handled > in case of IP mobility, but maybe we can use similar mechanism? > > As for session(s) termination(s), I did not study how each AAA component > should behave in case of movement. For example, when the peer leaves > NAS1 to attach to NAS2, does NAS1 send a STR? This must be studied and > detailed in the document (this is independent of the choice of > application id for ERP). > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --0016364d23035c9e69046d1a6281 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

=A0see inline.

On Wed, Jun = 24, 2009 at 6:41 AM, Sebastien Decugis <sdecugis@nict.go.jp> wrote:
Hello,

> =A0What about the end of my previous mail (see below) ???
Oops sorry I missed that part. I'll answer this now.

> =A0 =A0 =A0Just wondering: what happens with the originial AAA/EAP ser= ver
> =A0 =A0 which is
> =A0 =A0 supposed to handle in particular lifetime session ? Do we need= to
> =A0 =A0 inform
> =A0 =A0 him of the HO ? what happens to its AAA session with the first=
> =A0 =A0 authenticator ?
>
I am not sure of the impact of the handover on the EAP server.
Basically, I think it doesn't have any, at least on the authentication<= br> side. In my understanding, the EAP server function is to (mutually)
authenticate a peer/user and provide a lifetime to this authentication.
When ERP is used, it allows the peer/user to change attachment point to
the network and still use this (mutual) authentication "token" wh= ile its
lifetime is not expired. Since the lifetime is not extended, the EAP
server does not need to know the movement in my opinion.
<= br>Let's make it simple:
The home AAA/EAP server must kn= ow to which NAS the UE is currently attached. That's my issue.

=A0Regards,

=A0julien
=A0

The impact of ERP on the authorization has to be studied. The EAP server implicitly authorizes ERP (and therefore the peer movement) when
deriving an rRK / rDSRK (for a given domain) and providing it to the ER
server. If you need more granularity for the authorization than the
domain scale, then additional measures have to be taken, but I don't think this is required in this document. Do you think otherwise?
The impact of ERP and movement on the accounting is the most problematic in my opinion. I have put my ideas in the section 9 of the draft, for
open discussion and resolution. I don't have the appropriate background=
to understand fully the needs of accounting, so I am wanting to hear
more experienced peoples thoughts. I did not check yet how it is handled in case of IP mobility, but maybe we can use similar mechanism?

As for session(s) termination(s), I did not study how each AAA component should behave in case of movement. For example, when the peer leaves
NAS1 to attach to NAS2, does NAS1 send a STR? This must be studied and
detailed in the document (this is independent of the choice of
application id for ERP).

Best regards,
Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)


--0016364d23035c9e69046d1a6281-- From julien.bournelle@gmail.com Wed Jun 24 09:20:16 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186F83A6C89 for ; Wed, 24 Jun 2009 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlAAFWD2Jtwc for ; Wed, 24 Jun 2009 09:20:14 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 555433A6CBB for ; Wed, 24 Jun 2009 09:20:13 -0700 (PDT) Received: by ewy6 with SMTP id 6so1346311ewy.37 for ; Wed, 24 Jun 2009 09:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fBKVKBEVp5367UlJ5mCiNYrRjaElONMKQFyzQa/42RQ=; b=Br6YstNSxlXmBMwthPllWrjRZpGGIbL6eh1F2d6lfow36FQJ/qF6FpyKS+Mr9kXHA9 R9ITsFM/0uOycufoWowsyv6Hll2g9s4gwadSYkly5ZLb3yMPscqKQMycwghcsDuu2qoN kLJuwXv63leb93o3cy1ihG/fKnMmq7Iv+W+t4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IDc9nRTdp4dpDduYuk3w2zjwZ52cLkpdPjz1TekAEbTpMGbSHJHY1JAJrBCoBgvSS4 l9zL1pKcdu9KL9smUnvisstDf0Y9JSiNh8NmGKHnZ1pL0e5yn8C3bA2C6UGkHV73wMHI v+G3axUavMon/EK2pBICPMy4S6xO4qBKDAATI= MIME-Version: 1.0 Received: by 10.216.46.83 with SMTP id q61mr458522web.71.1245860331260; Wed, 24 Jun 2009 09:18:51 -0700 (PDT) In-Reply-To: <4A41B4A9.5090202@nict.go.jp> References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> <4A409349.8030808@nict.go.jp> <5e2406980906230935l6719309fj3ea3d07017d43e51@mail.gmail.com> <4A41B4A9.5090202@nict.go.jp> Date: Wed, 24 Jun 2009 18:18:51 +0200 Message-ID: <5e2406980906240918p299793bbpd4c7f0e7401f1935@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016e64c39dc7c0ab8046d1a76ee Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 16:20:16 -0000 --0016e64c39dc7c0ab8046d1a76ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, inline On Wed, Jun 24, 2009 at 7:07 AM, Sebastien Decugis wrote: > > > It was presented during Virtual Interim meeting last February. You > can > > still find the slides there: > > > http://trac.tools.ietf.org/wg/dime/trac/attachment/wiki/ConferenceBridge/diameter-erp.pdf > > The advantages of a separate Diameter application ID are > > highlighted in > > slide #8. > > > > > > ok, so I guess we are talking about the routing issue in case of a > > handover. > This is the main reason for this proposed change, but there may be other > advantages (possibility to detect if ERP is supported during the CER/CEA > exchange, for example). > > > Then, I still don't see what a new application id solves here. If I > > have multiple ERP servers in the visited or home, how does the target > > authenticator knows to which ERP servers it shall send its request ?? > I don't think there is an issue here. The question should be asked in > the HOKEY group, since it's an ERP concern, not Diameter, AFAICT. hmm, that is the issue. The local ERP server has the keying material. The target NAS must know the local ERP server to contact. This is exactly the same issue with or w/o an Application-ID in my view. > > If you use EAP application id, your local ERP Diameter proxy have to be > on the path of all EAP messages for both local and foreign realms coming > from a NAS in the local domain, and also all EAP messages coming from > other realms to the local EAP server. I think this requirement is very > difficult to achieve, and leads to a huge load of this proxy. for a Diameter Session (let's say during the EAP authentication), the local NAS will use a Diameter Proxy and the Diameter proxy will use the home Diameter server. We are not going to change the AAA path during the session. Am I missing something ? > > By having a different application ID, you can configure the routing > differently for ERP messages and for "normal" EAP messages. This > provides more flexibility in the deployment, which is always a good > thing IMHO. > I can't think of any inconvenient of having a separate application ID > for ERP compared to reusing the EAP application ID. In any case the > support for ERP cannot be added "transparently" since ERP requires > modifications of the EAP server and the NAS (regardless of Diameter). I don't see what it solves for our issue. I'd be glad to hear other opinions. > > > > > I guess we all agree that we have a routing issue. But it could be > > good to summarize > > clearly the routing issue in case of ERP. And then to explain how > > Application-Id solves it. > Do you think this should be put in the document, or discussed on this > mailing-list (or both) ? At least on the ML. Regards, Julien > > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --0016e64c39dc7c0ab8046d1a76ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

=A0inline

On Wed, Jun 24, 2= 009 at 7:07 AM, Sebastien Decugis <sdecugis@nict.go.jp> wrote:
<snip>
> =A0 =A0 It was presented during Virtual Interim meeting last February.= You can
> =A0 =A0 still find the slides there:
> =A0 =A0 http://trac.tools= .ietf.org/wg/dime/trac/attachment/wiki/ConferenceBridge/diameter-erp.pdf
> =A0 =A0 The advantages of a separate Diameter application ID are
> =A0 =A0 highlighted in
> =A0 =A0 slide #8.
>
>
> =A0ok, so I guess we are talking about the routing issue in case of a<= br> > handover.
This is the main reason for this proposed change, but there may be ot= her
advantages (possibility to detect if ERP is supported during the CER/CEA exchange, for example).

> =A0Then, I still don't see what a new application id solves here. = If I
> have multiple ERP servers in the visited or home, how does the target<= br> > authenticator knows to which ERP servers it shall send its request ??<= br>
I don't think there is an issue here. The question should be aske= d in
the HOKEY group, since it's an ERP concern, not Diameter, AFAICT.

hmm, that is the issue. The local ERP server has the keying= material. The target NAS must know the local ERP server to contact. This i= s exactly the same issue with or w/o an Application-ID in my view.
=A0

If you use EAP application id, your local ERP Diameter proxy have to = be
on the path of all EAP messages for both local and foreign realms coming from a NAS in the local domain, and also all EAP messages coming from
other realms to the local EAP server. I think this requirement is very
difficult to achieve, and leads to a huge load of this proxy.
<= div>
for a Diameter Session (let's say during the EAP authentication= ), the local NAS will use a Diameter Proxy and the Diameter proxy will use = the home Diameter server. We are not going to change the AAA path during th= e session.

Am I missing something ?
=A0

By having a different application ID, you can configure the routing
differently for ERP messages and for "normal" EAP messages. This<= br> provides more flexibility in the deployment, which is always a good
thing IMHO.
I can't think of any inconvenient of having a separate application ID for ERP compared to reusing the EAP application ID. =A0In any case the
support for ERP cannot be added "transparently" since ERP require= s
modifications of the EAP server and the NAS (regardless of Diameter).


I don't see what it solves for our issue. I'd b= e glad to hear other opinions.
=A0

>
> I guess we all agree that we have a routing issue. But it could be
> good to summarize
> clearly the routing issue in case of ERP. And then to explain how
> Application-Id solves it.
Do you think this should be put in the document, or discussed on this=
mailing-list (or both) ?

At least on the ML.

Re= gards,

=A0Julien
=A0


--0016e64c39dc7c0ab8046d1a76ee-- From dromasca@avaya.com Wed Jun 24 10:13:07 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A403A6FA5 for ; Wed, 24 Jun 2009 10:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBS9inZ9eaxk for ; Wed, 24 Jun 2009 10:13:06 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 0780C3A6CA2 for ; Wed, 24 Jun 2009 10:13:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,284,1243828800"; d="scan'208";a="165287061" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 24 Jun 2009 13:12:33 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Jun 2009 13:12:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 19:12:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review for draft-ietf-dime-diameter-qos-08.txt thread-index: Acn07ujvnQJ7sPNtQsW/Hl4Bloxxig== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review for draft-ietf-dime-diameter-qos-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 17:13:07 -0000 Please find below the AS review for draft-ietf-dime-diameter-qos-08.txt. I believe that there is a need for a revised ID before going to IETF Last Call in order to clarify a number of questions and fix a few more.=20 The comments below are divided into Technical and Editorial. T1. Can the QoS application support multiple concurrent sessions between an NE and an AE? I think that we need to clarify and add adequate text. T2. Can an NE work with multiple AEs? The security considerations section mentions this as a problem but provides no hints as to how to solve it. I think that we need to clarify and add adequate text. T3. Are different modes of operation supported for a given NE? I think that we need to clarify and add adequate text. T4. The Terminology section mentions that an AE corresponds to an RFC 2573 PDP and an NE corresponds to an RFC 2573 PEP. I am wondering why we go through the pain of inventing a new set of terms (AE, NE) and we do not just use the 2573 terminology all over.=20 T5. In Section 2 - 'For example, a SIP Agent is one kind of Application Endpoint.' - is this a SIP User Agent?=20 T6.In section 4.2.1=20 The AE's identity, information about the application session and/or identity and credentials of the QoS RRE, requested QoS parameters, signaling session identifier and/or QoS enabled data flows identifiers MAY be encapsulated into respective Diameter AVPs and included in the Diameter message sent to the AE. =20 Why is this a MAY? Is there another way to pass AE identity information at session establishment (assuming we are doing Diameter and not something else) T7. In the table the data type of the QoS-Authorization-Data attribute is Grouped, while in the textual description it shows as OctetString T8. I find the security considerations section weak. I suggest that for each threat the security mechanisms within Diameter or external to Diameter that can be used for protection be explicitly mentioned.=20 T9. Logging for security events related to authentication and authorization should be enhanced by sending alerts to a management system (if available) T10. 'Failing to provide the required credentials should be subject to logging.'. Why is this a non-capitalized should and not a capitalized MUST?=20 E1. Potential problems detected by idnits:=20 Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, = but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).=20 trust-12-feb-2009 Section 6.c.iii text: "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." Checking references for intended status: Proposed Standard =20 ------------------------------------------------------------------------ ---- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ... =3D=3D Outdated reference: A later version (-12) exists of draft-ietf-dime-qos-attributes-11 =3D=3D Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-10 ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) =3D=3D Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-19 -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) E2. In section 3.1=20 Note that the parameters passed to the Traffic Control function may be different from requested QoS (depending on the authorization decision).=20 should rather be Note that the parameters passed to the Traffic Control function may be different from the ones in the requested QoS (depending on the authorization decision).=20 E3. In section 3.2.2 page 13: either Push mode or Pull mode may be used Better to use MAY with 2119 capitalization E4. The language used in the requirements in section 3.4 is confusing. Many of the requirements are being expressed on the 'QoS AAA protocol' - should not they be rather on the 'Diameter QoS application'?=20 E5. The term 'Bearer' in the Bearer Gating requirement should probably be replaced with some other more IP-friendly term E6. In the Accounting Correlation requirement 'may' should be capitalized to MAY E7. In the 'Interaction with other AAA Applications' required should be capitalized to REQUIRED E8.=20 Authentication of the QoS reservation requesting entity to the AE is necessary if a particular Diameter QoS application protocol run cannot be related (or if there is no intention to relate it) to a prior authentication.=20 Something is missing or wrong here. What is a 'Diameter QoS application protocol run'?=20 E9. In Section 4.2.1 The NE generates a QAR message in which the required objects from the QoS signaling message that is converted to Diameter AVPs. Bad syntax makes this phrase impossible to understand. E10. In Section 4.2.2 The indication of QoS reservation and activation of the data flow can be provided by the QoS-Install-Answer message immediately. In the case of successful enforcement, the Result-Code (=3D = DIAMETER_SUCCESS, (see Section 7.1)) information is provided in the QIA message. Note that the reserved QoS resources reported in the QIA message MAY be different than those initially authorized with the QIR message, due to the QoS signaling specific behavior (e.g., receiver-initiated reservations with One-Path-With-Advertisements) or specific process of QoS negotiation along the data path. When path coupled signaling is used for QoS reservation along the data path, QAR/QAA may be used to update the results of QoS reservation and enforcement following the establishment of data flows. The usage of keywords seems to be wrong in this paragraph. The first MAY should rather be a 'may' while in the last phrase the 'may' seems to indicate a requirement, so it should rather be capitalized as MAY. E11. Last sentence in section 4.2.3 s/or globally routable IP address/or a globally routable IP address/ E12. In section 5 s/Diameter nodes conforming to this specification MAY advertise support by including/Diameter nodes conforming to this specification MAY advertise support for the Diameter QoS Application by including/ =20 E13. It is recommended to put all the ABNF definitions in section 5 in an Annex that can also include in one place the copyright notice.=20 E14. In section 6/1 s/This MUST be supported/These MUST be supported/ =20 Thanks and Regards, Dan From sdecugis@nict.go.jp Wed Jun 24 19:19:35 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5723F28C4DA for ; Wed, 24 Jun 2009 19:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsxsW-QtzuiR for ; Wed, 24 Jun 2009 19:19:34 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id E8C3D28C160 for ; Wed, 24 Jun 2009 19:19:33 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n5P2JhOT024094; Thu, 25 Jun 2009 11:19:43 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n5P2Jh4b010767; Thu, 25 Jun 2009 11:19:43 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n5P2JhIT010764; Thu, 25 Jun 2009 11:19:43 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 847FF16575; Thu, 25 Jun 2009 11:19:43 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 7DD0216574; Thu, 25 Jun 2009 11:19:43 +0900 (JST) Message-ID: <4A42DEBC.6090305@nict.go.jp> Date: Thu, 25 Jun 2009 11:19:40 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> <4A409349.8030808@nict.go.jp> <5e2406980906230935l6719309fj3ea3d07017d43e51@mail.gmail.com> <4A41B4A9.5090202@nict.go.jp> <5e2406980906240918p299793bbpd4c7f0e7401f1935@mail.gmail.com> In-Reply-To: <5e2406980906240918p299793bbpd4c7f0e7401f1935@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 02:19:35 -0000 > If I > > have multiple ERP servers in the visited or home, how does the > target > > authenticator knows to which ERP servers it shall send its > request ?? > I don't think there is an issue here. The question should be asked in > the HOKEY group, since it's an ERP concern, not Diameter, AFAICT. > > > hmm, that is the issue. The local ERP server has the keying material. > The target NAS must know the local ERP server to contact. This is > exactly the same issue with or w/o an Application-ID in my view. To me, it's just a routing configuration, I still don't see the issue, sorry... If you want to have several ERP servers in the home domain, I guess you'd have to keep the key cache in sync, or share a database, or some similar mechanism. As I wrote, this is a question for HOKEY (i.e. it concerns ERP), not Diameter. > for a Diameter Session (let's say during the EAP authentication), the > local NAS will use a Diameter Proxy and the Diameter proxy will use > the home Diameter server. We are not going to change the AAA path > during the session. Nothing guarantees that the path does not change, AFAIK. Anyway, this is not really the problem. The ER server in local domain must be on the path of the following exchanges if you use the EAP application ID: -> first and last row of full EAP exchange of a visiting peer, if you use implicit bootstrapping (username: user@home, dest-realm: home) -> Re-authentication with bootstrapping, if you use explicit bootstrapping (better IMHO, as it provides ERP only to peers that really use it): (username: keyname@home, dest-realm: home) -> Simple re-authentication: (username: keyname@local, dest-realm: local) -> local peers visiting a foreign network: (username: user@local, dest-realm: local). Basically, all messages with EAP application ID to or from the local domain would have to go through this proxy. I doubt the scalability of such design. With a separate application ID for ERP, only re-authentication exchanges would reach the proxy, which unloads it a lot. (I assume that re-authentications are far less frequent than full authentications) > I'd be glad to hear other opinions. Me too :) Thanks, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Wed Jun 24 19:21:32 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9323A6DAA for ; Wed, 24 Jun 2009 19:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVoAy8ceu1tc for ; Wed, 24 Jun 2009 19:21:32 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id B02A128C4FA for ; Wed, 24 Jun 2009 19:21:31 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n5P2LjWB023653; Thu, 25 Jun 2009 11:21:45 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n5P2Ljth008208; Thu, 25 Jun 2009 11:21:45 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n5P2LjF4008205; Thu, 25 Jun 2009 11:21:45 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 16ABA16436; Thu, 25 Jun 2009 11:21:45 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 11E661642F; Thu, 25 Jun 2009 11:21:45 +0900 (JST) Message-ID: <4A42DF36.4000906@nict.go.jp> Date: Thu, 25 Jun 2009 11:21:42 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> <5e2406980906230941x7c74915eqe754c30d335d04f0@mail.gmail.com> <4A41AE75.7090103@nict.go.jp> <5e2406980906240913o73ba4327p614a4bfdf51e1110@mail.gmail.com> In-Reply-To: <5e2406980906240913o73ba4327p614a4bfdf51e1110@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 02:21:32 -0000 > Let's make it simple: > The home AAA/EAP server must know to which NAS the UE is currently > attached. That's my issue. Do you mean at any time during the lifetime of the authentication? Why would it need to know this? Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From julien.bournelle@gmail.com Wed Jun 24 20:29:12 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC093A6F26 for ; Wed, 24 Jun 2009 20:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M61RMTk9joc9 for ; Wed, 24 Jun 2009 20:29:10 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 71F5E3A6813 for ; Wed, 24 Jun 2009 20:29:08 -0700 (PDT) Received: by ewy6 with SMTP id 6so1836681ewy.37 for ; Wed, 24 Jun 2009 20:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NdQTbKYFvOmlKIshqDP3Q9lUFiYyYp0QRNEVXSEQoRk=; b=a79FY1JObMcn2duCHmheJMFV8LXN6nRx/s1Px8IO9YFjXhutNmueEdQEzAkalyjJtn ShYY8o8txuhBRkQYhZe4Qk/nkqBNmeOF2RIYtO6yT76ThKSGJp/F/lxs6HfpSIDaq6qT XSnO67OPdJzveHSRpb/eCV8s5QcDf//71A7zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Fjy3EipNLmoJ1A33Ut34pXcu3OjFYrwCDxJc+Q/o4/078BAvi6efTX0vPHLIae1rVk HPZcf6KIBbttqZNeLT+cwlxkZZSwoQtlx3SjbNINuOE/gpLBU4iLF25mXEp6dXFXPFP7 QzQd7Lu6VjqR+dGKrhL1Lpg8706M6H0DlmI7I= MIME-Version: 1.0 Received: by 10.216.35.69 with SMTP id t47mr594145wea.221.1245900491291; Wed, 24 Jun 2009 20:28:11 -0700 (PDT) In-Reply-To: <4A42DEBC.6090305@nict.go.jp> References: <4A2C8C10.1010507@nict.go.jp> <5e2406980906170537t64298af0y36b4640b97552fa4@mail.gmail.com> <5e2406980906170618t5451bad1i9cef9499f9d5054@mail.gmail.com> <4A409349.8030808@nict.go.jp> <5e2406980906230935l6719309fj3ea3d07017d43e51@mail.gmail.com> <4A41B4A9.5090202@nict.go.jp> <5e2406980906240918p299793bbpd4c7f0e7401f1935@mail.gmail.com> <4A42DEBC.6090305@nict.go.jp> Date: Thu, 25 Jun 2009 05:28:11 +0200 Message-ID: <5e2406980906242028v74964b18if97e6f0f6699d33e@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016367f9e54357e55046d23d00a Cc: dime@ietf.org Subject: Re: [Dime] New draft for Diameter ERP: poll for adoption X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 03:29:12 -0000 --0016367f9e54357e55046d23d00a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, On Thu, Jun 25, 2009 at 4:19 AM, Sebastien Decugis wrote: > > > If I > > > have multiple ERP servers in the visited or home, how does the > > target > > > authenticator knows to which ERP servers it shall send its > > request ?? > > I don't think there is an issue here. The question should be asked in > > the HOKEY group, since it's an ERP concern, not Diameter, AFAICT. > > > > > > hmm, that is the issue. The local ERP server has the keying material. > > The target NAS must know the local ERP server to contact. This is > > exactly the same issue with or w/o an Application-ID in my view. > To me, it's just a routing configuration, I still don't see the issue, > sorry... > If you want to have several ERP servers in the home domain, I guess > you'd have to keep the key cache in sync, or share a database, or some > similar mechanism. As I wrote, this is a question for HOKEY (i.e. it > concerns ERP), not Diameter. > > > for a Diameter Session (let's say during the EAP authentication), the > > local NAS will use a Diameter Proxy and the Diameter proxy will use > > the home Diameter server. We are not going to change the AAA path > > during the session. > Nothing guarantees that the path does not change, AFAIK. Anyway, this is > not really the problem. > The ER server in local domain must be on the path of the following > exchanges if you use the EAP application ID: > -> first and last row of full EAP exchange of a visiting peer, if you > use implicit bootstrapping > (username: user@home, dest-realm: home) > -> Re-authentication with bootstrapping, if you use explicit > bootstrapping (better IMHO, as it provides ERP only to peers that really > use it): > (username: keyname@home, dest-realm: home) > -> Simple re-authentication: > (username: keyname@local, dest-realm: local) > -> local peers visiting a foreign network: > (username: user@local, dest-realm: local). > > Basically, all messages with EAP application ID to or from the local > domain would have to go through this proxy. I doubt the scalability of > such design. > > With a separate application ID for ERP, only re-authentication exchanges > would reach the proxy, which unloads it a lot. (I assume that > re-authentications are far less frequent than full authentications) I still don't see the difference between requiring the same AAA/EAP proxy on the path (if Diameter EAP Application) and requiring that the new NAS contact the same local ERP server that was in the initial path (Diameter ERP). Regards, Julien > > > I'd be glad to hear other opinions. > Me too :) > > > Thanks, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --0016367f9e54357e55046d23d00a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Thu, Jun 25, 2009 at 4:19 AM, S= ebastien Decugis <sdecugis@nict.go.jp> wrote:

> =A0 =A0 If I
> =A0 =A0 > have multiple ERP servers in the visited or home, how doe= s the
> =A0 =A0 target
> =A0 =A0 > authenticator knows to which ERP servers it shall send it= s
> =A0 =A0 request ??
> =A0 =A0 I don't think there is an issue here. The question should = be asked in
> =A0 =A0 the HOKEY group, since it's an ERP concern, not Diameter, = AFAICT.
>
>
> hmm, that is the issue. The local ERP server has the keying material.<= br> > The target NAS must know the local ERP server to contact. This is
> exactly the same issue with or w/o an Application-ID in my view.
To me, it's just a routing configuration, I still don't see t= he issue,
sorry...
If you want to have several ERP servers in the home domain, I guess
you'd have to keep the key cache in sync, or share a database, or some<= br> similar mechanism. As I wrote, this is a question for HOKEY (i.e. it
concerns ERP), not Diameter.

> for a Diameter Session (let's say during the EAP authentication), = the
> local NAS will use a Diameter Proxy and the Diameter proxy will use > the home Diameter server. We are not going to change the AAA path
> during the session.
Nothing guarantees that the path does not change, AFAIK. Anyway, this= is
not really the problem.
The ER server in local domain must be on the path of the following
exchanges if you use the EAP application ID:
=A0-> first and last row of full EAP exchange of a visiting peer, if you=
use implicit bootstrapping
(username: user@home, dest-realm: home)
-> Re-authentication with bootstrapping, if you use explicit
bootstrapping (better IMHO, as it provides ERP only to peers that really use it):
(username: keyname@home, dest-realm: home)
-> Simple re-authentication:
(username: keyname@local, dest-realm: local)
-> local peers visiting a foreign network:
(username: user@local, dest-realm: local).

Basically, all messages with EAP application ID to or from the local
domain would have to go through this proxy. I doubt the scalability of
such design.

With a separate application ID for ERP, only re-authentication exchanges would reach the proxy, which unloads it a lot. (I assume that
re-authentications are far less frequent than full authentications)


I still don't see the difference between requiring th= e same AAA/EAP proxy on the path (if Diameter EAP Application) and requirin= g that the new NAS contact the same local ERP server that was in the initia= l path (Diameter ERP).
=A0
=A0Regards,

=A0Julien



> I'd be glad to hear other opinions.
Me too :)


Thanks,
Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)


--0016367f9e54357e55046d23d00a-- From julien.bournelle@gmail.com Wed Jun 24 20:40:19 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8AA3A6B4B for ; Wed, 24 Jun 2009 20:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxt0GrM06w7b for ; Wed, 24 Jun 2009 20:40:18 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id EF0DB3A69DE for ; Wed, 24 Jun 2009 20:40:17 -0700 (PDT) Received: by ewy6 with SMTP id 6so1841618ewy.37 for ; Wed, 24 Jun 2009 20:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=QkaVqfB3QQbs/rE+7UH520iernZdpKKktjw6hMlAH8Y=; b=XJZdWH+HJI6FPiWNRh16kYGlrnDCxFg2ITMCIB2Kenew4YjxkXWlFT69/Sb33OqExB CXRgyYUjOlteYpa1JddmRqjbeFLsCV3BrXscA+bD6Cr0DcNbnAexc6dF4uP58RiykdiP 7LaMtA+7TASHa02e+HPhj8WM7HzN7h7kvPDDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=HNBM/TlDYnt5e0aKpFMzUuH50xkGAStjSYl/WHWbGOLQv8fWLMisG+IfcPyojeBMnl JD6quoIS9cdFQIfKUy0OlaS7E3d93btA0TnyJb0LyMDUcoM1QnQ8cMf2tfI19I1lz+IA qPso505TcNC+8kcm7dgLlOgxmukS3F16Ii7yE= MIME-Version: 1.0 Received: by 10.216.26.80 with SMTP id b58mr617878wea.35.1245900743137; Wed, 24 Jun 2009 20:32:23 -0700 (PDT) Date: Thu, 25 Jun 2009 05:32:23 +0200 Message-ID: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=001485f423dc385874046d23df8e Cc: dime@ietf.org Subject: Re: [Dime] Does the home AAA/EAP server must know the current NAS ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 03:40:19 -0000 --001485f423dc385874046d23df8e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, On Thu, Jun 25, 2009 at 4:21 AM, Sebastien Decugis wrote: > > > Let's make it simple: > > The home AAA/EAP server must know to which NAS the UE is currently > > attached. That's my issue. > > Do you mean at any time during the lifetime of the authentication? Why > would it need to know this? Because the AAA server may maintain a state for a UE. If it wants to disconnect it for whatever reason, it must be able to send a STR to the correct NAS. Regards, Julien > > > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --001485f423dc385874046d23df8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Thu, Jun 25, 2009 at 4:21 AM, S= ebastien Decugis <sdecugis@nict.go.jp> wrote:

> Let's make it simple:
> The home AAA/EAP server must know to which NAS the UE is currently
> attached. That's my issue.

Do you mean at any time during the lifetime of the authentication? Wh= y
would it need to know this?

Because the AAA server may= maintain a state for a UE. If it wants to disconnect it for whatever reaso= n, it must be able to send a STR to the correct NAS.

Regards,

=A0Julien
=A0


Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)


--001485f423dc385874046d23df8e-- From sdecugis@nict.go.jp Wed Jun 24 21:00:57 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2762C3A694C for ; Wed, 24 Jun 2009 21:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s-CkBoqeBUz for ; Wed, 24 Jun 2009 21:00:56 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id D8BA73A68E7 for ; Wed, 24 Jun 2009 21:00:55 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n5P4186D008829; Thu, 25 Jun 2009 13:01:08 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n5P4188E007587; Thu, 25 Jun 2009 13:01:08 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n5P418sX007584; Thu, 25 Jun 2009 13:01:08 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 580FD16576; Thu, 25 Jun 2009 13:01:08 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 5222116569; Thu, 25 Jun 2009 13:01:08 +0900 (JST) Message-ID: <4A42F67F.6020108@nict.go.jp> Date: Thu, 25 Jun 2009 13:01:03 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> In-Reply-To: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Does the home AAA/EAP server must know the current NAS ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 04:00:57 -0000 Hi, > > The home AAA/EAP server must know to which NAS the UE is currently > > attached. That's my issue. > > > Do you mean at any time during the lifetime of the authentication? Why > would it need to know this? > > > Because the AAA server may maintain a state for a UE. If it wants to > disconnect it for whatever reason, it must be able to send a STR to > the correct NAS. I see. This must be added to the "to do" things on Diameter ERP then (this also is not correlated to the app id choice anyway). Any idea how to achieve this? (maybe some ideas can be borrowed from MIPv6?) Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From glenzorn@comcast.net Wed Jun 24 23:02:38 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F05A28C142 for ; Wed, 24 Jun 2009 23:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyeEWLKsCpRy for ; Wed, 24 Jun 2009 23:02:38 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 2BF293A68E7 for ; Wed, 24 Jun 2009 23:02:37 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 85xE1c0090EZKEL595xLFl; Thu, 25 Jun 2009 05:57:20 +0000 Received: from gwzPC ([124.122.162.191]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 85wo1c001484iLk3M5wtij; Thu, 25 Jun 2009 05:57:05 +0000 From: "Glen Zorn" To: References: <20090623203001.ACE0C3A6D27@core3.amsl.com> In-Reply-To: <20090623203001.ACE0C3A6D27@core3.amsl.com> Date: Thu, 25 Jun 2009 12:53:15 +0700 Message-ID: <00dd01c9f559$462f76e0$d28e64a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acn0Qb+Fc+7TmZvaSYShdYsY18mTMQBDUO6g Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 06:02:38 -0000 > A modified charter has been submitted for the Diameter Maintenance and > Extensions (dime) working group in the Operations and Management Area > of > the IETF. The IESG has not made any determination as yet. The > modified > charter is provided below for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June > 30, 2009. An email "hum" regarding the adoption of http://www.ietf.org/internet-drafts/draft-tsou-dime-realm-based-redirect-00. txt as a chartered working group item was begun on 12 June (http://www.ietf.org/mail-archive/web/dime/current/msg03595.html). The "hum" period ends tomorrow, yet the new charter has already been submitted to the IESG. Apparently there has been some unintentional oversight. ... From dromasca@avaya.com Thu Jun 25 01:38:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE27F3A6ADD; Thu, 25 Jun 2009 01:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cnI1ds0XmgT; Thu, 25 Jun 2009 01:38:37 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id B4AB33A6C3F; Thu, 25 Jun 2009 01:38:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,289,1243828800"; d="scan'208";a="165351438" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 25 Jun 2009 04:37:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jun 2009 04:37:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 10:37:37 +0200 Message-ID: In-Reply-To: <00dd01c9f559$462f76e0$d28e64a0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Diameter Maintenance and Extensions(dime) thread-index: Acn0Qb+Fc+7TmZvaSYShdYsY18mTMQBDUO6gAAfLFXA= References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , Cc: dime@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 08:38:37 -0000 Glen, Rechartering and the "hum" for adoption of a document as WG item need not be necessarily serialized. Rechartering is about approving to work on a specific problem. The "hum" acknowledges (or not) that a certain document is good enough to be the 00 version of the WG I-D that will provide a solution to the problem. Of course, if rechartering is not approved the "hum" will not have any effect, but otherwise some time may be won by runing the "hum" and the rechartering review in parallel.=20 Dan > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Glen Zorn > Sent: Thursday, June 25, 2009 8:53 AM > To: iesg@ietf.org > Cc: 'Hannes Tschofenig'; dime@ietf.org; vfajardo@tari.toshiba.com > Subject: RE: WG Review: Recharter of Diameter Maintenance and=20 > Extensions(dime)=20 >=20 > > A modified charter has been submitted for the Diameter=20 > Maintenance and=20 > > Extensions (dime) working group in the Operations and=20 > Management Area=20 > > of the IETF. The IESG has not made any determination as yet. The=20 > > modified charter is provided below for informational=20 > purposes only. =20 > > Please send your comments to the IESG mailing list=20 > (iesg@ietf.org) by=20 > > Tuesday, June 30, 2009. >=20 > An email "hum" regarding the adoption of=20 > http://www.ietf.org/internet-drafts/draft-tsou-dime-realm-base > d-redirect-00. > txt as a chartered working group item was begun on 12 June=20 > (http://www.ietf.org/mail-archive/web/dime/current/msg03595.ht > ml). The "hum" period ends tomorrow, yet the new charter has=20 > already been submitted to the IESG. Apparently there has=20 > been some unintentional oversight. >=20 > ... >=20 >=20 From glenzorn@comcast.net Thu Jun 25 02:32:53 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7455D3A69FC for ; Thu, 25 Jun 2009 02:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLGMCTfjj3PN for ; Thu, 25 Jun 2009 02:32:53 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 3DE6428C136 for ; Thu, 25 Jun 2009 02:32:53 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 89XT1c0030EPchoAA9XTEb; Thu, 25 Jun 2009 09:31:27 +0000 Received: from gwzPC ([124.122.162.191]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id 89X41c002484iLk8M9XAWi; Thu, 25 Jun 2009 09:31:25 +0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> In-Reply-To: Date: Thu, 25 Jun 2009 16:27:17 +0700 Message-ID: <00f901c9f577$2e9c2c30$8bd48490$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acn0Qb+Fc+7TmZvaSYShdYsY18mTMQBDUO6gAAfLFXAAAV7O0A== Content-Language: en-us Cc: dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 09:32:53 -0000 Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: > Glen, > > Rechartering and the "hum" for adoption of a document as WG item need > not be necessarily serialized. Rechartering is about approving to work > on a specific problem. The "hum" acknowledges (or not) that a certain > document is good enough to be the 00 version of the WG I-D that will > provide a solution to the problem. Of course, if rechartering is not > approved the "hum" will not have any effect, but otherwise some time > may > be won by runing the "hum" and the rechartering review in parallel. I see. Unfortunately, I can't see any mention of the problem in the revised charter, either, unless it is your opinion that realm-based redirection would be an extension to the Diameter Base Protocol (not unreasonable). On a different topic: the new charter contains the sentence "There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter." This is an incredibly poor idea: it's bad enough to persist in allowing RADIUS to be "extended" (though there's little real danger of that happening in the radext WG ;-), but to tie Diameter & RADIUS together at the hip is practically criminal. Backward compatibility with RADIUS is fine; on-going, _forward_ compatibility is not. This was discussed, as you know, on the dime list with no objections to the idea of limiting RADIUS-Diameter compatibility; however the offending sentence remains. ... From dromasca@avaya.com Thu Jun 25 02:43:11 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601BD3A6BE6; Thu, 25 Jun 2009 02:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUzZQMhBogOp; Thu, 25 Jun 2009 02:43:10 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id E04EC3A69FC; Thu, 25 Jun 2009 02:43:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,289,1243828800"; d="scan'208";a="149539772" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jun 2009 05:40:43 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jun 2009 05:40:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 11:40:04 +0200 Message-ID: In-Reply-To: <00f901c9f577$2e9c2c30$8bd48490$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Diameter Maintenance and Extensions(dime) thread-index: Acn0Qb+Fc+7TmZvaSYShdYsY18mTMQBDUO6gAAfLFXAAAV7O0AABEFOw References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 09:43:11 -0000 =20 > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@comcast.net]=20 > Sent: Thursday, June 25, 2009 12:27 PM > To: Romascanu, Dan (Dan) > Cc: 'Hannes Tschofenig'; dime@ietf.org;=20 > vfajardo@tari.toshiba.com; iesg@ietf.org > Subject: RE: WG Review: Recharter of Diameter Maintenance and=20 > Extensions(dime)=20 >=20 > Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: >=20 > > Glen, > >=20 > > Rechartering and the "hum" for adoption of a document as WG=20 > item need=20 > > not be necessarily serialized. Rechartering is about=20 > approving to work=20 > > on a specific problem. The "hum" acknowledges (or not) that=20 > a certain=20 > > document is good enough to be the 00 version of the WG I-D=20 > that will=20 > > provide a solution to the problem. Of course, if=20 > rechartering is not=20 > > approved the "hum" will not have any effect, but otherwise=20 > some time=20 > > may be won by runing the "hum" and the rechartering review in=20 > > parallel. >=20 > I see. Unfortunately, I can't see any mention of the problem=20 > in the revised charter, either, unless it is your opinion=20 > that realm-based redirection would be an extension to the=20 > Diameter Base Protocol (not unreasonable).=20 Something on this lines. The WG decided to use extensions as a generic denomination of many applications of various kinds so that the text needs not be changed each time. There is always an opportunity to express concerns when a deliverable is out of what would be a reasonable extension.=20 >=20 > On a different topic: the new charter contains the sentence=20 > "There is on-going work on defining RADIUS extensions and the=20 > DIME WG will ensure that work done in RADEXT is also=20 > available for Diameter." This is an incredibly poor idea:=20 > it's bad enough to persist in allowing RADIUS to be "extended" > (though there's little real danger of that happening in the=20 > radext WG ;-), but to tie Diameter & RADIUS together at the=20 > hip is practically criminal. > Backward compatibility with RADIUS is fine; on-going,=20 > _forward_ compatibility is not. This was discussed, as you=20 > know, on the dime list with no objections to the idea of=20 > limiting RADIUS-Diameter compatibility; however the offending=20 > sentence remains. >=20 I am not sure that the intention of this sentence is such a tight interdependence or forward compatibility as you fear. I would let however Hannes and Victor to comment first,=20 Dan > ... >=20 >=20 From jouni.nospam@gmail.com Thu Jun 25 03:33:18 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7A63A6A78; Thu, 25 Jun 2009 03:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qP0GJ3nx34U; Thu, 25 Jun 2009 03:33:17 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 21AD03A6950; Thu, 25 Jun 2009 03:33:16 -0700 (PDT) Received: by bwz9 with SMTP id 9so1295969bwz.37 for ; Thu, 25 Jun 2009 03:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=HN4mLOPR44NV7U3/JxCwmSa6qnD4JwkZZ3aPW+tK1pY=; b=p1GO4cOsJnEDpECmUdYjTBKt4aVENVGdQRDIatM3SXOSauny5myTIVPL50bqR3t1TW /DQlqRFt3Qfb2HtJG/3HdMR0+hbTVG0vnsv1kONS0kN4K/i3YrpPahj0ueRUagzmrWtc V13Qi6NfIwIv7JdDYVSUBKsb/eDSYw2wttNfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=tb18s2FsxCPdRbeanzBtGlKWMVDwn8BukL9jH1Ozwvf87r4CDW/JNyXGihoG5fdxq2 I/JcVWXCGYVPVffVaMFzEhFoDBQDzmPKGVXxI5tR7WK7Pn+vcfVZyNK/ntgh1EuX2gZB UJzPa1KLdOG6Dw1/fu9ulP0a8zfVGObL2qo50= Received: by 10.204.71.68 with SMTP id g4mr2340965bkj.81.1245925903312; Thu, 25 Jun 2009 03:31:43 -0700 (PDT) Received: from a88-112-140-213.elisa-laajakaista.fi (a88-112-140-213.elisa-laajakaista.fi [88.112.140.213]) by mx.google.com with ESMTPS id 9sm3204068fks.58.2009.06.25.03.31.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 03:31:42 -0700 (PDT) Message-Id: From: jouni korhonen To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 13:31:41 +0300 References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org, Glen Zorn , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 10:33:18 -0000 Hi, On Jun 25, 2009, at 12:40 PM, Romascanu, Dan (Dan) wrote: [snip] >> >> >> On a different topic: the new charter contains the sentence >> "There is on-going work on defining RADIUS extensions and the >> DIME WG will ensure that work done in RADEXT is also >> available for Diameter." This is an incredibly poor idea: >> it's bad enough to persist in allowing RADIUS to be "extended" >> (though there's little real danger of that happening in the >> radext WG ;-), but to tie Diameter & RADIUS together at the >> hip is practically criminal. >> Backward compatibility with RADIUS is fine; on-going, >> _forward_ compatibility is not. This was discussed, as you >> know, on the dime list with no objections to the idea of >> limiting RADIUS-Diameter compatibility; however the offending >> sentence remains. >> > > I am not sure that the intention of this sentence is such a tight > interdependence or forward compatibility as you fear. I would let > however Hannes and Victor to comment first, I posted on this topic already earlier (probably missed in the mail flood). I share the concern Glen has regarding the RADIUS compatibility. Cheers, Jouni > > > Dan > >> ... >> >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Thu Jun 25 07:00:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AB93A6C8A; Thu, 25 Jun 2009 07:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9-zUkvK6gN7; Thu, 25 Jun 2009 07:00:01 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 48ACA3A684D; Thu, 25 Jun 2009 07:00:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243828800"; d="scan'208";a="175068222" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Jun 2009 09:58:14 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 Jun 2009 09:58:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 15:58:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) thread-index: Acn1gCaSVhiFK6IuQKKyZFDRBQDwuAAHJuVA References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" Cc: dime@ietf.org, Glen Zorn , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 14:00:02 -0000 Jouni and Glen, Can you be exact about what text in the current charter proposal you consider problematic and how you propose to change it? Dan > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Thursday, June 25, 2009 1:32 PM > To: Romascanu, Dan (Dan) > Cc: Glen Zorn; dime@ietf.org; iesg@ietf.org > Subject: Re: [Dime] WG Review: Recharter of Diameter=20 > Maintenance and Extensions(dime) >=20 > Hi, >=20 > On Jun 25, 2009, at 12:40 PM, Romascanu, Dan (Dan) wrote: >=20 > [snip] >=20 > >> > >> > >> On a different topic: the new charter contains the=20 > sentence "There is=20 > >> on-going work on defining RADIUS extensions and the DIME WG will=20 > >> ensure that work done in RADEXT is also available for Diameter." =20 > >> This is an incredibly poor idea: > >> it's bad enough to persist in allowing RADIUS to be "extended" > >> (though there's little real danger of that happening in=20 > the radext WG=20 > >> ;-), but to tie Diameter & RADIUS together at the hip is=20 > practically=20 > >> criminal. > >> Backward compatibility with RADIUS is fine; on-going, _forward_=20 > >> compatibility is not. This was discussed, as you know, on=20 > the dime=20 > >> list with no objections to the idea of limiting RADIUS-Diameter=20 > >> compatibility; however the offending sentence remains. > >> > > > > I am not sure that the intention of this sentence is such a tight=20 > > interdependence or forward compatibility as you fear. I would let=20 > > however Hannes and Victor to comment first, >=20 > I posted on this topic already earlier (probably missed in=20 > the mail flood). I share the concern Glen has regarding the=20 > RADIUS compatibility. >=20 > Cheers, > Jouni >=20 >=20 >=20 > > > > > > Dan > > > >> ... > >> > >> > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 From tom.taylor@rogers.com Thu Jun 25 07:37:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0603A6A2E for ; Thu, 25 Jun 2009 07:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdfi2+sinb7Y for ; Thu, 25 Jun 2009 07:37:37 -0700 (PDT) Received: from smtp108.rog.mail.re2.yahoo.com (smtp108.rog.mail.re2.yahoo.com [68.142.225.206]) by core3.amsl.com (Postfix) with SMTP id D5A853A68C8 for ; Thu, 25 Jun 2009 07:37:36 -0700 (PDT) Received: (qmail 79641 invoked from network); 25 Jun 2009 14:35:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vRt5HPOVEkwYmdt4Nv3qFTQap1xP7xh742unwWaPWg/V6DHvBEC/lM63djE5VmJ9ADMEniz3+k7+5aRo+kcPlCO40QgdqKMc1ce9kuLbbIC/Pstd3tmH2OFX/xralpeYhgsedL9guBOKiYr3HnBENKvgPncJ/nLh2Za2hrf++6M= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 25 Jun 2009 14:35:59 -0000 X-YMail-OSG: 9F1I.cEVM1m5mq3O_C_F8YXHsSNGd1vR1hJsPmYLe8uo6yujwAyPVF5TzH8Z4Eiajw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A438B4F.7050304@rogers.com> Date: Thu, 25 Jun 2009 10:35:59 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, Glen Zorn , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 14:37:37 -0000 I asked the question on the DIME list. I'll ask it again. I believe I read below that if the realm-based redirection draft becomes sufficiently mature it can be adopted as a WG item within the scope of the currently proposed charter. Can you confirm this? Tom Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: Glen Zorn [mailto:glenzorn@comcast.net] >> Sent: Thursday, June 25, 2009 12:27 PM >> To: Romascanu, Dan (Dan) >> Cc: 'Hannes Tschofenig'; dime@ietf.org; >> vfajardo@tari.toshiba.com; iesg@ietf.org >> Subject: RE: WG Review: Recharter of Diameter Maintenance and >> Extensions(dime) >> >> Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: >> >>> Glen, >>> >>> Rechartering and the "hum" for adoption of a document as WG >> item need >>> not be necessarily serialized. Rechartering is about >> approving to work >>> on a specific problem. The "hum" acknowledges (or not) that >> a certain >>> document is good enough to be the 00 version of the WG I-D >> that will >>> provide a solution to the problem. Of course, if >> rechartering is not >>> approved the "hum" will not have any effect, but otherwise >> some time >>> may be won by runing the "hum" and the rechartering review in >>> parallel. >> I see. Unfortunately, I can't see any mention of the problem >> in the revised charter, either, unless it is your opinion >> that realm-based redirection would be an extension to the >> Diameter Base Protocol (not unreasonable). > > Something on this lines. The WG decided to use extensions as a generic > denomination of many applications of various kinds so that the text > needs not be changed each time. There is always an opportunity to > express concerns when a deliverable is out of what would be a > reasonable extension. > [snip] From dromasca@avaya.com Thu Jun 25 08:06:26 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C257B3A68C8; Thu, 25 Jun 2009 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBCbWbTYkv3G; Thu, 25 Jun 2009 08:06:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3C7873A6862; Thu, 25 Jun 2009 08:06:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243828800"; d="scan'208";a="149580261" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jun 2009 11:01:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 Jun 2009 11:01:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 17:01:27 +0200 Message-ID: In-Reply-To: <4A438B4F.7050304@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) thread-index: Acn1okLUGlWMaVuARtWpSoeycjnYuAAAxoww References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> <4A438B4F.7050304@rogers.com> From: "Romascanu, Dan (Dan)" To: "Tom Taylor" Cc: dime@ietf.org, Glen Zorn , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 15:06:26 -0000 Tom, This is my understanding. I would add the fact that there should be enough active participants (editors, committed reviewers) for this work to be undergone and completed. =20 Dan > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com]=20 > Sent: Thursday, June 25, 2009 5:36 PM > To: Romascanu, Dan (Dan) > Cc: Glen Zorn; dime@ietf.org; iesg@ietf.org > Subject: Re: [Dime] WG Review: Recharter of Diameter=20 > Maintenance and Extensions(dime) >=20 > I asked the question on the DIME list. I'll ask it again. I=20 > believe I read below that if the realm-based redirection=20 > draft becomes sufficiently mature it can be adopted as a WG=20 > item within the scope of the currently proposed charter. Can=20 > you confirm this? >=20 > Tom >=20 > Romascanu, Dan (Dan) wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Glen Zorn [mailto:glenzorn@comcast.net] > >> Sent: Thursday, June 25, 2009 12:27 PM > >> To: Romascanu, Dan (Dan) > >> Cc: 'Hannes Tschofenig'; dime@ietf.org; vfajardo@tari.toshiba.com;=20 > >> iesg@ietf.org > >> Subject: RE: WG Review: Recharter of Diameter Maintenance and > >> Extensions(dime) > >> > >> Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: > >> > >>> Glen, > >>> > >>> Rechartering and the "hum" for adoption of a document as WG > >> item need > >>> not be necessarily serialized. Rechartering is about > >> approving to work > >>> on a specific problem. The "hum" acknowledges (or not) that > >> a certain > >>> document is good enough to be the 00 version of the WG I-D > >> that will > >>> provide a solution to the problem. Of course, if > >> rechartering is not > >>> approved the "hum" will not have any effect, but otherwise > >> some time > >>> may be won by runing the "hum" and the rechartering review in=20 > >>> parallel. > >> I see. Unfortunately, I can't see any mention of the=20 > problem in the=20 > >> revised charter, either, unless it is your opinion that=20 > realm-based=20 > >> redirection would be an extension to the Diameter Base=20 > Protocol (not=20 > >> unreasonable). > >=20 > > Something on this lines. The WG decided to use extensions as a=20 > > generic denomination of many applications of various kinds=20 > so that the=20 > > text needs not be changed each time. There is always an=20 > opportunity to=20 > > express concerns when a deliverable is out of what would be a=20 > > reasonable extension. > >=20 > [snip] >=20 From hannes.tschofenig@nsn.com Thu Jun 25 08:27:10 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96893A6862; Thu, 25 Jun 2009 08:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.389 X-Spam-Level: X-Spam-Status: No, score=-5.389 tagged_above=-999 required=5 tests=[AWL=1.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+ZFvKp3uVGe; Thu, 25 Jun 2009 08:27:09 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4D1843A6C76; Thu, 25 Jun 2009 08:27:08 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n5PD7EjR013218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Jun 2009 15:07:14 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n5PD7CXY013154; Thu, 25 Jun 2009 15:07:14 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 15:07:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 16:07:13 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45017B3822@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions(dime) Thread-Index: Acn0Qb+Fc+7TmZvaSYShdYsY18mTMQBDUO6gAAfLFXAACN1vIA== References: <20090623203001.ACE0C3A6D27@core3.amsl.com><00dd01c9f559$462f76e0$d28e64a0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Romascanu, Dan (Dan)" , "Glen Zorn" , X-OriginalArrivalTime: 25 Jun 2009 13:07:13.0764 (UTC) FILETIME=[DB75EA40:01C9F595] Cc: dime@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 15:27:10 -0000 Glen,=20 This is not the last time we are going to submit a recharter proposal to the IESG. In fact, this recharter proposal is in relationship to the Hums we did at the last IETF meeting. The Hum and the rechartering activity are not related to each other.=20 Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >Behalf Of ext Romascanu, Dan (Dan) >Sent: 25 June, 2009 10:38 >To: Glen Zorn; iesg@ietf.org >Cc: dime@ietf.org >Subject: Re: [Dime] WG Review: Recharter of Diameter=20 >Maintenance andExtensions(dime) > >Glen, > >Rechartering and the "hum" for adoption of a document as WG=20 >item need not be necessarily serialized. Rechartering is about=20 >approving to work on a specific problem. The "hum"=20 >acknowledges (or not) that a certain document is good enough=20 >to be the 00 version of the WG I-D that will provide a=20 >solution to the problem. Of course, if rechartering is not=20 >approved the "hum" will not have any effect, but otherwise=20 >some time may be won by runing the "hum" and the rechartering=20 >review in parallel.=20 > >Dan > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf=20 >> Of Glen Zorn >> Sent: Thursday, June 25, 2009 8:53 AM >> To: iesg@ietf.org >> Cc: 'Hannes Tschofenig'; dime@ietf.org; vfajardo@tari.toshiba.com >> Subject: RE: WG Review: Recharter of Diameter Maintenance and >> Extensions(dime) >>=20 >> > A modified charter has been submitted for the Diameter >> Maintenance and >> > Extensions (dime) working group in the Operations and >> Management Area >> > of the IETF. The IESG has not made any determination as yet. The=20 >> > modified charter is provided below for informational >> purposes only. =20 >> > Please send your comments to the IESG mailing list >> (iesg@ietf.org) by >> > Tuesday, June 30, 2009. >>=20 >> An email "hum" regarding the adoption of=20 >> http://www.ietf.org/internet-drafts/draft-tsou-dime-realm-base >> d-redirect-00. >> txt as a chartered working group item was begun on 12 June=20 >> (http://www.ietf.org/mail-archive/web/dime/current/msg03595.ht >> ml). The "hum" period ends tomorrow, yet the new charter=20 >has already=20 >> been submitted to the IESG. Apparently there has been some=20 >> unintentional oversight. >>=20 >> ... >>=20 >>=20 >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From jouni.nospam@gmail.com Thu Jun 25 09:20:28 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71C53A6D9B; Thu, 25 Jun 2009 09:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzYCq2NRTR+i; Thu, 25 Jun 2009 09:20:28 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 5B7EF28C0EA; Thu, 25 Jun 2009 09:20:27 -0700 (PDT) Received: by bwz9 with SMTP id 9so1518574bwz.37 for ; Thu, 25 Jun 2009 09:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=1B3Lz4rEukFUGWAgxlUcpBZnVceIBzuoF/RMvCL0DuY=; b=VPn59mlVw+sQuOf9MELkBnKEK+cGQfGKq13vbyYnwhqFfgwdB4/h6JG3AbRwcLsudh OOoVd5MdYJUdOyEEeea3CXvAu6P8GR2ohnmLGtWCE4VcLtzOPAtXoYDEwr5KLa3bjR9u S1NVUVqRO4Y0jimWR9Yz9MwF9j/3cg+GeOQwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=W6KOlzdPt7dnbKErt5PMrqFyicZZENl3WVO6VXbWKWTfsp2F/uO6q0ROWqW8SWrUk7 CcfgAsAoSSRLmLM6YqMmrpTrEUhFst1VbTZQQkg5lI7mWYDgM6BeDRLab+71JJLR6ANW OYGy8d8nqWst2MgdVPq5u6WzpRp2Sml9nElfQ= Received: by 10.103.167.14 with SMTP id u14mr1665559muo.38.1245946729624; Thu, 25 Jun 2009 09:18:49 -0700 (PDT) Received: from a88-112-140-213.elisa-laajakaista.fi (a88-112-140-213.elisa-laajakaista.fi [88.112.140.213]) by mx.google.com with ESMTPS id 7sm12469523mup.24.2009.06.25.09.18.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 09:18:49 -0700 (PDT) Message-Id: <4519FFCE-9286-4ED1-8ACC-AF798714725B@gmail.com> From: jouni korhonen To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 19:18:47 +0300 References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org, Glen Zorn , iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 16:20:29 -0000 Hi Dan, The following text in the proposed charter: "The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter." In my opinion it is not Dime's responsibility to follow what RADEXT does and try to align with them. Especially the line "the DIME WG will ensure that work done in RADEXT is also available for Diameter" is scary. If RADEXT is in a process of upgrading RADIUS with all Diameter functionality, why should we care about aligning with them? I would just write that RADEXT and Dime will work together for the general good of AAA. There are topics that concern both.. like internationalization etc. CHeers, Jouni On Jun 25, 2009, at 4:58 PM, Romascanu, Dan (Dan) wrote: > Jouni and Glen, > > Can you be exact about what text in the current charter proposal you > consider problematic and how you propose to change it? > > Dan > > >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Thursday, June 25, 2009 1:32 PM >> To: Romascanu, Dan (Dan) >> Cc: Glen Zorn; dime@ietf.org; iesg@ietf.org >> Subject: Re: [Dime] WG Review: Recharter of Diameter >> Maintenance and Extensions(dime) >> >> Hi, >> >> On Jun 25, 2009, at 12:40 PM, Romascanu, Dan (Dan) wrote: >> >> [snip] >> >>>> >>>> >>>> On a different topic: the new charter contains the >> sentence "There is >>>> on-going work on defining RADIUS extensions and the DIME WG will >>>> ensure that work done in RADEXT is also available for Diameter." >>>> This is an incredibly poor idea: >>>> it's bad enough to persist in allowing RADIUS to be "extended" >>>> (though there's little real danger of that happening in >> the radext WG >>>> ;-), but to tie Diameter & RADIUS together at the hip is >> practically >>>> criminal. >>>> Backward compatibility with RADIUS is fine; on-going, _forward_ >>>> compatibility is not. This was discussed, as you know, on >> the dime >>>> list with no objections to the idea of limiting RADIUS-Diameter >>>> compatibility; however the offending sentence remains. >>>> >>> >>> I am not sure that the intention of this sentence is such a tight >>> interdependence or forward compatibility as you fear. I would let >>> however Hannes and Victor to comment first, >> >> I posted on this topic already earlier (probably missed in >> the mail flood). I share the concern Glen has regarding the >> RADIUS compatibility. >> >> Cheers, >> Jouni >> >> >> >>> >>> >>> Dan >>> >>>> ... >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> >> From Mark.Jones@bridgewatersystems.com Thu Jun 25 11:39:21 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BB33A69C4; Thu, 25 Jun 2009 11:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-LrgosxCX1t; Thu, 25 Jun 2009 11:39:21 -0700 (PDT) Received: from anders.electric.net (anders.electric.net [72.35.23.15]) by core3.amsl.com (Postfix) with ESMTP id E12E83A6837; Thu, 25 Jun 2009 11:39:20 -0700 (PDT) Received: from 1MJthZ-0003ai-VZ by anders.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1MJtha-0003bQ-TM; Thu, 25 Jun 2009 11:29:38 -0700 Received: by emcmailer; Thu, 25 Jun 2009 11:29:38 -0700 Received: from [72.35.6.119] (helo=mail.bridgewatersystems.com) by anders.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1MJthZ-0003ai-VZ; Thu, 25 Jun 2009 11:29:37 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Thu, 25 Jun 2009 14:29:37 -0400 From: Mark Jones To: "Romascanu, Dan (Dan)" Date: Thu, 25 Jun 2009 14:29:34 -0400 Thread-Topic: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) Thread-Index: Acn1sOpKknY2RizkTeuMX2dXn2LgBAADXM9Q Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034BF5@m679t05.fpmis.bridgewatersys.com> References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> <4519FFCE-9286-4ED1-8ACC-AF798714725B@gmail.com> In-Reply-To: <4519FFCE-9286-4ED1-8ACC-AF798714725B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 750505 X-Virus-Status: Scanned by VirusSMART (c) Cc: "dime@ietf.org" , Glen Zorn , "iesg@ietf.org" Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 18:39:22 -0000 Hi Dan, I agree with Jouni and Glen. I see no motivation for a general commitment t= hat "work done in RADEXT is also available for Diameter". Following Jouni's= suggestion, I propose updating the charter text to read: "The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is also=20 on-going work in the RADEXT WG on defining RADIUS extensions.=20 The DIME WG will work with the RADEXT WG to harmonize approaches on new AAA topics that concern both groups." Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of jouni korhonen > Sent: June 25, 2009 9:19 AM > To: Romascanu, Dan (Dan) > Cc: dime@ietf.org; Glen Zorn; iesg@ietf.org > Subject: Re: [Dime] WG Review: Recharter of Diameter=20 > Maintenance and Extensions(dime) >=20 >=20 > Hi Dan, >=20 > The following text in the proposed charter: >=20 > "The IETF has completed work on the Diameter Base protocol and is > working on revising the base protocol specification. There is on-going > work on defining RADIUS extensions and the DIME WG will ensure > that work done in RADEXT is also available for Diameter." >=20 > In my opinion it is not Dime's responsibility to follow what RADEXT =20 > does and try to align with them. Especially the line "the=20 > DIME WG will =20 > ensure that work done in RADEXT is also available for Diameter" is =20 > scary. If RADEXT is in a process of upgrading RADIUS with all=20 > Diameter =20 > functionality, why should we care about aligning with them? >=20 > I would just write that RADEXT and Dime will work together for the =20 > general good of AAA. There are topics that concern both.. like =20 > internationalization etc. >=20 > CHeers, > Jouni >=20 >=20 >=20 >=20 >=20 > On Jun 25, 2009, at 4:58 PM, Romascanu, Dan (Dan) wrote: >=20 > > Jouni and Glen, > > > > Can you be exact about what text in the current charter proposal you > > consider problematic and how you propose to change it? > > > > Dan > > > > > >> -----Original Message----- > >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] > >> Sent: Thursday, June 25, 2009 1:32 PM > >> To: Romascanu, Dan (Dan) > >> Cc: Glen Zorn; dime@ietf.org; iesg@ietf.org > >> Subject: Re: [Dime] WG Review: Recharter of Diameter > >> Maintenance and Extensions(dime) > >> > >> Hi, > >> > >> On Jun 25, 2009, at 12:40 PM, Romascanu, Dan (Dan) wrote: > >> > >> [snip] > >> > >>>> > >>>> > >>>> On a different topic: the new charter contains the > >> sentence "There is > >>>> on-going work on defining RADIUS extensions and the DIME WG will > >>>> ensure that work done in RADEXT is also available for Diameter." > >>>> This is an incredibly poor idea: > >>>> it's bad enough to persist in allowing RADIUS to be "extended" > >>>> (though there's little real danger of that happening in > >> the radext WG > >>>> ;-), but to tie Diameter & RADIUS together at the hip is > >> practically > >>>> criminal. > >>>> Backward compatibility with RADIUS is fine; on-going, _forward_ > >>>> compatibility is not. This was discussed, as you know, on > >> the dime > >>>> list with no objections to the idea of limiting RADIUS-Diameter > >>>> compatibility; however the offending sentence remains. > >>>> > >>> > >>> I am not sure that the intention of this sentence is such a tight > >>> interdependence or forward compatibility as you fear. I would let > >>> however Hannes and Victor to comment first, > >> > >> I posted on this topic already earlier (probably missed in > >> the mail flood). I share the concern Glen has regarding the > >> RADIUS compatibility. > >> > >> Cheers, > >> Jouni > >> > >> > >> > >>> > >>> > >>> Dan > >>> > >>>> ... > >>>> > >>>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dime > >> > >> >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = From glenzorn@comcast.net Thu Jun 25 16:29:41 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79BB43A68A4 for ; Thu, 25 Jun 2009 16:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvsG-2E7WeS9 for ; Thu, 25 Jun 2009 16:29:41 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 2AE723A67E2 for ; Thu, 25 Jun 2009 16:29:41 -0700 (PDT) Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 8KQG1c0061ei1Bg53PTC8y; Thu, 25 Jun 2009 23:27:12 +0000 Received: from gwzPC ([124.120.218.130]) by OMTA24.westchester.pa.mail.comcast.net with comcast id 8PTN1c0012pPh2s3kPTWG2; Thu, 25 Jun 2009 23:27:57 +0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" , "'jouni korhonen'" References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> In-Reply-To: Date: Fri, 26 Jun 2009 06:22:45 +0700 Message-ID: <003901c9f5eb$edfadc10$c9f09430$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn1gCaSVhiFK6IuQKKyZFDRBQDwuAAHJuVAABO2mnA= Content-Language: en-us Cc: dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:29:41 -0000 Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: > Jouni and Glen, > > Can you be exact about what text in the current charter proposal you > consider problematic and how you propose to change it? Certainly: delete the sentence "There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter." ... From glenzorn@comcast.net Thu Jun 25 16:32:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6363A67A3 for ; Thu, 25 Jun 2009 16:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTGWpaNLabXw for ; Thu, 25 Jun 2009 16:32:57 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id C97893A68C3 for ; Thu, 25 Jun 2009 16:32:57 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 8NAv1c00216AWCUAAPVnKN; Thu, 25 Jun 2009 23:29:47 +0000 Received: from gwzPC ([124.120.218.130]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id 8PV31c00C2pPh2s8SPVEtM; Thu, 25 Jun 2009 23:29:42 +0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> <4A438B4F.7050304@rogers.com> In-Reply-To: Date: Fri, 26 Jun 2009 06:25:15 +0700 Message-ID: <003a01c9f5ec$4a3d2d20$deb78760$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn1okLUGlWMaVuARtWpSoeycjnYuAAAxowwABGoQqA= Content-Language: en-us Cc: dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:32:58 -0000 Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: > Tom, > > This is my understanding. Thanks! > I would add the fact that there should be > enough active participants (editors, committed reviewers) for this work > to be undergone and completed. I think that that has been amply demonstrated on the list. ... From glenzorn@comcast.net Thu Jun 25 16:48:10 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BECE93A68C3 for ; Thu, 25 Jun 2009 16:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGmON4edbKrZ for ; Thu, 25 Jun 2009 16:48:10 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id DCC283A6825 for ; Thu, 25 Jun 2009 16:48:08 -0700 (PDT) Received: from OMTA17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 8Nq81c0011vXlb85BPo3MU; Thu, 25 Jun 2009 23:48:03 +0000 Received: from gwzPC ([124.120.218.130]) by OMTA17.westchester.pa.mail.comcast.net with comcast id 8PoA1c00A2pPh2s3dPoJ64; Thu, 25 Jun 2009 23:48:52 +0000 From: "Glen Zorn" To: "'Mark Jones'" , "'Romascanu, Dan \(Dan\)'" References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> <4519FFCE-9286-4ED1-8ACC-AF798714725B@gmail.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034BF5@m679t05.fpmis.bridgewatersys.com> In-Reply-To: <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034BF5@m679t05.fpmis.bridgewatersys.com> Date: Fri, 26 Jun 2009 06:43:30 +0700 Message-ID: <004701c9f5ee$d73f6f10$85be4d30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn1sOpKknY2RizkTeuMX2dXn2LgBAADXM9QAAvFDHA= Content-Language: en-us Cc: dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:48:10 -0000 Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] writes: > Hi Dan, > > I agree with Jouni and Glen. I see no motivation for a general > commitment that "work done in RADEXT is also available for Diameter". > Following Jouni's suggestion, I propose updating the charter text to > read: > > "The IETF has completed work on the Diameter Base protocol and is > working on revising the base protocol specification. There is also > on-going work in the RADEXT WG on defining RADIUS extensions. > The DIME WG will work with the RADEXT WG to harmonize approaches on > new AAA topics that concern both groups." I actually don't see any reason to even mention RADIUS or radext in the charter... ... From aland@deployingradius.com Thu Jun 25 17:10:03 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A5D3A68F8; Thu, 25 Jun 2009 17:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyZ-z9acleTV; Thu, 25 Jun 2009 17:10:02 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 6B0633A68D8; Thu, 25 Jun 2009 17:10:01 -0700 (PDT) Received: from Thor.local (port-212-202-223-58.static.qsc.de [212.202.223.58]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 15CDE123456B; Fri, 26 Jun 2009 02:09:20 +0200 (CEST) Message-ID: <4A4411AF.2040000@deployingradius.com> Date: Fri, 26 Jun 2009 02:09:19 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Glen Zorn References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> <4519FFCE-9286-4ED1-8ACC-AF798714725B@gmail.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034BF5@m679t05.fpmis.bridgewatersys.com> <004701c9f5ee$d73f6f10$85be4d30$@net> In-Reply-To: <004701c9f5ee$d73f6f10$85be4d30$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Mark Jones' , dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 00:10:03 -0000 Glen Zorn wrote: > I actually don't see any reason to even mention RADIUS or radext in the > charter... If the groups don't need to coordinate, does this mean that the RADEXT documents can remove all "Diameter considerations" sections? If there aren't any RADIUS <-> Diameter gateways in production environments, this would seem to be a reasonable thing to do. Alan DeKok. From glenzorn@comcast.net Thu Jun 25 17:33:16 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143FD3A6A99 for ; Thu, 25 Jun 2009 17:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebl+R-miltVz for ; Thu, 25 Jun 2009 17:33:15 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 4C57B3A69EF for ; Thu, 25 Jun 2009 17:33:15 -0700 (PDT) Received: from OMTA16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id 8Q7B1c00L1ZMdJ4A3QYZSZ; Fri, 26 Jun 2009 00:32:33 +0000 Received: from gwzPC ([124.120.218.130]) by OMTA16.emeryville.ca.mail.comcast.net with comcast id 8QYh1c0082pPh2s8cQYqB8; Fri, 26 Jun 2009 00:33:23 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <20090623203001.ACE0C3A6D27@core3.amsl.com> <00dd01c9f559$462f76e0$d28e64a0$@net> <00f901c9f577$2e9c2c30$8bd48490$@net> <4519FFCE-9286-4ED1-8ACC-AF798714725B@gmail.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034BF5@m679t05.fpmis.bridgewatersys.com> <004701c9f5ee$d73f6f10$85be4d30$@net> <4A4411AF.2040000@deployingradius.com> In-Reply-To: <4A4411AF.2040000@deployingradius.com> Date: Fri, 26 Jun 2009 07:27:54 +0700 Message-ID: <004901c9f5f5$0c5d8d20$2518a760$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn18l0fd5uOaMl5QmKGS+KGYnqXZwAAle3g Content-Language: en-us Cc: 'Mark Jones' , dime@ietf.org, iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions(dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 00:33:16 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > I actually don't see any reason to even mention RADIUS or radext in > the > > charter... > > If the groups don't need to coordinate, does this mean that the > RADEXT > documents can remove all "Diameter considerations" sections? I had thought that that was pretty much the consensus reached during the radext "virtual interim" (bowing to the radext Chairs, of course). > > If there aren't any RADIUS <-> Diameter gateways in production > environments, this would seem to be a reasonable thing to do. > > Alan DeKok. From behcetsarikaya@yahoo.com Fri Jun 26 14:14:12 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101453A69D2 for ; Fri, 26 Jun 2009 14:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwKTc56eOM-2 for ; Fri, 26 Jun 2009 14:14:11 -0700 (PDT) Received: from n3.bullet.mail.re3.yahoo.com (n3.bullet.mail.re3.yahoo.com [68.142.237.110]) by core3.amsl.com (Postfix) with SMTP id 940BB3A6A7E for ; Fri, 26 Jun 2009 14:13:56 -0700 (PDT) Received: from [68.142.237.88] by n3.bullet.mail.re3.yahoo.com with NNFMP; 26 Jun 2009 21:14:13 -0000 Received: from [67.195.9.82] by t4.bullet.re3.yahoo.com with NNFMP; 26 Jun 2009 21:14:13 -0000 Received: from [67.195.9.105] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 26 Jun 2009 21:14:12 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 26 Jun 2009 21:14:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 913969.71536.bm@omp109.mail.gq1.yahoo.com Received: (qmail 151 invoked by uid 60001); 26 Jun 2009 21:14:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246050852; bh=2AopcAjbD8muhk/o+d3isAExlNJrx4iGrZTtmA/gPi4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y+PwAaS1FJ3WwSYIJnQ6Hp5kL0ClIPx55fvor3Rwt0pGEXNcLj02ziXlxIf+uqu98zck0UaELPahIEP8OGsl5AhTVn2lC5ftNrB+U2sQpOvgVJjOCZQznHi6BTnhV/+yGExmYZo7U6ZN1ByvwtJOfh5DkGcfiMfH47flRbPWfyU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CAfxX3bY/DlNV7Fc92cRugdEk+ssfUCgdNADbXicvoSUxqgtAFU3J3BYbG+o6O+zQ/+d3ZAPyzY7PWvZvx5A6+HmukHlNXmlZqbxEpCjwPz8ZFKWXTQP4yUnXAwFIJOTB9p/ycagKea6tW+oYp1Czr5Fmd0HZmdutFe5SGplf+E=; Message-ID: <701005.98419.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: MWfPZ4gVM1l0LFXx_4TbmrTT3JDbqpwpFi8VNEhmjyntdOmsV4fsDga69.SYyjrzZEt8ZcYxsIn.pWcyIgG9TmOY4hZKbGRCIzstKYtYNJnc9zz8sVaZ76L8Accr00HcxyXwDFwc5jghhJXwtOwsPdhH4O.WI.RLwmIjme9uXRp5T32x7HTZV.1cKmSMBhy3nBCpsRwvWWokavjGvnwnGHfQjEDWioft9Y.N0EswzcAq.tUZ7FC8nhmazpiHdU_6nHIY8oTaWyudNh76bQRHiRZp3N1FfVJP6hsVi49Q9krriw4NHaO4jA-- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 26 Jun 2009 14:14:12 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> Date: Fri, 26 Jun 2009 14:14:12 -0700 (PDT) From: Behcet Sarikaya To: Sebastien Decugis In-Reply-To: <4A42F67F.6020108@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 21:14:12 -0000 Hi Sebastien,=0A=A0 On page 13, you asked:=0A=A0=A0=A0 [[Editor16: How do w= e create / retrieve the Session-Id?]]=0A=0AI think that Session-ID is first= =A0introduced in RFC 5247 which is not referenced in your draft.=0ASession-= ID needs to be defined for each EAP Method separately.=0A=0AMy 2 cents.=0A= =0ARegards,=0A=0ABehcet=0A=0A=0A=0A From sdecugis@nict.go.jp Sun Jun 28 18:40:23 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DFA3A68F5 for ; Sun, 28 Jun 2009 18:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4QufR7tjwnl for ; Sun, 28 Jun 2009 18:40:22 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 412A43A6807 for ; Sun, 28 Jun 2009 18:40:21 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n5T1eTOB016660; Mon, 29 Jun 2009 10:40:29 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n5T1eTwa007623; Mon, 29 Jun 2009 10:40:29 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n5T1eT0g007620; Mon, 29 Jun 2009 10:40:29 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 059BF1657A; Mon, 29 Jun 2009 10:40:29 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 0074F1655E; Mon, 29 Jun 2009 10:40:28 +0900 (JST) Message-ID: <4A481B88.6020703@nict.go.jp> Date: Mon, 29 Jun 2009 10:40:24 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Behcet Sarikaya References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> In-Reply-To: <701005.98419.qm@web111413.mail.gq1.yahoo.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 01:40:23 -0000 Dear Behcet, Thank you for this information. I should definitely cite this RFC from the draft. Anyway, in the context of the draft, the Session-Id refers to the definition given in RFC3588 (Diameter Base Protocol) section 8 (Diameter User Sessions). It is not limited to EAP and authentication, but used also for accounting for example. When the peer moves to a new authenticator and uses ERP for authentication, we must figure a way for accounting to work properly. I can see two possibilities here (there might be others): -> The new NAS learns by some mean the Session-Id that was used in the previous NAS, and sends its accounting records using this Session-Id. -> The NAS creates a new Session-Id, and the accounting server is able to correlate the new Session-Id with the old one. Both solutions are not trivial IMHO, and need to be discussed. Best regards, Sebastien. Behcet Sarikaya a écrit : > Hi Sebastien, > On page 13, you asked: > [[Editor16: How do we create / retrieve the Session-Id?]] > > I think that Session-ID is first introduced in RFC 5247 which is not referenced in your draft. > Session-ID needs to be defined for each EAP Method separately. > > My 2 cents. > > Regards, > > Behcet > > > > > > > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From Mark.Jones@bridgewatersystems.com Mon Jun 29 08:17:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369E828C156 for ; Mon, 29 Jun 2009 08:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfzSj69GsUN6 for ; Mon, 29 Jun 2009 08:17:41 -0700 (PDT) Received: from bean.electric.net (bean.electric.net [72.35.23.29]) by core3.amsl.com (Postfix) with ESMTP id 6DCDC28C1A5 for ; Mon, 29 Jun 2009 08:17:41 -0700 (PDT) Received: from 1MLIcI-0001oq-Tm by bean.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1MLIcI-0001p0-U5 for dime@ietf.org; Mon, 29 Jun 2009 08:17:58 -0700 Received: by emcmailer; Mon, 29 Jun 2009 08:17:58 -0700 Received: from [72.35.6.119] (helo=mail.bridgewatersystems.com) by bean.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1MLIcI-0001oq-Tm for dime@ietf.org; Mon, 29 Jun 2009 08:17:58 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Mon, 29 Jun 2009 11:17:58 -0400 From: Mark Jones To: "dime@ietf.org" Date: Mon, 29 Jun 2009 11:17:57 -0400 Thread-Topic: Review of draft-ietf-dime-diameter-cmd-iana Thread-Index: Acn4zMguFnarNKd4QT6lWGKyxVbNXQ== Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034C95@m679t05.fpmis.bridgewatersys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 750505 X-Virus-Status: Scanned by VirusSMART (c) Subject: [Dime] Review of draft-ietf-dime-diameter-cmd-iana X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:17:42 -0000 I realize that this is past the review deadline but hope it is not too late= for consideration. My comments on the Abstract and Introduction are editor= ial but the meat of it (the IANA considerations) looks fine to me. Abstract: --- Suggest rewording: RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. =20 To: RFC3588 illustrates the conditions which require the definition of=20 a new Diameter application or a new ommand. --- Suggest rewording: This document aligns the extensibility rules of Diameter application with the Diameter commands offering ways to To: This document aligns the extensibility rules for Diameter command codes= =20 with those defined for Diameter application identifiers and offers a consistent way to=20 =3D=3D=3D 1. Introduction Suggest rewording: This is achieved by splitting the command code space into an IANA administered code space, and a vendors-specific code space with different rules of allocation as per [RFC5226]. To: This is achieved by splitting the command code space into an IETF code space, and a vendors-specific code space with different rules=20 of allocation as per [RFC5226]. The whole command code space is still under IANA administration, right? --- Typo: s/[I-D.ietf-dime-rfc3588bis]./[I-D.ietf-dime-rfc3588bis] --- Regards Mark= From sunseawq@huawei.com Mon Jun 29 19:00:44 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788383A6A41 for ; Mon, 29 Jun 2009 19:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.361 X-Spam-Level: X-Spam-Status: No, score=0.361 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6gdCdRhqOGE for ; Mon, 29 Jun 2009 19:00:43 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5484D3A67EA for ; Mon, 29 Jun 2009 19:00:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM1000LA49HLX@szxga03-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 10:00:53 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM100H4349HJL@szxga03-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 10:00:53 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM100FK249H3A@szxml06-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 10:00:53 +0800 (CST) Date: Tue, 30 Jun 2009 10:00:52 +0800 From: Qin Wu To: Sebastien Decugis , Behcet Sarikaya Message-id: <014801c9f926$996b7680$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:00:44 -0000 SGksIFNlYmFzdGllbiBhbmQgYWxsOg0KU29tZSBjbGFyaWZpY2F0aW9uLg0KSSB0aGluayBTZXNz aW9uLUlkIGRlc2NyaWJlZCBpbiBSRkM1MjQ3IGlzIGFwcGxpY2FibGUgZm9yIEVBUCBTZXNzaW9u IGFuZCB1c2VkIGJldHdlZW4gRUFQIHBlZXIgYW5kIEVBUCBzZXJ2ZXIuIE1vYmlsZSBkZXZpY2Ug Y2FuIGJlIG9uZSBleGFtcGxlIG9mIEVBUCBwZWVyLiBUaGUgU2Vzc2lvbi1JZCB5b3UgbWVudGlv bmVkIGlzIGFjY2VzcyBhdXRoZW50aWNhdGlvbiBzZXNzaW9uIGFuZCB1c2VkIGJldHdlZW4gQUFB IGNsaWVudCBhbmQgQUFBIHNlcnZlci4gSSB3b25kZXIgd2hldGhlciB0aGV5IGFyZSB0aGUgc2Ft ZSB0aGluZy4NCldoYXQgYW0gSSBtaXNzaW5nPw0KSW4gbXkgb3BpbmlvbiwgZWFjaCBFQVAgYXV0 aGVudGljYXRpb24gaGFzIGEgdW5pcXVlIHNlc3Npb24tSWQgaW4gcmVsYXRpb24gdG8gdGhlIEVB UCBtZXRob2QgdXNlZCwgdGhlIFNlc3Npb24tSWQgY2FuIGJlIGNyZWF0ZWQgYnkgdGhlIEVBUCBw ZWVyIG9yIEVBUCBzZXJ2ZXIuIEFtIEkgcmlnaHQ/DQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNlYmFzdGllbiBEZWN1Z2lzIiA8c2RlY3Vn aXNAbmljdC5nby5qcD4NClRvOiAiQmVoY2V0IFNhcmlrYXlhIiA8c2FyaWtheWFAaWVlZS5vcmc+ DQpDYzogPGRpbWVAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEp1bmUgMjksIDIwMDkgOTo0MCBB TQ0KU3ViamVjdDogUmU6IFtEaW1lXSBTZXNzaW9uLUlEIGluIGRyYWZ0LXNkZWN1Z2lzLWRpbWUt ZGlhbWV0ZXItZXJwLTAxDQoNCg0KRGVhciBCZWhjZXQsDQoNClRoYW5rIHlvdSBmb3IgdGhpcyBp bmZvcm1hdGlvbi4gSSBzaG91bGQgZGVmaW5pdGVseSBjaXRlIHRoaXMgUkZDIGZyb20NCnRoZSBk cmFmdC4NCg0KQW55d2F5LCBpbiB0aGUgY29udGV4dCBvZiB0aGUgZHJhZnQsIHRoZSBTZXNzaW9u LUlkIHJlZmVycyB0byB0aGUNCmRlZmluaXRpb24gZ2l2ZW4gaW4gUkZDMzU4OCAoRGlhbWV0ZXIg QmFzZSBQcm90b2NvbCkgc2VjdGlvbiA4IChEaWFtZXRlcg0KVXNlciBTZXNzaW9ucykuIEl0IGlz IG5vdCBsaW1pdGVkIHRvIEVBUCBhbmQgYXV0aGVudGljYXRpb24sIGJ1dCB1c2VkDQphbHNvIGZv ciBhY2NvdW50aW5nIGZvciBleGFtcGxlLiBXaGVuIHRoZSBwZWVyIG1vdmVzIHRvIGEgbmV3DQph dXRoZW50aWNhdG9yIGFuZCB1c2VzIEVSUCBmb3IgYXV0aGVudGljYXRpb24sIHdlIG11c3QgZmln dXJlIGEgd2F5IGZvcg0KYWNjb3VudGluZyB0byB3b3JrIHByb3Blcmx5LiBJIGNhbiBzZWUgdHdv IHBvc3NpYmlsaXRpZXMgaGVyZSAodGhlcmUNCm1pZ2h0IGJlIG90aGVycyk6DQotPiBUaGUgbmV3 IE5BUyBsZWFybnMgYnkgc29tZSBtZWFuIHRoZSBTZXNzaW9uLUlkIHRoYXQgd2FzIHVzZWQgaW4g dGhlDQpwcmV2aW91cyBOQVMsIGFuZCBzZW5kcyBpdHMgYWNjb3VudGluZyByZWNvcmRzIHVzaW5n IHRoaXMgU2Vzc2lvbi1JZC4NCi0+IFRoZSBOQVMgY3JlYXRlcyBhIG5ldyBTZXNzaW9uLUlkLCBh bmQgdGhlIGFjY291bnRpbmcgc2VydmVyIGlzIGFibGUNCnRvIGNvcnJlbGF0ZSB0aGUgbmV3IFNl c3Npb24tSWQgd2l0aCB0aGUgb2xkIG9uZS4NCg0KQm90aCBzb2x1dGlvbnMgYXJlIG5vdCB0cml2 aWFsIElNSE8sIGFuZCBuZWVkIHRvIGJlIGRpc2N1c3NlZC4NCg0KQmVzdCByZWdhcmRzLA0KU2Vi YXN0aWVuLg0KDQoNCg0KQmVoY2V0IFNhcmlrYXlhIGEg6WNyaXQgOg0KPiBIaSBTZWJhc3RpZW4s DQo+ICAgT24gcGFnZSAxMywgeW91IGFza2VkOg0KPiAgICAgW1tFZGl0b3IxNjogSG93IGRvIHdl IGNyZWF0ZSAvIHJldHJpZXZlIHRoZSBTZXNzaW9uLUlkP11dDQo+DQo+IEkgdGhpbmsgdGhhdCBT ZXNzaW9uLUlEIGlzIGZpcnN0IGludHJvZHVjZWQgaW4gUkZDIDUyNDcgd2hpY2ggaXMgbm90IHJl ZmVyZW5jZWQgaW4geW91ciBkcmFmdC4NCj4gU2Vzc2lvbi1JRCBuZWVkcyB0byBiZSBkZWZpbmVk IGZvciBlYWNoIEVBUCBNZXRob2Qgc2VwYXJhdGVseS4NCj4NCj4gTXkgMiBjZW50cy4NCj4NCj4g UmVnYXJkcywNCj4NCj4gQmVoY2V0DQo+DQo+DQo+DQo+ICAgICAgIA0KPg0KPg0KPiAgIA0KDQot LSANClNlYmFzdGllbiBEZWN1Z2lzDQpSZXNlYXJjaCBmZWxsb3cNCk5ldHdvcmsgQXJjaGl0ZWN0 dXJlIEdyb3VwDQpOSUNUIChuaWN0LmdvLmpwKQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ== From sdecugis@nict.go.jp Mon Jun 29 19:35:15 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83CB3A6C29 for ; Mon, 29 Jun 2009 19:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHBzTXaD8vtU for ; Mon, 29 Jun 2009 19:35:15 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 6BE123A6979 for ; Mon, 29 Jun 2009 19:35:14 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n5U2Z38X015365; Tue, 30 Jun 2009 11:35:03 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n5U2Z2cI016846; Tue, 30 Jun 2009 11:35:02 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n5U2Z26Q016843; Tue, 30 Jun 2009 11:35:02 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id BBAA216869; Tue, 30 Jun 2009 11:35:02 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id AF9901685A; Tue, 30 Jun 2009 11:35:02 +0900 (JST) Message-ID: <4A4979D0.2010106@nict.go.jp> Date: Tue, 30 Jun 2009 11:34:56 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Qin Wu References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> In-Reply-To: <014801c9f926$996b7680$260ca40a@china.huawei.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:35:15 -0000 Hi Qin, > I think Session-Id described in RFC5247 is applicable for EAP Session and used between EAP peer and EAP server. Mobile device can be one example of EAP peer. The Session-Id you mentioned is access authentication session and used between AAA client and AAA server. I wonder whether they are the same thing. > What am I missing? > No, in my opinion these are two different concepts. For example, even when EAP is not used, a Session-Id AVP is created in Diameter. > In my opinion, each EAP authentication has a unique session-Id in relation to the EAP method used, the Session-Id can be created by the EAP peer or EAP server. Am I right? > I was not aware that EAP methods also created a Session Id (or is it the EMSK KeyName?). Anyway, AFAIK, usually Diameter Session-Id AVP are created based on the User-Name, itself acquired from EAP Identity Request/Response (in case of EAP authentication). This exchange is not performed in the case of ERP (after a handover to a new NAS), so we really need to define what the (Diameter) Session-Id AVP will be in this case, and how it is created/retrieved. Session-Id AVP is mandatory in most Diameter messages. That is what I tried to highlight in the draft. I was not referring to the EAP Session Id, there. I hope this clarifies, Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Mon Jun 29 23:15:23 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6440328C17D for ; Mon, 29 Jun 2009 23:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvzq4r8lqrOl for ; Mon, 29 Jun 2009 23:15:22 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 441F03A69FA for ; Mon, 29 Jun 2009 23:15:22 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM1005KFG1WYV@szxga01-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 14:15:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM100G48G1W9L@szxga01-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 14:15:32 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM1008CPG1VP8@szxml04-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 14:15:32 +0800 (CST) Date: Tue, 30 Jun 2009 14:15:31 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 06:15:23 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: "Behcet Sarikaya" ; Sent: Tuesday, June 30, 2009 10:34 AM Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 > Hi Qin, > >> I think Session-Id described in RFC5247 is applicable for EAP Session and used between EAP peer and EAP server. Mobile device can be one example of EAP peer. The Session-Id you mentioned is access authentication session and used between AAA client and AAA server. I wonder whether they are the same thing. >> What am I missing? >> > No, in my opinion these are two different concepts. For example, even > when EAP is not used, a Session-Id AVP is created in Diameter. [Qin]: I agree, In that sense, we need to define a generic session-Id in ERP which is used between Diameter Client and Server, am I right? >> In my opinion, each EAP authentication has a unique session-Id in relation to the EAP method used, the Session-Id can be created by the EAP peer or EAP server. Am I right? >> > I was not aware that EAP methods also created a Session Id (or is it the > EMSK KeyName?). Anyway, AFAIK, usually Diameter Session-Id AVP are > created based on the User-Name, itself acquired from EAP Identity > Request/Response (in case of EAP authentication). This exchange is not > performed in the case of ERP (after a handover to a new NAS), so we > really need to define what the (Diameter) Session-Id AVP will be in this > case, and how it is created/retrieved. Session-Id AVP is mandatory in > most Diameter messages. That is what I tried to highlight in the draft. > I was not referring to the EAP Session Id, there. > > I hope this clarifies, [Qin]: Since ERP is method indpendent mechanism, In my opinion, we don't need to consider Session Id created by method, right? Session Id created by method consist of Nonce or Rand which are used to generate key materials,e.g.,EMSK. As regarding Diameter Session-Id, I have no objection to add it in ERP, However I am not quite sure why we need to define such Session-Id? One obvious reason occured to me is used for accounting, am I right? is there any other reason? > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Mon Jun 29 23:43:37 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42C328C2FF for ; Mon, 29 Jun 2009 23:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIH4qOD7u3-a for ; Mon, 29 Jun 2009 23:43:37 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 5CF7128C144 for ; Mon, 29 Jun 2009 23:43:36 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n5U6hRDs005425; Tue, 30 Jun 2009 15:43:27 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n5U6hQKS017982; Tue, 30 Jun 2009 15:43:26 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n5U6hQs0017976; Tue, 30 Jun 2009 15:43:26 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id AD1151689C; Tue, 30 Jun 2009 15:43:26 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id A65CA16888; Tue, 30 Jun 2009 15:43:26 +0900 (JST) Message-ID: <4A49B407.6040903@nict.go.jp> Date: Tue, 30 Jun 2009 15:43:19 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Qin Wu References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> In-Reply-To: <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 06:43:38 -0000 Hi again, > [Qin]: I agree, In that sense, we need to define a generic session-Id in ERP which is used between Diameter Client and Server, am I right? > We need this Session-Id in Diameter. I am not sure if the Id must be retrieved from ERP and propagated to Diameter, or retrieved directly by Diameter. At the time I wrote the draft, I was only thinking to the second choice, but managing this Id in ERP (maybe as opaque data) might simplify the process, and is worth investigation. > [Qin]: Since ERP is method indpendent mechanism, In my opinion, we don't need to consider Session Id created by method, right? > Session Id created by method consist of Nonce or Rand which are used to generate key materials,e.g.,EMSK. > Yes, I think it is better that Diameter does not need to understand the internals of EAP as much as possible :) > As regarding Diameter Session-Id, I have no objection to add it in ERP, However I am not quite sure why we need to define such Session-Id? > As I answered to the first question in this mail, I was not considering adding this Diameter Session-Id inside ERP so far. I was just pointing out that we need the new NAS to "have" a Session-Id, for peers that are using ERP to authenticate. This Session-Id is either new (then we need correlation with the previous Session-Id in the accounting server or ER server) or the same (then we need a mechanism to acquire this Session-Id in the NAS). > One obvious reason occured to me is used for accounting, am I right? is there any other reason? > I was also thinking about accounting, but there may be other uses. At this point, I don't know what is the best way to proceed to correlate the session information between previous and new authenticator, with regards to accounting. It might be worth having a brainstorm on this topic at Stockholm, if people are interested... I guess the main "philosophical" question here is: From the Diameter point of view, after handover and ERP re-authentication, are we continuing the same session, or is it a new session? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From tena@huawei.com Tue Jun 30 00:14:12 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE7828C332 for ; Tue, 30 Jun 2009 00:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoPlStHkPpry for ; Tue, 30 Jun 2009 00:14:11 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 055EC28C333 for ; Tue, 30 Jun 2009 00:13:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM1003PQIOMGA@szxga04-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 15:12:22 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM100JY5IOMR0@szxga04-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 15:12:22 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM100HVVIOM7W@szxml04-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 15:12:22 +0800 (CST) Date: Tue, 30 Jun 2009 15:12:22 +0800 From: Tina TSOU To: hannes.tschofenig@nsn.com, Victor Fajardo Message-id: <014401c9f952$1ce56540$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_n1jyOzJXzMnrWrTAopLzNA)" X-Priority: 3 X-MSMail-priority: Normal References: <3D3C75174CB95F42AD6BCC56E5555B4501711EDC@FIESEXC015.nsn-intra.net> <5DB86FE558C707408F58C3772801C2CA993E5B@S4DE9JSAANH.ost.t-com.de> Cc: dime@ietf.org Subject: Re: [Dime] HUM regarding draft-tsou-dime-realm-based-redirect-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 07:14:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_n1jyOzJXzMnrWrTAopLzNA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Hannes and Victor, What's your views of WG consensus for this? B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_n1jyOzJXzMnrWrTAopLzNA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi Hannes and Victor,
What's your views of WG consensus for this?
 
 
 
--Boundary_(ID_n1jyOzJXzMnrWrTAopLzNA)-- From julien.bournelle@gmail.com Tue Jun 30 00:15:47 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4196D28C32F for ; Tue, 30 Jun 2009 00:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4H3kXP-TwD1 for ; Tue, 30 Jun 2009 00:15:46 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 3AEED28C332 for ; Tue, 30 Jun 2009 00:15:45 -0700 (PDT) Received: by ewy6 with SMTP id 6so6358502ewy.37 for ; Tue, 30 Jun 2009 00:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=RD7KDcYSnEogUfWttvsbWeOezxztcy6QLZ/ZV6gvvvg=; b=Yn8h4AuhsgpT7YFNr8pKZO5zEcGenxPjf73kSfW+78etZoG8SXN4Krb83JZBDFRGq4 oGjvXwNQN2PZhesNwlE+fHWBVA6rQPSrMdRrs+c/9knlUOulYkfVE+Iw4iuQkrOj5hZj vsYETjB0bs/cJv2hFjGMkcZQydKg7GYfPOnx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=azK9qLYCrWvVmwfQQUtdrPBDNIcgJ2MWTzZ+eYBi2K/QAGyxovTSq0SYGJdEoeaUHw H8N0JXPoubTaAs62jTDPGoWc1PRP2Y66T117wpwWqt/4+oVt5FNwi0SoniNLZnfnqxMb pCb2/zdHGYHQuK2el2gF7GatBV216qvoIZBe8= MIME-Version: 1.0 Received: by 10.216.28.85 with SMTP id f63mr2288010wea.142.1246346150122; Tue, 30 Jun 2009 00:15:50 -0700 (PDT) Date: Tue, 30 Jun 2009 09:15:50 +0200 Message-ID: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> From: Julien Bournelle To: dime@ietf.org Content-Type: multipart/alternative; boundary=0016e6d99e6e8b965d046d8b930c Subject: [Dime] ERP/Routing Issue ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 07:15:47 -0000 --0016e6d99e6e8b965d046d8b930c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, Let's start a thread on the so-called routing issue within ERP to see if we agree on the problem statement. Let's take the roaming scenario. We have on the path for the initial authentication (simple scenario): the peer (eap/erp), the NAS, a AAA proxy and the AAA/EAP server. Let's assume that AAA and EAP server are colocated. To authenticate the peer, the NAS creates a Diameter session with the AAA proxy. The AAA proxy creates a session the home AAA/EAP server. The EAP authentication occurs. If the peer moves to a new NAS (target NAS), the t_NAS will create a new Diameter session with a AAA proxy. If we have different AAA proxies, it may contact another AAA proxy than the one on the initial path. If some ERP keying material was sent to the initial AAA proxy, we have a problem because the target NAS has currently no way to contact the correct AAA proxy. If we have only one AAA proxy, we don't have problem. Before going further, can we agree on this ? Regards, Julien --0016e6d99e6e8b965d046d8b930c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

=A0Let's start a thread on the so-called routing issue <= br>within ERP to see if we agree on the problem statement.

=A0Let= 9;s take the roaming scenario. We have on the path for
the initial auth= entication (simple scenario): the peer (eap/erp),
the NAS, a AAA proxy and the AAA/EAP server.
=A0
=A0Let's assume = that AAA and EAP server are colocated.

=A0To authenticate the peer, = the NAS creates a Diameter
session with the AAA proxy. The AAA proxy cre= ates a
session the home AAA/EAP server. The EAP authentication occurs.

=A0I= f the peer moves to a new NAS (target NAS), the t_NAS will
create a new = Diameter session with a AAA proxy. If we have
different AAA proxies, it = may contact another AAA proxy than the
one on the initial path. If some ERP keying material was sent to
the ini= tial AAA proxy, we have a problem because the target NAS
has currently n= o way to contact the correct AAA proxy.

=A0If we have only one AAA p= roxy, we don't have problem.

=A0Before going further, can we agree on this ?

=A0Regards,
<= br>=A0Julien

--0016e6d99e6e8b965d046d8b930c-- From sunseawq@huawei.com Tue Jun 30 01:03:07 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF6828C32E for ; Tue, 30 Jun 2009 01:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paubF1tNNw6p for ; Tue, 30 Jun 2009 01:03:06 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 211C328C325 for ; Tue, 30 Jun 2009 01:03:06 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM100GBAL0U8D@szxga01-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 16:02:54 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM100E06L0URV@szxga01-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 16:02:54 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM10083KL0UT1@szxml06-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 16:02:54 +0800 (CST) Date: Tue, 30 Jun 2009 16:02:54 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <038d01c9f959$2c4c4010$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> <4A49B407.6040903@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 08:03:07 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: "Behcet Sarikaya" ; Sent: Tuesday, June 30, 2009 2:43 PM Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 > Hi again, > >> [Qin]: I agree, In that sense, we need to define a generic session-Id in ERP which is used between Diameter Client and Server, am I right? >> > We need this Session-Id in Diameter. I am not sure if the Id must be > retrieved from ERP and propagated to Diameter, or retrieved directly by > Diameter. At the time I wrote the draft, I was only thinking to the > second choice, but managing this Id in ERP (maybe as opaque data) might > simplify the process, and is worth investigation. [Qin]: As decribed in the section 8.8 of RFC3588, " The Session-Id is created by the Diameter application initiating the session, which in most cases is done by the client. " That's to say, session-Id is relevant to the Diameter application. If we agree that we need a new application between NAS and Diameter AAA server, I think Session-Id is apparently necessary. On the other hand, Session-Id is used to distinguish one authentication exchange from another run by the client, e.g., the mobile bootstrapping from one AAA domain and move within this AAA domain, the authentications happen twice, one is full EAP authentication, the other is Re-authentication, that is to say we need to define two different Session-ID to differentiate between them, Am I right? >> [Qin]: Since ERP is method indpendent mechanism, In my opinion, we don't need to consider Session Id created by method, right? >> Session Id created by method consist of Nonce or Rand which are used to generate key materials,e.g.,EMSK. >> > Yes, I think it is better that Diameter does not need to understand the > internals of EAP as much as possible :) > >> As regarding Diameter Session-Id, I have no objection to add it in ERP, However I am not quite sure why we need to define such Session-Id? >> > As I answered to the first question in this mail, I was not considering > adding this Diameter Session-Id inside ERP so far. I was just pointing > out that we need the new NAS to "have" a Session-Id, for peers that are > using ERP to authenticate. This Session-Id is either new (then we need > correlation with the previous Session-Id in the accounting server or ER > server) or the same (then we need a mechanism to acquire this Session-Id > in the NAS). [Qin]: So we have two choices: 1. ERP defines Session-Id 2. NASReq defines Session-Id right? >> One obvious reason occured to me is used for accounting, am I right? is there any other reason? >> > I was also thinking about accounting, but there may be other uses. > > At this point, I don't know what is the best way to proceed to correlate > the session information between previous and new authenticator, with > regards to accounting. It might be worth having a brainstorm on this > topic at Stockholm, if people are interested... [Qin]: I agree with you. It is too complicated thing to correlate session between previous and new authenticator when inter-authenticator handover frequently happens. > I guess the main "philosophical" question here is: From the Diameter > point of view, after handover and ERP re-authentication, are we > continuing the same session, or is it a new session? [Qin]: It is not necessary, the Session in relation to the Session-Id has nothing to do with mobility session, in my opinion. The only role of Session-Id is used to differentiate one authentication exchange from another, So each time Re-authentication happens, there will be a new Session Id to be created, am I right? > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Tue Jun 30 01:35:53 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BD53A6E17 for ; Tue, 30 Jun 2009 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52yucva3QbhH for ; Tue, 30 Jun 2009 01:35:52 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id EE6833A6BE0 for ; Tue, 30 Jun 2009 01:35:51 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n5U8ZU2N014260; Tue, 30 Jun 2009 17:35:31 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n5U8ZU5X022619; Tue, 30 Jun 2009 17:35:30 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n5U8ZUVK022616; Tue, 30 Jun 2009 17:35:30 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id AFEE8168B3; Tue, 30 Jun 2009 17:35:30 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id AA48E168B1; Tue, 30 Jun 2009 17:35:30 +0900 (JST) Message-ID: <4A49CE4B.7040702@nict.go.jp> Date: Tue, 30 Jun 2009 17:35:23 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Qin Wu References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> <4A49B407.6040903@nict.go.jp> <038d01c9f959$2c4c4010$260ca40a@china.huawei.com> In-Reply-To: <038d01c9f959$2c4c4010$260ca40a@china.huawei.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 08:35:53 -0000 Hi again, > [Qin]: As decribed in the section 8.8 of RFC3588, > " > The Session-Id is created by the Diameter application initiating the > session, which in most cases is done by the client. > " > That's to say, session-Id is relevant to the Diameter application. I don't think this is true. For example, the same Session-Id that is created by NASREQ application is re-used in accounting (another Diameter application). The Session-Id simply provides a way to correlate messages that are linked together. I guess that this definition of "linked together" really depends on the application(s) and the way they interface. > If we agree that we need a new application between NAS and Diameter AAA server, > I think Session-Id is apparently necessary. > In any case, the NAS will need to know a Session-Id, for sending accounting records for example. > On the other hand, Session-Id is used to distinguish one authentication exchange from another run by the client, e.g., the mobile bootstrapping from one AAA domain and move within this AAA domain, the authentications happen twice, one is full EAP authentication, the other is Re-authentication, that is to say we need > to define two different Session-ID to differentiate between them, Am I right? > On the NAS, the "life" of the Session-Id is greater than the authentication alone. It is valid until a STA message is received for the session (unless for stateless servers?) Anyway, on the servers, I think it depends on how the application(s) are designed... > [Qin]: So we have two choices: > 1. ERP defines Session-Id > 2. NASReq defines Session-Id > right? > I think so, yes. > [Qin]: I agree with you. It is too complicated thing to correlate session between previous and new authenticator when inter-authenticator handover > frequently happens. > It is not necessarily complicated. The ER server may cache the session information, and inform the NAS with the ERP response. Just a thought... >> I guess the main "philosophical" question here is: From the Diameter >> point of view, after handover and ERP re-authentication, are we >> continuing the same session, or is it a new session? >> > > [Qin]: It is not necessary, the Session in relation to the Session-Id has nothing to do with mobility session, in my opinion. > The only role of Session-Id is used to differentiate one authentication exchange from another, So each time Re-authentication happens, > there will be a new Session Id to be created, am I right? > That is an open issue. We may also choose to always re-use the same Session-Id than created during the first full EAP authentication. I don't know the pro & cons of each possibility yet. Thanks, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Tue Jun 30 02:44:14 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9EED28C357 for ; Tue, 30 Jun 2009 02:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWeKTUUTz9UL for ; Tue, 30 Jun 2009 02:44:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E6ABF28C1E9 for ; Tue, 30 Jun 2009 02:43:47 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM100BZ8PO4BY@szxga03-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 17:43:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM100HOOPO4JL@szxga03-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 17:43:16 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM1006ASPO37W@szxml04-in.huawei.com> for dime@ietf.org; Tue, 30 Jun 2009 17:43:16 +0800 (CST) Date: Tue, 30 Jun 2009 17:43:14 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <043201c9f967$30a46e40$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> <4A49B407.6040903@nict.go.jp> <038d01c9f959$2c4c4010$260ca40a@china.huawei.com> <4A49CE4B.7040702@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 09:44:15 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: Sent: Tuesday, June 30, 2009 4:35 PM Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 > Hi again, > > >> [Qin]: As decribed in the section 8.8 of RFC3588, >> " >> The Session-Id is created by the Diameter application initiating the >> session, which in most cases is done by the client. >> " >> That's to say, session-Id is relevant to the Diameter application. > I don't think this is true. For example, the same Session-Id that is > created by NASREQ application is re-used in accounting (another Diameter > application). The Session-Id simply provides a way to correlate messages > that are linked together. I guess that this definition of "linked > together" really depends on the application(s) and the way they interface. [Qin]: So your point is Session-Id is independent of application and can be used by multiple applications. Session-Id and Acct-Session-Id can be the identical, right? >> If we agree that we need a new application between NAS and Diameter AAA server, >> I think Session-Id is apparently necessary. >> > In any case, the NAS will need to know a Session-Id, for sending > accounting records for example. [Qin] Okay. >> On the other hand, Session-Id is used to distinguish one authentication exchange from another run by the client, e.g., the mobile bootstrapping from one AAA domain and move within this AAA domain, the authentications happen twice, one is full EAP authentication, the other is Re-authentication, that is to say we need >> to define two different Session-ID to differentiate between them, Am I right? >> > On the NAS, the "life" of the Session-Id is greater than the > authentication alone. It is valid until a STA message is received for > the session (unless for stateless servers?) Anyway, on the servers, I > think it depends on how the application(s) are designed... [Qin] I don't catch your meaning here, can you give me more explanation? >> [Qin]: So we have two choices: >> 1. ERP defines Session-Id >> 2. NASReq defines Session-Id >> right? >> > I think so, yes. > >> [Qin]: I agree with you. It is too complicated thing to correlate session between previous and new authenticator when inter-authenticator handover >> frequently happens. >> > It is not necessarily complicated. The ER server may cache the session > information, and inform the NAS with the ERP response. Just a thought... [Qin]: Feasible. >>> I guess the main "philosophical" question here is: From the Diameter >>> point of view, after handover and ERP re-authentication, are we >>> continuing the same session, or is it a new session? >>> >> >> [Qin]: It is not necessary, the Session in relation to the Session-Id has nothing to do with mobility session, in my opinion. >> The only role of Session-Id is used to differentiate one authentication exchange from another, So each time Re-authentication happens, >> there will be a new Session Id to be created, am I right? >> > That is an open issue. We may also choose to always re-use the same > Session-Id than created during the first full EAP authentication. I > don't know the pro & cons of each possibility yet. [Qin]: right. Maybe it is easy operated to use the same Session-Id for Accouting in the inter-authenticator handover scenario which does not need extra operations to update the session. > Thanks, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From Mark.Jones@bridgewatersystems.com Tue Jun 30 08:25:11 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8782B28C3F9; Tue, 30 Jun 2009 08:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-TBPBoDvWeg; Tue, 30 Jun 2009 08:25:09 -0700 (PDT) Received: from anders.electric.net (anders.electric.net [72.35.23.15]) by core3.amsl.com (Postfix) with ESMTP id 6952228C3D6; Tue, 30 Jun 2009 08:25:07 -0700 (PDT) Received: from 1MLfBE-0000qZ-T2 by anders.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1MLfBE-0000rM-Tj; Tue, 30 Jun 2009 08:23:32 -0700 Received: by emcmailer; Tue, 30 Jun 2009 08:23:32 -0700 Received: from [72.35.6.119] (helo=mail.bridgewatersystems.com) by anders.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1MLfBE-0000qZ-T2; Tue, 30 Jun 2009 08:23:32 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 30 Jun 2009 11:23:31 -0400 From: Mark Jones To: "Reith, Lothar" , "dime@ietf.org" Date: Tue, 30 Jun 2009 11:23:30 -0400 Thread-Topic: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard Thread-Index: AcnyIyBlhwCA0wyYT8+j1vTCsLFDMAAlEIgQAbPC6RA= Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034CEA@m679t05.fpmis.bridgewatersys.com> References: <016501c9e5c8$9e730dd0$db592970$@net><031a01c9f000$460eefa0$260ca40a@china.huawei.com><4A3A3F6B.804@tari.toshiba.com> <008f01c9f221$05d0c3a0$2101a8c0@756BFB16836341A> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 750505 X-Virus-Status: Scanned by VirusSMART (c) Cc: "iesg-secretary@ietf.org" Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 15:25:12 -0000 Hi Lothar, Thanks for the thorough review. Comments inline.=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Reith, Lothar > Sent: June 21, 2009 5:54 PM > To: dime@ietf.org > Cc: iesg-secretary@ietf.org > Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-attributes=20 > (Quality of Service Attributes for Diameter) to Proposed Standard >=20 > =20 > Dear all, >=20 > please find below a list of comments regarding the Last Call=20 > on: draft-ietf-dime-qos-attributes (Quality of Service=20 > Attributes for Diameter) to Proposed Standard >=20 > Where applicable, I have stated the issue and a proposed=20 > solution to fix the issue. >=20 > 1. issue: in Section 3.1 it is stated that > "QoS Resources AVP .......describes a list of policies"=20 >=20 > however, the ABNF definition in the line below specifies that=20 > the QoS Resource AVP contains a list of QoS-Rules.=20 >=20 > proposed solution: replace "describes a list of policies" by =20 > "contains a list of QoS-Rules" >=20 > Background: > The question is if the term policies and QoS-Rules are meant=20 > synonymous in the context of the document. If that is the=20 > case, I suggest to replace the term "policies" with=20 > "Qos-Rules", as it is the only occurance of that term within=20 > the document. If that is not the case, the meaning of the=20 > term policy in this document needs be defined, given that the=20 > term "policy" is somewhat overloaded. For example, one could=20 > define, that the terms "policy" and "QoS-Rule" are being used=20 > synonymously in the context of the document, except when=20 > referring to RFC5226 as a policy. Or one could state that a=20 > "QoS-Rule" is a type of "policy".=20 >=20 > Alternative Solution: replace "describes a list of policies"=20 > by "contains a list of policy rules"=20 >=20 Agreed. We change this to "list of QoS policy rules" in the next revision. > 2. issue: section 4.1.8.23 discusses Ethernet=20 > "user-priority". I would recommend to review with IEEE on=20 > this to verify if "user-priority" or "P-bits" would be the=20 > most appropriate term.=20 We've reused the terms from the IEEE specs wherever possible. The IEEE 802.= 1D-2004 spec uses "user_priority parameter" rather than "P-bits" and so we = assumed this was the most appropriate term. > In addition, there seems to no=20 > consideration yet for the "drop eligibility indicator"=20 > contained in an S-Tag with Ethertype 0x88a8. It should be=20 > possible to formulate a QoS-Rule which considers the "drop=20 > eligibility indicator". Also it should be possible to=20 > formulate a mark action, which sets the value of the "drop=20 > eligibility indicator" bit to 1. Along these lines, it should=20 > also be possible to formulate a QoS-Rule which considers MPLS=20 > EXP Bits of an incoming packet. And it should be possible to=20 > mark MPLS EXP bits. >=20 This draft does not claim exhaustive support for all ethertype flags and fe= atures. The IEEE features will contine to be a moving target and so we focu= sed on the ones required to satisfy current SDO requirements while ensuring= that all the groups AVPs can be easily extended to handle new features.=20 > 3. issue in section 4.2.1: charging granularity not compliant=20 > with consumer protection legislation (at least in Germany) > Proposed Solution: I would recommend to multiply the values=20 > by 10, in order to arrive at a granularity of one tenth of a=20 > second (split-second). This would allow to comply with some=20 > consumer protection regulations in the area of charging=20 > accuracy, such as a "telecommunication customer protection=20 > law" effective in Germany. I know of one voice switch vendor,=20 > who had to reprogramm his voice-switch accounting software=20 > because of that law, as a metering granularity of one second=20 > was not good enough to meet the legal demands in all cases.=20 > This was due to the possible errors in measuring the time at=20 > the start of a call and at the end of a call could add up to=20 > more than one second, even though the time measurement itself=20 > had a granularity of one second. As a minimum, the range must=20 > be doubled to a measurement granularity of a half-second, in=20 > order to be on the safe side regarding compliance with this law. >=20 Agreed. We propose keeping the existing AVPs which use the Diameter Time da= tatype and adding a "fractional" AVP of type Unsigned32 to add additional p= recision to both the absolute and relative timestamps in the draft. > 4.issues in section 5.1 the actions drop, shape and mark may=20 > require some further scrutiny and refinement >=20 > 4.1 Issue regarding the drop action: Drop action does not=20 > differentiate, if the dropped packet shall get accounted. > one possible solution (not necessary the proposed solution):=20 > differentiate between > - drop without counting, i.e. drop without charging for the=20 > delivery to the point, where the packet gets dropped, because=20 > the packet did not get delivered to the customer, such as=20 > discarding unsolicited out of profile downstream traffic from=20 > some source in the Internet. > - drop after counting, i.e. drop with charging for the=20 > delivery of the packet to the point where it got discarded=20 > (if legally allowed). This may be applicable to out of=20 > profile upstream traffic. >=20 This is a QoS AVP draft and we have purposely avoided introducing charging = aspects in the actions. The AVPs that determine the charging characteristic= s associated with the actions can always be added by applications that use = these QoS AVPs and additionally require charging. > 4.2 Issue regarding a lack of unambiguity of the definition=20 > of the shape action: > - shape to which token bucket size and depletion rate? This is covered in the companion I-D on QoS-Parameters (draft-ietf-dime-qos= -parameters). > - which bytes of the incoming packet count for depleting the=20 > token bucket? All bytes of the layer 2 Frame in case of a=20 > QoS-Rule at the Ethernet layer, where an IP header may not=20 > even be present? In this context: Is the term bandwidth in=20 > the "bandwidth AVP" defined as "net data rate" as in ANCP, or=20 > differently defined or undefined?=20 >=20 This is not defined currently in the QoS-Parameters draft. We feel this kin= d of detail will be ironed out when the actual deployment gets done and the= operator then states which part of the traffic contributes to the depletin= g counters.=20 > 4.3. Issue regarding the completeness of the scope of the mark action: > - only TOS byte, or also MPLS EXP bits and Ethernet P-bits ? > - only absolute mark, or also remarking rule that depends on=20 > the previous setting the field? > Proposed solution regarding the first item: split the mark=20 > action into 3 different mark actions, mark-TOS byte,=20 > mark-MPLS_EXP-bit and mark-P-bits. Consider to allow the=20 > presence of multiple mark actions in a single QoS-Rule.=20 > Proposed solution regarding the second item: Add actions for=20 > re-mark-TOS byte, re-mark-MPLS_EXP-bit and re-mark-P-bits,=20 > where the result of the re-mark-action depends on the former=20 > setting of the field being re-marked. >=20 Please see response to comment 2. > 5. Issue in section 5.4 I do not quite understand the=20 > semantic differences between QoS Available, QoS Authorized=20 > and QoS Reserved, in particular if QoS Reserved is already=20 > accounting relevant.=20 > Solution: Verify and make sure that there is indeed a=20 > semantic difference, and that accounting for QoS Reserved is=20 > compliant with consumer protection laws. >=20 Agreed that we need to expand the description of these values. The QoS-Auth= orized is delivered by the Authorization Server. The QoS-Available is what = the client is able to apply (QoS-Available < QoS-Authorized). > 6. issue in section 7.5 there is an example on how this may=20 > apply in combination with Diameter Credit Control, and it is=20 > stated there that " In this case the User is charged as soon=20 > as the Service Element (CC client) receives the service request. " > Proposed solution: Verify if a procedure which starts=20 > charging without knowing, if the the QoS-Resource can=20 > actually be allocated does not violate consumer protection laws. >=20 Agreed. We'll clarify this. Charging for a given QoS must not start before = the QoS-Resource is reserved. > 7. reading further on in this short section 7.5 it states the=20 > following: > "In this case the client uses the "QoS-Desired"=20 > QoS-Semantics parameter in the QoS-Resources AVP that it=20 > sends to the Accounitng server. The server responds with a=20 > "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP" >=20 This is a typo and the server responds with QoS-Authorized as shown in Figu= re 6. > This raises some doubts if the "accounting server" acts as an=20 > authorization server. There should be clear separation of=20 > accounting and authorization. > Proposed solution: Change the wording to make clear, that the=20 > accounting server does not authorize anything, otherwise, do=20 > not call it an accounting server, but rather an=20 > authorization and accounting server, which would imply that=20 > both functions are combined in one server (which in large=20 > implementations is usually not the case).=20 >=20 Agreed that the accounting server does not authorize QoS. We'll separate th= ese two functions onto distinct servers for clarity.=20 > 8. reading further on, there is a Message shown "CCA=20 > (Granted-Units, QoS-Resources(QoS-Authorized))" which makes=20 > me wonder, what is being authorized here with DCC. Is it an=20 > authorization for a certain number of granted-Units delivered=20 > with a higher QoS and charged extra using a one time charge=20 > because of delivering these granted units with higher QoS? >=20 > If that would be the case, it would in my view be a bad=20 > practice, as the one-time charge mechanism would effectively=20 > be used for session based charging, but without the=20 > reservation mechanism. What happens, if the Granted-Units=20 > cannot be delivered with the higher QoS, say in case of an=20 > outage?=20 We are certainly not proposing a change in DCCA behaviour. Even if the QoS = was reserved, an outage could still prevent delivery as you point out. Pers= umably, if Granted-Units (with/without QoS-Reserved) can not be subsquently= delivered then the DCCA refund procedure would apply. > Session based charging can handle this by means of=20 > not confirming the reservation within a time limit. It would=20 > require extra complex logic to handle this situation, where=20 > the One-Time charge would have to be cancelled or compensated=20 > by a one-time bonus of same amount. >=20 > Proposed solution for issue 8: Use another example, which=20 > does not suggest to re-invent session based online charging=20 > using one-time charging events. >=20 Agreed. We have no intention of reinventing DCCA here. We'll either clarify= ensuring DCCA compliance or use a non-DCCA example. Regards Mark >=20 > Best Regards, >=20 >=20 > Lothar Reith >=20 > Competence Practice Communications Technology >=20 > Detecon International GmbH=A0 > Oberkasseler Str. 2=A0 > 53227 Bonn - Germany > =A0 > Phone:=A0+49 228 700 2958 > Mobile: +49 175 580 4892 > Fax: +49 228 700 2107 > mailto:lothar.reith@detecon.com=20 > http://www.detecon.com=20 >=20 > Detecon International GmbH > Aufsichtsrat: Hans-J=FCrgen Wickenh=F6fer (acting) > Gesch=E4ftsf=FChrung: Dr. Klaus Hofmann, Andreas Baumann > Handelsregister: Amtsgericht Bonn HRB 2093 > Sitz der Gesellschaft: Bonn >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > [Dime]Last Call: draft-ietf-dime-qos-attributes (Quality of=20 > Service Attributes for Diameter) to Proposed Standard >=20 > * To: IETF-Announce > * Subject: [Dime] Last Call:=20 > draft-ietf-dime-qos-attributes (Quality of Service Attributes=20 > for Diameter) to Proposed Standard > * From: The IESG > * Date: Mon, 8 Jun 2009 07:08:51 -0700 (PDT) > * Cc: dime at ietf.org > * Delivered-to: dime at core3.amsl.com > * List-archive: > * List-help: > * List-id: Diameter Maintanence and Extentions Working=20 > Group > * List-post: > * List-subscribe:=20 > ,=20 > > * List-unsubscribe:=20 > ,=20 > > * Reply-to: ietf at ietf.org >=20 > The IESG has received a request from the Diameter Maintenance and=20 > Extensions WG (dime) to consider the following document: >=20 > - 'Quality of Service Attributes for Diameter ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive=20 > comments to the > ietf at ietf.org mailing lists by 2009-06-22. Exceptionally,=20 > comments may be sent to iesg at ietf.org instead. In either=20 > case, please=20 > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib > utes-12.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D16192&rfc_flag=3D0 >=20 > * Prev by Date: [Dime] WGLC Comments on=20 > draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20 > * Next by Date: Re: [Dime] New draft for Diameter ERP:=20 > poll for adoption > * Previous by thread: [Dime] WGLC Comments on=20 > draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20 > * Next by thread: [Dime] Fwd: New Version Notification=20 > for draft-korhonen-dime-mip6-feature-bits-01 > * Index(es): > o Date > o Thread >=20 > Note: Messages sent to this list are the opinions of the=20 > senders and do not imply endorsement by the IETF.=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = From behcetsarikaya@yahoo.com Tue Jun 30 09:26:27 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C5D3A6B48 for ; Tue, 30 Jun 2009 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q16HCvSPvW+x for ; Tue, 30 Jun 2009 09:26:25 -0700 (PDT) Received: from n71.bullet.mail.sp1.yahoo.com (n71.bullet.mail.sp1.yahoo.com [98.136.44.36]) by core3.amsl.com (Postfix) with SMTP id B092B3A6B26 for ; Tue, 30 Jun 2009 09:26:25 -0700 (PDT) Received: from [69.147.84.144] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 30 Jun 2009 16:26:10 -0000 Received: from [67.195.9.81] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 30 Jun 2009 16:26:10 -0000 Received: from [67.195.9.104] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 16:26:10 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 16:26:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 303008.79730.bm@omp108.mail.gq1.yahoo.com Received: (qmail 45762 invoked by uid 60001); 30 Jun 2009 16:26:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246379169; bh=YVI5Ce9X5Lde8RYncV3HFiZfzdaWU2HyyWkiqyZZY6I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nap9NsXUuKEvjXkHwJE2bNmwnN0u0j71LzpBPs5AMUUDsWusX6KfQxf6DwXAgYSobS46eAEGM8iH8nEvsQB7fmdpPonXN5ZWk4oWwrtqOIINyEazihfn/HkmKQlUB0ME8GHQbBHaYv1lBZydiSUV8+Gx6iWI2NbikS0B7o15mkg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qt9Xfzck7ez8ejBs9UytTPXRtFjj/UdyjgX58fXbNSG5gQleK8gK7QRdBzIko1LfHhVcj1cmtRHHgfNO9eYC6Mr6AEeOGW76f8j2cAL2xabAYW9vx53wa8bi4D0h1Gth5emHxCrHRztsowT6BTwz/sEiWif9x2pa89B55FOElJA=; Message-ID: <989276.34190.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: 5LMll2AVM1mQdZRBj0GnVzsTPMeC.dJuMJqgcTgjD.laLNTpRkMK5aZb_YWsy6yA0SrEhdjmaz49mgPBPnNRgNw5tiwstgQgtMusV5PYd8Y_W.xnK6lSa_t2EzHy5OFJdZrJ3ofWfUQz_Cv3h.J6xOd2O_PzJ6ooXaTtcoy2XFZQpXJOTxY7RY20ab2FDqbzyNNUM4p4B4P32yBErNJiR6guGWenn2tRgH7ib8HIu0SjhdPrGYhzsNJtZ4ge_Qd83niOO5LQ6_gEigD9pwdn9dNBH5Wy62xRsf._odLLkjyGIxmv_BVFJrCLfxdjKdYWPeteUQFff7nhqGNJSec0AHy3ng-- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Tue, 30 Jun 2009 09:26:09 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> Date: Tue, 30 Jun 2009 09:26:09 -0700 (PDT) From: Behcet Sarikaya To: Qin Wu In-Reply-To: <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:26:27 -0000 Hi all,=0A=A0 ERP is executed after a full EAP authentication which uses on= e of the EAP methods. I don't think in that sense ERP is EAP method indeped= ent.=0AI think that Session-Id here refers to the EAP method generated Sess= ion-ID. RFC 5247 requires each EAP method to export a Session-ID. Most EAP = methods have defined their way of generating Session-Ids.=0A=0ARegards,=0A= =0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From: Qin Wu =0A> To: Sebastien Decugis =0A> Cc: Behcet= Sarikaya ; dime@ietf.org=0A> Sent: Tuesday, June 30, 20= 09 1:15:31 AM=0A> Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-dia= meter-erp-01=0A> =0A> Hi, Sebastien:=0A> =0A> ----- Original Message ----- = =0A> From: "Sebastien Decugis" =0A> To: "Qin Wu" =0A> Cc: "Behcet Sarikaya"= ; =0A> Sent: Tuesday, June 30, 2009 10:34 AM=0A> Subject: Re: [Dime] Sessi= on-ID in draft-sdecugis-dime-diameter-erp-01=0A> =0A> =0A> > Hi Qin,=0A> > = =0A> >> I think Session-Id described in RFC5247 is applicable for EAP Sessi= on and =0A> used between EAP peer and EAP server. Mobile device can be one = example of EAP =0A> peer. The Session-Id you mentioned is access authentica= tion session and used =0A> between AAA client and AAA server. I wonder whet= her they are the same thing.=0A> >> What am I missing?=0A> >>=A0 =0A> > No,= in my opinion these are two different concepts. For example, even=0A> > wh= en EAP is not used, a Session-Id AVP is created in Diameter.=0A> =0A> [Qin]= : I agree,=A0 In that sense, we need to define a generic session-Id in ERP = =0A> which is used between Diameter Client and Server, am I right?=0A> =0A>= >> In my opinion, each EAP authentication has a unique session-Id in relat= ion to =0A> the EAP method used, the Session-Id can be created by the EAP p= eer or EAP =0A> server. Am I right?=0A> >>=A0 =0A> > I was not aware that E= AP methods also created a Session Id (or is it the=0A> > EMSK KeyName?). An= yway, AFAIK, usually Diameter Session-Id AVP are=0A> > created based on the= User-Name, itself acquired from EAP Identity=0A> > Request/Response (in ca= se of EAP authentication). This exchange is not=0A> > performed in the case= of ERP (after a handover to a new NAS), so we=0A> > really need to define = what the (Diameter) Session-Id AVP will be in this=0A> > case, and how it i= s created/retrieved. Session-Id AVP is mandatory in=0A> > most Diameter mes= sages. That is what I tried to highlight in the draft.=0A> > I was not refe= rring to the EAP Session Id, there.=0A> > =0A> > I hope this clarifies,=0A>= =0A> [Qin]: Since ERP is method indpendent mechanism, In my opinion, we do= n't need to =0A> consider Session Id created by method, right?=0A> Session = Id created by method consist of Nonce or Rand which are used to generate = =0A> key materials,e.g.,EMSK.=0A> As regarding Diameter Session-Id, I have = no objection to add it in ERP, However =0A> I am not quite sure why we need= to define such Session-Id?=0A> One obvious reason occured to me is used fo= r accounting, am I right? is there =0A> any other reason?=0A> =0A> > Best r= egards,=0A> > Sebastien.=0A> > =0A> > -- =0A> > Sebastien Decugis=0A> > Res= earch fellow=0A> > Network Architecture Group=0A> > NICT (nict.go.jp)=0A> >= =0A=0A=0A=0A From Mark.Jones@bridgewatersystems.com Tue Jun 30 14:25:49 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605DB28C399 for ; Tue, 30 Jun 2009 14:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf+EptoVGdtE for ; Tue, 30 Jun 2009 14:25:48 -0700 (PDT) Received: from bean.electric.net (bean.electric.net [72.35.23.29]) by core3.amsl.com (Postfix) with ESMTP id EAA493A67AE for ; Tue, 30 Jun 2009 14:25:47 -0700 (PDT) Received: from 1MLkq8-0005CV-UU by bean.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1MLkq8-0005Cq-Un for dime@ietf.org; Tue, 30 Jun 2009 14:26:08 -0700 Received: by emcmailer; Tue, 30 Jun 2009 14:26:08 -0700 Received: from [72.35.6.119] (helo=mail.bridgewatersystems.com) by bean.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1MLkq8-0005CV-UU for dime@ietf.org; Tue, 30 Jun 2009 14:26:08 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 30 Jun 2009 17:26:08 -0400 From: Mark Jones To: "dime@ietf.org" Date: Tue, 30 Jun 2009 17:26:07 -0400 Thread-Topic: Review of draft-ietf-dime-rfc3588bis-17 Thread-Index: Acn5yWFUbN0yOTnPT8ayhLcwu/RFxg== Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034D1D@m679t05.fpmis.bridgewatersys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 750505 X-Virus-Status: Scanned by VirusSMART (c) Subject: [Dime] Review of draft-ietf-dime-rfc3588bis-17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 21:25:49 -0000 Here are my review comments for rfc3588bis-17. All are editorial. Regards Mark --- Section 1.3.1: Typo: s/where as/whereas/ Section 1.3.4: Rewording suggestion: has to be understood mandatorily or not To: must be understood or not Remove 2nd paragraph under "M-bit Setting" because MAY column has been remo= ved. =09 Section 2: Rewording suggestion: A Diameter Client that does not support both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Client" where X is the application which it supports, and not a "Diameter Client". To: A Diameter Client that supports a specific application X MUST be referre= d to as "Diameter X Client" and not a "Diameter Client". Rewording suggestion: A Diameter Server that does not support both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Server" where X is the application which it supports, and not a "Diameter Server". To: A Diameter Server that supports a specific application X MUST be referre= d to as=20 "Diameter X Server" and not a "Diameter Server". Rewording suggestion: A Diameter proxy which does not support both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X Proxy" where X is the application which it supports, and not a "Diameter Proxy". To: A Diameter Proxy that supports a specific application X MUST be referred= to as=20 "Diameter X Proxy" and not a "Diameter Proxy". Section 2.6: Missing period on last sentence in this section. Section 2.7: The last paragraph incorrectly implies that a proxy agent is somehow differ= ent when it comes to advertising supported applications. Only a relay does = not have to advertise the supported application ids because it supports eve= rything. Section 2.8: Typo: s/an number/a number/ Rewording suggestion: o A complex network will have multiple authentication sources, they can sort requests and forward towards the correct target. To: o For a complex network having multiple authentication sources, they can sort requests and forward towards the correct target. Section 2.8.1: Rewording Suggestion: common geographical area (POP) To: common geographical area or point of presence (POP) Rewording suggestion: NASes To: NAS Section 4.1: Suggestion: Remove mention of the 'P' bit in the AVP header. Make it reserv= ed. Section 4.5: No need to use DiamIdent in the AVP table since space constraint no longer = exists. I think the M-bit must be set for Error-Reporting-Host AVP but I guess this= causes backwards compatibility issues. Section 7.2: Remove "Message Format" below first paragraph. Section 8.2: Clarify that "state" here is session state, i.e.=20 Class AVPs found in a re-authorization answer message override the ones found in any previous authorization answer message for the same session. From sunseawq@huawei.com Tue Jun 30 19:07:21 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD7F3A6A68 for ; Tue, 30 Jun 2009 19:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fYYJYDHRABp for ; Tue, 30 Jun 2009 19:07:20 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9CD533A6877 for ; Tue, 30 Jun 2009 19:07:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM2003Y2Z8JEU@szxga04-in.huawei.com> for dime@ietf.org; Wed, 01 Jul 2009 10:07:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM2001TYZ8JPL@szxga04-in.huawei.com> for dime@ietf.org; Wed, 01 Jul 2009 10:07:31 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM2007LZZ8JMD@szxml04-in.huawei.com> for dime@ietf.org; Wed, 01 Jul 2009 10:07:31 +0800 (CST) Date: Wed, 01 Jul 2009 10:07:31 +0800 From: Qin Wu To: Behcet Sarikaya Message-id: <010c01c9f9f0$b1028750$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> <989276.34190.qm@web111402.mail.gq1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 02:07:21 -0000 Hi, Behcet: Full EAP authentication can be method specific and create EAP method specific session-Id, however, as described in RFC5296, ERP is a method independent protocol. Unless the ERP reuse the method specific Session-Id generated from Full EAP authentication, it seems difficult for ERP to create EAP method specific Session-Id. On the other hand, if ERP can create Session-Id that is independent of EAP, that's another case. Regards! -Qin ----- Original Message ----- From: "Behcet Sarikaya" To: "Qin Wu" Cc: Sent: Wednesday, July 01, 2009 12:26 AM Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 Hi all, ERP is executed after a full EAP authentication which uses one of the EAP methods. I don't think in that sense ERP is EAP method indepedent. I think that Session-Id here refers to the EAP method generated Session-ID. RFC 5247 requires each EAP method to export a Session-ID. Most EAP methods have defined their way of generating Session-Ids. Regards, Behcet ----- Original Message ---- > From: Qin Wu > To: Sebastien Decugis > Cc: Behcet Sarikaya ; dime@ietf.org > Sent: Tuesday, June 30, 2009 1:15:31 AM > Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 > > Hi, Sebastien: > > ----- Original Message ----- > From: "Sebastien Decugis" > To: "Qin Wu" > Cc: "Behcet Sarikaya" ; > Sent: Tuesday, June 30, 2009 10:34 AM > Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 > > > > Hi Qin, > > > >> I think Session-Id described in RFC5247 is applicable for EAP Session and > used between EAP peer and EAP server. Mobile device can be one example of EAP > peer. The Session-Id you mentioned is access authentication session and used > between AAA client and AAA server. I wonder whether they are the same thing. > >> What am I missing? > >> > > No, in my opinion these are two different concepts. For example, even > > when EAP is not used, a Session-Id AVP is created in Diameter. > > [Qin]: I agree, In that sense, we need to define a generic session-Id in ERP > which is used between Diameter Client and Server, am I right? > > >> In my opinion, each EAP authentication has a unique session-Id in relation to > the EAP method used, the Session-Id can be created by the EAP peer or EAP > server. Am I right? > >> > > I was not aware that EAP methods also created a Session Id (or is it the > > EMSK KeyName?). Anyway, AFAIK, usually Diameter Session-Id AVP are > > created based on the User-Name, itself acquired from EAP Identity > > Request/Response (in case of EAP authentication). This exchange is not > > performed in the case of ERP (after a handover to a new NAS), so we > > really need to define what the (Diameter) Session-Id AVP will be in this > > case, and how it is created/retrieved. Session-Id AVP is mandatory in > > most Diameter messages. That is what I tried to highlight in the draft. > > I was not referring to the EAP Session Id, there. > > > > I hope this clarifies, > > [Qin]: Since ERP is method indpendent mechanism, In my opinion, we don't need to > consider Session Id created by method, right? > Session Id created by method consist of Nonce or Rand which are used to generate > key materials,e.g.,EMSK. > As regarding Diameter Session-Id, I have no objection to add it in ERP, However > I am not quite sure why we need to define such Session-Id? > One obvious reason occured to me is used for accounting, am I right? is there > any other reason? > > > Best regards, > > Sebastien. > > > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp) > > From sdecugis@nict.go.jp Tue Jun 30 19:10:24 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42583A6A99 for ; Tue, 30 Jun 2009 19:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iu7ilgY8q8K for ; Tue, 30 Jun 2009 19:10:23 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 1A6E43A68D3 for ; Tue, 30 Jun 2009 19:10:22 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n612APKb016081; Wed, 1 Jul 2009 11:10:25 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n612APAU011760; Wed, 1 Jul 2009 11:10:25 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n612APbF011757; Wed, 1 Jul 2009 11:10:25 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 6676116400; Wed, 1 Jul 2009 11:10:25 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 605AD2B1C; Wed, 1 Jul 2009 11:10:25 +0900 (JST) Message-ID: <4A4AC58A.7050909@nict.go.jp> Date: Wed, 01 Jul 2009 11:10:18 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Qin Wu References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> <4A49B407.6040903@nict.go.jp> <038d01c9f959$2c4c4010$260ca40a@china.huawei.com> <4A49CE4B.7040702@nict.go.jp> <043201c9f967$30a46e40$260ca40a@china.huawei.com> In-Reply-To: <043201c9f967$30a46e40$260ca40a@china.huawei.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 02:10:24 -0000 Hi Qin, > [Qin]: So your point is Session-Id is independent of application and can be used by multiple applications. > Session-Id and Acct-Session-Id can be the identical, right? > According to its definition, Acct-Session-Id is only used for RADIUS/Diameter translation, not in pure Diameter deployments. I think only Session-Id is needed in that case. >> On the NAS, the "life" of the Session-Id is greater than the >> authentication alone. It is valid until a STA message is received for >> the session (unless for stateless servers?) Anyway, on the servers, I >> think it depends on how the application(s) are designed... >> > > [Qin] I don't catch your meaning here, can you give me more explanation? > Sorry it was not clear :) What I want to say is : the Session-Id (in Diameter meaning) represents the provision of a service to a peer (a session). All messages related to this session should contain the same Session-Id. Anyway, which servers are involved in the process may change during the lifetime of this session. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp)