Ric, > I strongly disagree. PANA is not suitable to DSLForum requirements.
Could you please be specific? > Other protocols in the IETF and IEEE are far better candidates. Taking > this work in the PANA WG is a totally wrong conclusion that somehow PANA > is the correct framework for solving a layer 2 authentication problem! Unfortunately since you are the one calling this a "layer 2 authentication problem", could you please explain what exactly you mean by that and how "DHCP" is solving that "L2 auth" problem, and how DSLF requirements "IPAuth-10 Must be independent of medium type (eg Fixed Ethernet, Legacy ATM, PON, WiFi, WiMax, etc)" plays into that? > Put you hammer back in the drawer, not every problem is a nail you need > to hit with it. That's a misconception I've been hearing from you, but in case you haven't noticed, this WG was created exactly for this problem space, even to the extent that we mentioned it in our RFC 4058 DSL networks are a specific example where PANA has the potential for addressing some of the deployment scenarios. Some DSL deployments do not use PPP [RFC1661] as the access link-layer (IP is carried over ATM and the subscriber device is either statically or DHCP- configured). The operators of these networks are left either using an application-layer web-based login (captive portal) scheme for subscriber authentication, or providing a best-effort service only as they cannot perform subscriber authentication required for the differentiated services. The captive portal scheme is a non-standard solution that has various limitations and security flaws. Alper _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
