Hi all,

I agree with the PANA analysis as well. I think PANA fits the DSL Forum requirements quite cleanly. Additionally, the proposed alternative, i.e.; DHCP-based authentication would essentially be a remake of functionality that PANA already possess with the dis-advantage of having DHCP and authentication tightly coupled. So, it just common sense to consider PANA as an alternative. The claim that DHCP solution is less intrusive does'nt make sense to me either, since your going to have to modify the DHCP client and server implementation regardless. This is probably more disruptive than just adding another protocol on top of an existing IP stack; i.e. PANA. I maybe stating the obvious but it certainly is better from an architecture stand point not to create a monolithic do it all protocol from DHCP.

regards,
Victor Fajardo

Hi all,

 I second lionel. PANA fulfills DSL Forum requirements and should be
considered as a serious candidate.

 Regards,

 Julien Bournelle

On Dec 7, 2007 7:54 PM, MORAND Lionel RD-CORE-ISS
<[EMAIL PROTECTED]> wrote:
The list of requirements is the only material available from the DSL Forum and 
we should stay focus on!

Actually I refer to a previous mail that I sent on this topic on the Intarea ML:
 (snip)

"Now, one "could" say that the PANA protocol specification is "quite"
stable as a Proposed Standard RFC is available ;) Therefore, the question is 
quite simple: why do not simply reconsider the use of PANA in DSL environment? 
The proposed alternative, i.e. DHCP-based authentication, that is for the 
moment only an individual submission at IETF, will have anyway impacts on the 
DHCP client, the DHCP server and DSL network node behaviours if the goal is to 
have EAP in DHCP. And the proposed alternative do not explain why the current 
possible solution(s) don't fulfil the DSL Forum requirements... And I'm not 
sure that there is a direct link between the existing use of the DHCP option 82 
in DSL network leads seamlessly to DHCP-EAP...

At least, a pragmatic approach within IETF would be to see how PANA can fulfill DSL forum 
security requirements, see if there is some functionality gaps, see if this gap could be 
fulfilled with within PANA or with possible add-on solutions and if not, see other 
alternatives should be investigated. Only because IETF has already defined "the 
Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport 
for Extensible Authentication Protocol (EAP) to enable network access authentication 
between clients and access networks."

I support the actual ongoing work in the PANA WG to clarify the fact that PANA, 
as a candidate protocol, is fulfilling DSL requirements. It is not said that 
PANA is the ultimate solution for DSL networks. It is just said that the PANA 
protocol should be considered as serious candidate protocol.

And I agree with the current content of the slides.

Lionel


-----Message d'origine-----
De : Yoshihiro Ohba [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 7 décembre 2007 19:38
À : [email protected]
Cc : Mark Townsley (townsley); Jari Arkko
Objet : Re: [Pana] RE: DSLF Requirement analysis
I have a feeling that the two things are mixed in the
discussion : (i) whether a requirement is satisfied, and (ii)
how complex a solution would be to satisfy the requirement.
I suggest we focus on (i).  I have a problem with discussing
(ii) here, because it tends to be based on additional
unwritten requirements such as "number of states" and
"troubleshoot" and I cannot agree on arguments based on
unwritten requirements.

Yoshihiro Ohba



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

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


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



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

Reply via email to