Subject: [Pana] Issue 218: AD comments on Introduction

From: "Alper Yegin" <[email-masked]>
Date: Tue, 17 Jan 2006 19:04:22 +0200

http://danforsberg.info:8080/pana-issues/issue218

>   Scope of this work is identified as designing a link-layer agnostic
>   transport for network access authentication methods.  The Extensible
>   Authentication Protocol (EAP) [RFC3748] provides such authentication
>   methods.  In other words, PANA will carry EAP which can carry
various
>   authentication methods.  By the virtue of enabling transport of EAP
>   above IP, any authentication method that can be carried as an EAP
>   method is made available to PANA and hence to any link-layer
>   technology.  
> 
 
This is not entirely true. EAP may be *transported* over any link-layer 
for which IP is defined via PANA, however, there are still a number of 
linkages between EAP and the link-layer (reaching around the "PANA 
layer"). Some are referred to later in this document (A MAC Address 
Device ID, PANA session lifetime triggered by the lower layer, etc).

Alper> There is no part of the PANA that makes it specific to any link-layer
technology. In other words, PANA specification does not have to change in
order to run on a given L2 technology. The MAC Address Device ID does not
change this situation either (we followed the lead of the IPv6 ND RFC2461 in
order to carry any L2 address type without having to enumerate them in our
spec). Session termination triggered by a L2 termination action is an
informative part of the spec. We can easily remove that if necessary.
Anyways, that text is not specific to any L2 technology either. 

.

>There is a clear division of labor between PANA (an EAP
>   lower layer), EAP and EAP methods as described in [RFC3748].
>  
> 
This is not true either, Section 5.10 on Network Selection is a clear 
case where the line between EAP and PANA is muddy indeed.
 
Alper> Earlier e-mails had clarified that doing network discovery and
selection within the EAP lower layer is a more appropriate approach than
doing that within the EAP or EAP methods.  
 
Let's be a bit more honest in the Introduction. PANA offers a common 
transport for EAP over various link-layers, but it does not shield the 
link-layer from defining a number of things in order to work with
PANA/EAP.

Alper> I don't see what the L2 needs to do to carry PANA, as this is just an
IP-based protocol.

Alper

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana