Re: [Dime] Comments on draft-ietf-dime-erp-03.txt
Sebastien Decugis <sdecugis@nict.go.jp> Tue, 16 March 2010 08:01 UTC
Return-Path: <sdecugis@nict.go.jp>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3A83A6874 for <dime@core3.amsl.com>; Tue, 16 Mar 2010 01:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.055
X-Spam-Level:
X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 5cXoO1x7Nfkp for <dime@core3.amsl.com>; Tue, 16 Mar 2010 01:01:07 -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 D1EA83A659A for <dime@ietf.org>; Tue, 16 Mar 2010 01:00:59 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o2G8157G016832 for <dime@ietf.org>; Tue, 16 Mar 2010 17:01:05 +0900 (JST)
Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o2G815mG000493 for <dime@ietf.org>; Tue, 16 Mar 2010 17:01:05 +0900 (JST)
Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o2G815VE000490 for <dime@ietf.org>; Tue, 16 Mar 2010 17:01:05 +0900 (JST)
Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 042E82C2AC for <dime@ietf.org>; Tue, 16 Mar 2010 17:01:05 +0900 (JST)
Received: from [133.243.146.169] (5gou2f-dhcp09.nict.go.jp [133.243.146.169]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 007FB2C29A for <dime@ietf.org>; Tue, 16 Mar 2010 17:01:04 +0900 (JST)
Message-ID: <4B9F3AB6.4060609@nict.go.jp>
Date: Tue, 16 Mar 2010 17:00:54 +0900
From: Sebastien Decugis <sdecugis@nict.go.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: dime@ietf.org
References: <001501cac04d$390cdec0$ab269c40$@net>
In-Reply-To: <001501cac04d$390cdec0$ab269c40$@net>
X-Enigmail-Version: 1.0.1
OpenPGP: id=33D9F61D
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Dime] Comments on draft-ietf-dime-erp-03.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2010 08:01:09 -0000
Hi, sorry for late reply. Preliminary question: what is "Network Working Group" ? > I wonder what the purpose of this paragraph might be: why would it be > necessary to configure Diameter routing at all? It is necessary to configure it in the case of an explicit bootstrapping request, since the NAI contains the home server, but we want to bootstrap the local server (if any). In any other case, there should be no conflict : default Diameter routing would send the message to this local ER server anyway. If we do not configure the routing explicitly, the message will go to the home domain, and might not pass through the local ER server. In such case, we loose the benefit of this local server. > There seems to be some confusion here: an ER server will _never_ receive an > ERP/DER message, since that is a _Diameter_ message, not an EAP message. > Actually, the confusion starts in the Introduction: "a new Diameter ERP > application to transport ERP messages between an ER authenticator and the ER > server". "Authenticator" is a technical term & refers to an EAP protocol > entity, not a Diameter entity, so how can send Diameter messages? Clearing > up this confusion might go a long way toward making an acceptable > specification. > No you mean that we have to define yet *another* protocol to transport the ERP message between a Diameter entity (that receives the Diameter ERP request) and the ER server ? Seems like recursive to me if we don't accept that the ER server *has* to talk "Diameter" as well... I will be glad to discuss this further in Anaheim. About the term "authenticator", I confess it is unclear to me what the difference is between all the terminology for this entity (the one that actually decides if the peer gets access or not, and generates the Diameter EAP request in full EAP authentication scenario). Is "NAS" better? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp)
- [Dime] Comments on draft-ietf-dime-erp-03.txt Glen Zorn
- Re: [Dime] Comments on draft-ietf-dime-erp-03.txt Tina TSOU
- Re: [Dime] Comments on draft-ietf-dime-erp-03.txt Qin Wu
- Re: [Dime] Comments on draft-ietf-dime-erp-03.txt Qin Wu
- Re: [Dime] Comments on draft-ietf-dime-erp-03.txt Glen Zorn
- Re: [Dime] Comments on draft-ietf-dime-erp-03.txt Sebastien Decugis