Re: [pcp] EAP-over-PCP

["Zhangdacheng (Dacheng)" <[e-mail]>]

Hi, Alper:

I am not surprised that you have  that feeling. If you could check the discussion during the IETF 83 in Paris, we have clarified the PCP based authentication mechanism adopted the idea of PANA (but only the useful part). Also, in that meeting, people started discussing whether we need an integrated or an separated authentication mechanism. I think the most important problem we are discussing now is whether we need to use PCP or PANA to transport EAP, right?

Please refer to the following link for more information: http://www.ietf.org/mail-archive/web/pcp/current/msg01930.html

From: [e-mail] [mailto:[e-mail]] On Behalf Of Alper Yegin
Sent: Tuesday, September 18, 2012 4:41 PM
To: Sam Hartman
Cc: '[e-mail]'
Subject: [pcp] EAP-over-PCP

I went back to reading your draft again.

I gotta tell you, it felt like reading PANA!
Most of the design is direct adaptation of PANA design.
Earlier version of the I-D had softly acknowledged that:


   Some of the ideas in this document were adopted from PANA[RFC5191].

Interestingly, this statement disappeared in the latest doc.
"Some" is a major understatement btw.

The most striking difference between PANA and your design is in the terminology, and making it (look like) part of PCP.

But actually, on that last note, this does not look like PCP at all either.

PCP is a host-driven req/rsp protocol, plus server-side one-way notifications. That dictates its state machine.

Your design includes:
- client side one way message (PCC-Initiation)
- server-driven req/rsp
- one-way acks (PA-Ack) from client, wedged into req/rsp sequence

This is so different than PCP. Forcing the base PCP protocol to have a state machine to support both its native needs and this new "extension" is not trivial.

If you folks revert the terminology back to PANA's, we can be done :-)

Alper