Re: [HOKEY] Russ Housley's Discuss on draft-ietf-hokey-arch-design-10: (with DISCUSS)

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Thu, 29 December 2011 20:19 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
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 99F3721F8BA0; Thu, 29 Dec 2011 12:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.738
X-Spam-Level:
X-Spam-Status: No, score=-6.738 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut6VNRijGgTF; Thu, 29 Dec 2011 12:19:01 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E4FF621F8B9E; Thu, 29 Dec 2011 12:19:00 -0800 (PST)
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 <0LWZ00HPRF3BEM@szxga03-in.huawei.com>; Fri, 30 Dec 2011 04:18:47 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWZ0064ZF3BUU@szxga03-in.huawei.com>; Fri, 30 Dec 2011 04:18:47 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGC38256; Fri, 30 Dec 2011 04:18:43 +0800
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Dec 2011 04:18:38 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Fri, 30 Dec 2011 04:18:33 +0800
Date: Thu, 29 Dec 2011 20:18:32 +0000
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
In-reply-to: <4EFC3897.2000004@gmail.com>
To: Glen Zorn <glenzorn@gmail.com>
Message-id: <5D2C30AD-F2D9-4971-9A12-64E92DCD1929@huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: Russ Housley's Discuss on draft-ietf-hokey-arch-design-10: (with DISCUSS)
Thread-index: AQHMxg/DH+X9yP2BSUmpqF8ZPgAx2JXzQfJz
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <4EFC3897.2000004@gmail.com>
Cc: "rbarnes@bbn.com" <rbarnes@bbn.com>, Russ Housley <housley@vigilsec.com>, The IESG <iesg@ietf.org>, "hokey@ietf.org" <hokey@ietf.org>, "draft-ietf-hokey-arch-design@tools.ietf.org" <draft-ietf-hokey-arch-design@tools.ietf.org>
Subject: Re: [HOKEY] Russ Housley's Discuss on draft-ietf-hokey-arch-design-10: (with DISCUSS)
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: Thu, 29 Dec 2011 20:19:01 -0000

Authors, the gen-art review from Richard Barnes seems reasonable.
You may consider to update a new version.

Tina as document shepherd,
Sent from my iPad

On Dec 29, 2011, at 4:53 AM, "Glen Zorn" <glenzorn@gmail.com> wrote:

> Sorry for the delayed reply; I have been ill.  In any case, the gen-art
> review is reproduced below, with comments.
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>gt;.
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
>> Document:  draft-ietf-hokey-arch-design-03
>> Reviewer:  Richard Barnes
>> Review Date: 2011-11-23
>> IETF LC End Date:
>> IESG Telechat date: 2011-12-01
>> 
>> Summary:  Largely complete, but hard to use
>> 
>> Major issues:
>> 
>> The document seems to make several architectural assumptions that are
>> not clearly stated.  For example, both this document and the HOKEY
>> problem statement [RFC5169] make reference to "home" and "visited"
>> networks, terms which are defined in neither document.  It would be
>> helpful if this document could clarify some of these issues that are 
>> left vague by the problem statement.
> 
> The terms "home network" and "visited network" have been in common usage
> in the roaming community for at least 10 years.
> 
>> 
>> Likewise, the document states the architecture in terms of several "
>> functions" that are performed by "components".  For a reader
>> unfamiliar with the history of this document, it is not clear how
>> these functions work together to solve the problems laid out in RFC
>> 5169.
> 
> Since this document attempts to describe the entire hokey architecture
> of which re authentication and key management (the subjects of RFC 5169)
> are only portions (the other major component being early authentication,
> discussed in RFC 5836), I don't think that it is particularly surprising
> that there is not a one-to-one mapping.  That said, however, I find this
> comment quite amorphous, bordering upon "I don't understand", and not
> very useful.  Some specific, actionable suggestions would be much
> appreciated; note that 'add an (unspecified) reference" is not part of
> that set.
> 
>> 
>> The components are also given suggestive names, but not defined.  For
>> example, there are components named "serving authenticator" and
>> "candidate authenticator", whose names seem to imply that they play
>> particular roles in the protocol or occupy particular places in the
>> network.  But the document never explains this beyond the names.
> 
> "Candidate Authenticator" is defined in Section 2 of RFC 5836 (see
> below), which is referenced in Section 2 of the document under
> discussion.  I can add the following definition to Section 2 of the
> draft if necessary:
> 
>   Serving Authenticator (SA)
>      The EAP authenticator on the SAP [RFC5826].
> 
> 
> 
> Minor issues:
> 
> 
> Editorial nits:
> 
> Version -10 appears to have introduced the term "DSrRK", which appears
> nowhere else in the document.
> 
> "DSrRK" appears in Tables 4 and 5.