Subject: Re: [HOKEY] Change proposal for ERP-AAK - 1: NAS-Identifier Redefining

From: Glen Zorn <[email-masked]>
Date: Wed, 05 Oct 2011 19:03:59 +0700

On 9/29/2011 4:20 PM, Qin Wu wrote:

> Hi,
> As we discussed on the list to draft-ietf-hokey-erp-aak, NAS Identifier
> defined in the section 5.32 of RFC2865
> is not appropriate to be used in the inter-realm hanover case. Since
> CAP(s) and/or SAP are not global identifier
> and the value they are choosing may conflict with each other, therefore
> I propose to redefine NAS-Identifier,
> in other words, abandon using NAS-Identifer in the
> draft-ietf-hokey-erp-aak-05, instead, replace it with CAP-Identifier
> as belows:
>  
> "
> 
>    CAP-Identifier: This is carried in a TLV
> 
>    payload. The type is TBD. This attribute contains a string
> identifying the Candidate Access Points prior to the
> 
>    arrival of the MH at the Candidate Access Network (CAN).It is used by
> the SAP to advertise the identifier(s) of
> 
>    CAP(s) to the peer and EA server.
> 
> "

OK, but this needs a format specification (FQDN might be good).

>  
> Regards!
> -Qin
> 
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey

---

From: Qin Wu <[email-masked]>
Date: Sat, 08 Oct 2011 12:07:11 +0800

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 05, 2011 8:03 PM
Subject: Re: [HOKEY] Change proposal for ERP-AAK - 1: NAS-Identifier Redefining

> OK, but this needs a format specification (FQDN might be good).

[Qin]: Agree.

---

From: Zhen Cao <[email-masked]>
Date: Sun, 9 Oct 2011 10:39:29 +0800

I think  we should be careful adding more semantics to the current
tools, otherwise it takes longer to converge.

How about re-use the NAS-Id and in the string part, make it a
FQDN-alike way, then that depends on the implementation only.

-- 
Best regards,
Zhen

---

From: Zhen Cao <[email-masked]>
Date: Tue, 11 Oct 2011 13:30:49 +0800

CAS-Identity would be a new concept and need Type for the TLV, and it
may be not general enough.  I am afraid IETF would be conservative to
agree with this, given we have way to circumvent.

On Tue, Oct 11, 2011 at 1:24 PM, Glen Zorn <[email-masked]> wrote:
> On 10/9/2011 9:39 AM, Zhen Cao wrote:
>
> Sorry, I don't understand.
>
>>

-- 
Best regards,
Zhen

---

From: Glen Zorn <[email-masked]>
Date: Tue, 11 Oct 2011 12:24:58 +0700

---

From: Qin Wu <[email-masked]>
Date: Wed, 12 Oct 2011 14:29:01 +0800

This is not a problem.
Since NAI-Identifier defined in RFC2865 is not general either and only used in 
 Access-Request packet to the RADIUS Server, however in our use case,
we need a TLV for SAP to carry CAP lists to the server that may be in another 
domain which is quite different from original usage of NAI-Identifier specified in RFC2865.
Therefore it worth having a new TLV to fix this issue.

Regards!
-Qin

---

From: Zhen Cao <[email-masked]>
Date: Fri, 14 Oct 2011 22:11:15 +0800

understand now. From this respect, the new TLV is indeed needed.

Thank you for the clarification.

-- 
Best regards,
Zhen