[pcp] PANA vs. EAP-o-PCP

[Alper Yegin <[e-mail]>]

Let me summarize why I think the WG should continue with its current selection of PANA.


+ PANA is an RFC that is already adopted by other SDOs (Zigbee Alliance, ETSI M2M, ATIS IPTV), with 2 open-source, and multiple interoperating production implementations.

+ PANA already serves the need with a minor update to PANA (allocation of 3 bits from Reserved ones), or no update at all if the WG agrees to allow its use on native PANA port.

+ The only extra PANA feature that is currently not needed for PCP is the IP Address Reconfiguration, which is a mere bit setting. So, the protocol is lean enough.


On the other hand:

- EAP-o-PCP is a half-cooked clone of PANA. There's no clear justification why it's needed when PANA is already available. It's a half-way re-invented wheel. Why not re-use? 

- EAP-o-PCP is an incomplete EAP lower-layer. It's not supporting re-authentication.

- The state machine and message flows of EAP-o-PCP are fundamentally different than PCP's. It's not PCP compatible. It's in fact another protocol that is burrowing PCP header and PCP port.  That's it. It's not going to simplify PCP, it's going to complicate PCP. 


This story is unfolding exactly like what we had with EAP-o-DHCP, even with the technical characteristics (state-machine mismatch, opposite message flows, continued desire to use one's own design instead of IETF's good-old "reuse" approach, etc.). At the end, it became such a big waste of time/effort for anyone.

Alper