Just below you are acknowledging the need for EAP over IP. I don't
understand how you can still claim you don't understand why PANA is
useful...
The framework doesn't seem to talk much about simple EAP over IP
scenarios, so I have assumed this is not the major focus.
I am sure you read RFC 4058 (like anyone who claims they don't understand
PANA should have done). RFC 4058 said:
PANA will carry EAP above IP in order to enable any authentication
method on any link-layer.
You are aware that "virtual open-access AP" mode is OK. One of the
two alternatives we proposed had an issue, and the other one still
holds.
Right. I was referring only to the WPA/WPA2 scenarios.
Your earlier statement did give another impression, like PANA does not work
with 802.11i at all. Thanks for clarifying it now!
De-facto? Could you please elaborate how it is becoming a de-facto
standard?
EAP over UDP is one of the foundation technologies for Network Endpoint
Assessment (NEA). As I understand it, EAPoUDP is being made available on
most operating systems, and is in the process of being deployed by many
enterprise customers.
Yes, that individual I-D is productized as a proprietary protocol by one
company (Cisco). Client-side software may be made available by them for
various platforms (note PANA is already made available as an open source
--both client and software side). If Cisco develops a proprietary protocol
on its own for a subset of our work, should we now stop what we do at IETF?
Is that where this whole fuss is coming from now?
Besides. Of course PANA is more complex than EAPoUDP. The latter (an
individual I-D) has very limited applicability.
As I understand it, EAP over UDP is mostly being deployed for wired access
scenarios where IEEE 802.1X might not work well (e.g. multiple hosts
sharing a port).
Which SDOs? Please give us more detail.
As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has
evaluated the PANA framework document.
How does this explain your "rejected by the SDOs" claim? IEEE 802.11
provided a review feedback and they fixed few important problems and
acknowledged the applicability of our other alternative solutions. How is
that a rejection?!?
As for 3GPP2, I can get into really gory details of what has been happening
there, but it's not technical at all (if you are familiar with 3GPP2 and the
relevant players in this discussion, you can guess).
Alper
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf