Re: [HOKEY] Mail regarding draft-ietf-dime-erp
Glen Zorn <gwz@net-zen.net> Sun, 26 June 2011 07:19 UTC
Return-Path: <gwz@net-zen.net>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id 5A6F4228017 for <hokey@ietfa.amsl.com>;
Sun, 26 Jun 2011 00:19:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level:
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018,
BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V11br2Gf5LMB for
<hokey@ietfa.amsl.com>; Sun, 26 Jun 2011 00:19:18 -0700 (PDT)
Received: from p3plsmtpa01-03.prod.phx3.secureserver.net
(p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by ietfa.amsl.com
(Postfix) with SMTP id AB127228014 for <hokey@ietf.org>;
Sun, 26 Jun 2011 00:19:18 -0700 (PDT)
Received: (qmail 21565 invoked from network); 26 Jun 2011 07:19:18 -0000
Received: from unknown (124.120.80.190) by
p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP;
26 Jun 2011 07:19:17 -0000
Message-ID: <4E06DD6F.7020701@net-zen.net>
Date: Sun, 26 Jun 2011 14:19:11 +0700
From: Glen Zorn <gwz@net-zen.net>
Organization: Network Zen
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Qin Wu <sunseawq@huawei.com>
References: <CA299E1F.B359%jouni.korhonen@nsn.com>
<BBCCBAD8771C48E0950227790B2C0717@china.huawei.com>
In-Reply-To: <BBCCBAD8771C48E0950227790B2C0717@china.huawei.com>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/mixed; boundary="------------000000040801050203060105"
Cc: Jouni Korhonen <jouni.korhonen@nsn.com>,
"hokey-chairs@tools.ietf.org" <hokey-chairs@tools.ietf.org>,
dime-chairs@tools.ietf.org, hokey@ietf.org, draft-ietf-dime-erp@tools.ietf.org
Subject: Re: [HOKEY] Mail regarding draft-ietf-dime-erp
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>,
<mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>,
<mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jun 2011 07:19:23 -0000
On 6/24/2011 9:03 AM, Qin Wu wrote: > Hi, > I think the draft is almost stable besides we have two open issues that need to be fixed. > One issue is about authorization and how to do the session management. I have summarized some results > about what we discussed in the DIME and Hokey WG in the past and will put them into the new version > of Hokey Architecture document. > > The second issue is about Shall Hokey WG should cover the case where home realm contains > more than one EAP server. I believe none of existing works in the hokey WG cover this case. My opinion is the peer or user only need to talk > to one EAP serve during full EAP exchange. OK, but It's not clear to me what that has to do with ERP. Doesn't it rely upon a key derived from a _previous_ EAP authentication for re-authentication? > Even there is several EAP servers, the user should only choose > one EAP server in the home realm. How to do this is decided by Diameter Routing mechanism rather than rely on Hokey WG come up some new mechanisms to fix this. I don't believe that ERP messages contain any data that is useful for the kind of intra-realm routing we're discussing. > > So I think we should leave this out of scope of draft-ietf-dime-erp. Maybe so, but the problem should be at least discussed, if not solved. > Also draft-ietf-dime-erp should not rely on the Hokey Progress. I have repeated this in the last meeting several times. That's something that I don't really understand. How can you write a Diameter application for an architecture that is not well-understood? > > Therefore I think we should move this forward with the first open issue fixed. There is no reason to let this work get > stuck there and we wait for nothing from Hokey WG. It seems that there is even less reason to publish an RFC that is incorrect or incomplete just to satisfy some desire to make "progress" (which seems only to arise in this WG every 4 months or so). ...