> > Yes, that individual I-D is productized as a proprietary protocol by one
> > company (Cisco).
>
> As I understand it, EAP over UDP is one of the items proposed for
> standardization in the NEA WG.
You misunderstood it, despite the clear text in their charter:
...
Requirements need to
be defined for an EAP over L3 transport for L3 access scenarios.
...
* Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG)
and work with ADs to identify the WG responsible for accommodating
protocol requirements that are not currently being met.
> That leads me to wonder whether the IETF
> will be chartering multiple WGs to standardize EAP encapsulation over IP.
>
> Although my understanding of both PANA and NEA is no doubt
> incomplete/wrong/confusled, having multiple EAP encapsulation standards
> seems duplicative to me.
It is not suggested anyways.
> > 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).
>
> The issue is that integration of PANA with link layer technologies
> requires the support of the organizations that own those link layers.
Not necessarily. Why do you think so? 802.11 is a counter example. DSL is a
counter example.
> Without that link layer integration (for whatever reason) the scenarios
> can't be realized, at least in a mainstream way.
>
> It seems to me that one of the motivations for PANA is to *avoid* link
> layer
> dependencies in situations where link layer technology is inadequate/can't
> be deployed, and a forklift upgrade isn't in the budget. In those
> circumstances, integration with link layers or IPsec VPN technology is
> not under consideration -- because that would require a forklift upgrade.
>
> For example, the wireless hotspot case where something more sophisticated
> than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN
> deployment isn't a realistic alternative. Or the shared wired media case
> where "network port authentication" doesn't really work, and wholesale
> switch port replacements aren't affordable. In both of those cases, EAP
> over IP might provide a light weight, easily deployed solution.
Are you referring to NACP as "EAP over IP"? You acknowledged it is designed
for wired networks. It is not even useful for wireless. Won't work.
> Yet, rather than focusing on the specific scenarios in which PANA might
> be compelling, the PANA framework document tries to cover a wide
> range of potential uses, trying to position PANA for use in scenarios
> where the case is less obvious.
I think that would have been unnecessarily limiting, given that we designed
a protocol that can naturally work in variety of scenarios.
Alper
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf