[pcp] EAP-over-PCP

[Sam Hartman <[e-mail]>]

Hi, Alper.
Thanks for your review.
We're glad that we were able in your eyes to successfully re-use a lot
of the work that went into PANA design.
We really appreciated being able to look at previous lower-layer work
including PANA and draft-ietf-abfab-gss-eap to make our job easier.


If the WG believes terminology realignment would be beneficial here,
then we can work towards that goal.

I'd appreciate comments from PCP implementors on the state machine
integration issue that Alper brings up.

Depending on what's easy for PCP implementations we have a number of
options.

In RFC 3748  the conversation is conceptually server driven.
However, there is typically a client (lower layer) indication to get
things started.

However, the only reason that the conversation is server-driven iss
retransmissions. If you take a look at section 2 of RFC 3748 you note
that the protocol is lockstep. The server cannot send a new request
until the client has responded to the previous one.  If you take a look
at section 4.3, a lower layer may sent the retransmission timeout to
infinite. In this mode, the server will never generate an unsolicited
request.
So, it's entirely possible to  view things as a client-server protocol
with client-driven retransmissions if that makes things easier for PCP
implementations.

That's the approach we took in draft-ietf-abfab-gss-eap. That spec is an
approved EAP lower layer in the RFC editor queue. That spec treats EAP
as a simple lock-step client-server protocol. We lose a half round trip
because we ask the server to get started and it then asks us for our
identity. We came up with mechanisms for including our identity in the
first request, trimming a half round trip. The decision of that working
group was that the complexity was not worth it, but that optimization is
available if it helps with PCP.

so, feedback from people with PCP state machines would be really helpful
about which of these issues matter to you.