Re: [HOKEY] REMINDER: WGLC on draft-ietf-hokey-erp-aak-04

Richard, thank you for the comments.

See inline for the response.  We will update the draft to reflect some
of your comments. Thank you again.

2011/8/15 Qin Wu <bill.wu@huawei.com>om>:
> Please find below a review from Richard about draft-ietf-hokey-erp-aak-04.
> I forwarded this eMail to the Hokey list. If you reply, please maintain
> Richard' eMail address in the recipients list.
>
> Regards!
> -Qin

>
> Hi, All:
>
> I have read it and have the following comments.
> 1)  The document also specifies a method by which the SAP may send the
>   identities of neighboring attachment points to the peer in the EAP-
>   Initiate/Re-auth-Start message.
> [Richard]
> The are two kinds of CAP discovery model：The CAPs could be found by SAP or
> by MH.
> Why not specify both cases?

I think the case of CAP discovery via MH is out of scope of this document.

>
> 2) The peer sends an early-authentication request message (EAP-Initiate/
>   Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS-
>   Identifier, rIK and sequence number.
> [Richard]
> The question is similar to the first one. It seemed that the text suggests
> the CAP list must be offered by the SAP.
> In the real application , It is possible that: The CAP list offered by the
> SAP is a reference or Mandatory.
> Also, MH could have a CAP list by itself and may refer or use the CAP list
> provided by the SAP.
> I suggest the draft would consider such cases and give some descriptions.

Same as the first question, I think we should keep it simple. And to
support you case, the SAP can leave the list blank and depends on the
EAP-Initiate/Re-auth packet to include the discovered CAP.

>
> 3)  This document only discusses the case of distributing the key to a
> single CAP.
> [Richard] it would let the draft only supports very limited scenarios. In
> some cases like unstable Wireless signal, the MH have to rapidly
> Shift among several CAPs. In order to ensure the user experience, it is
> possible that AAK is installed on the several
> CAPs before the MH's hand over.

We are designing a protocol to support the basic needs, and with good
extensibility .  In the previous versions of this draft, we have
indeed discussed the case of multiple CAP, but the working group
consensus is to have only one CAP in the scope. That's why we are
here.

>
> 4) The realm in the keyName-NAI field is used to locate the peer's ERP/AAK
> server
> [Richard] what would happen if the SAP does not know the ERP/AAK server
> indicated by the keyName-NAI

Inter-realm handover is not in scope.

>
> Regards
> Richard
>
> -----邮件原件-----
> 发件人: hokey-bounces@ietf.org [mailto:hokey-bounces@ietf.org] 代表 Glen
> Zorn
> 发送时间: 2011年8月4日 19:31
> 收件人: hokey@ietf.org
> 主题: [HOKEY] REMINDER: WGLC on draft-ietf-hokey-erp-aak-04
>
> At the hokey WG session during IETF 81 last week, the beginning of a three
> week Working Group Last Call for this document was announced.
> However, it appears that no-one mentioned this fact on the mailing list :-(,
> so the Last Call will be extended to 25 August.
>
> A URL for this document is
> http://www.ietf.org/id/draft-ietf-hokey-erp-aak-04.txt.  Please note that
> the draft is only 15 pages long, including boilerplate, so reading it should
> not be a major task.  Reply to this message with any comments (including
> statements such as "I read it and it's fine").  Thank you.
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
>

-- 
Best regards,
Zhen