Subject: [Pana] Re: [issue218] AD comments on Introduction

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 27 Jan 2006 18:58:47 -0500

On Sun, Jan 08, 2006 at 09:26:57AM +0000, Hannes Tschofenig PANA-Issues wrote:
> 
> Hannes Tschofenig <[email-masked]> added the comment:
> 
> >   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).
> 
> 
> [hannes] 
> 
> here is a suggestion for a new paragraph:
> 
> "
> The scope of this work is to design a link-layer agnostic
> transport for network access authentication methods. 
> Even though the transport is link-layer agnostic it might 
> still be necessary to interact with link layer mechanisms
> in certain scenarios, for example, when link-layer security 
> has to be enabled as a result of a successful network access 
> authentication protocol run. The Extensible Authentication 
> Protocol (EAP) [RFC3748] provides such authentication
> methods.  In other words, PANA carries 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.  
> "

The text looks good, as it mentions interaction with L2 
mechanisms when L2-sec is enabled.

> 
> 
> 
> >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.
> 
> 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.
> 
> 
> 
> [hannes] i suggest to delete the sentence. alternatively it might be possible 
> to elaborate on the 
> division of labor in more detail.

I think we should delete the sentence.  It is enough to refer to EAP
3748, EAP keying framework draft and PANA framework draft, and all
these documents are already referred to in this section.

Yoshihiro Ohba

> 
> ----------
> status: No Discussion -> Text Proposed
> ___________________________________________________
> PANA Issues <[email-masked]>
> <http://danforsberg.info:8080/pana-issues/issue218>
> ___________________________________________________
> 
> 

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