[HOKEY] Comments on draft-ietf-hokey-arch-design

Qin Wu <bill.wu@huawei.com> Mon, 11 July 2011 04:14 UTC

Date: Mon, 11 Jul 2011 04:13:43 +0000
From: Qin Wu <bill.wu@huawei.com>
To: "hokey@ietf.org" <hokey@ietf.org>
Message-id: <B8F9A780D330094D99AF023C5877DABA2BCA49@szxeml523-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Sh7WqN9yeM1Wp050n31nMw)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: Comments on draft-ietf-hokey-arch-design
Thread-index: Acw/gOwQmDYgpiiLTkuc+iTf896X4g==
Subject: [HOKEY] Comments on draft-ietf-hokey-arch-design
Precedence: list

Hi, Yoav:
Good comments. Please see my reply inline.
----- Original Message -----
From: Yoav Nir<mailto:ynir@checkpoint.com>
To: Qin Wu<mailto:bill.wu@huawei.com>
Sent: Sunday, July 10, 2011 6:36 PM
Subject: Re: Next step of draft-ietf-hokey-arch-design

Hi Qin.

Here are my other comments:

  *   The title of section 3.1.1 talks about minimizing communications with home servers. Then the body talks about the peer communicating with its own home server. I agree that this should be minimized, but I'm missing discussion of communications between the visited network and the home servers. I would guess that the local AAA servers communicating with the home AAA servers would introduce as much delay, no? Section 3.1.2 does address this in passing, but it's about LDN discovery, so I think the "implicit is preferable" sentence should move to 3.1.1.

       [Qin]: Yes, I realize there some overlapping between section 3.1.1 and section 3.1.2 and section 3.1.3 when we introduce new section 3.1.2 to discuss "minimized user interaction" You are right, commmunication between local server and home server also needs to be minimized. I will put some text to clarify this. As regarding moving "implicit preferable", If you read into section 3.1.3, you will find  they are focuing on local domain name integration,talking about the different thing.  in order to eleminate these overlapping, I would suggest to change the title of section 3.1.2 into "minimized  user interaction for authorization".

  *   Section 3.1.2 says " [RFC5296<http://tools.ietf.org/html/rfc5296>] does not specify such a domain name discovery mechanism and suggests that the peer may learn the domain name through the EAP- Initiate/Re-auth-Start message or via lower layer announcements. To allow more efficient handovers…" It doesn't say why this suggestion is not efficient. After all, it's data that's included in a field in a message that has to be sent anyway, no?

     [Qin]:Yes, it depends on whether you use these method described in RFC5296 in implicit bootstrapping or in the explicit bootstrapping.
     In the implicit bootstapping, local domain name discovery happens after the whole implicit bootstrapping completes while in the explicit boostrapping, the local domain  name discovery is part of explicit bootstapping and happen during the explicit boostraping, i.e., carry local domain name TLV in the EAP-Finish message. That is the difference. That is why we say we need to integrate local domain name into implicit bootstrapping. Hope it clarifies. But thanks, I will put some text to clarify this.

[HOKEY] Comments on draft-ietf-hokey-arch-design Qin Wu