Re: [pcp] EAP-over-PCP

[Margaret Wasserman <[e-mail]>]

On Sep 18, 2012, at 4:40 AM, Alper Yegin wrote:
> 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

Um, the latest doc describes two solutions, one of which _is_ PANA (encapsulated in PCP), so it would seem a bit strange to claim the ideas were "adapted from" PANA...

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

Both mechanisms described in the current draft are encapsulation mechanisms, and I was under the impression that you were arguing that a demultiplexing (side-by-side) mechanism was substantially preferable...  Am I missing something?

The PCP-Specific mechanism is very similar to an encapsulated PANA mechanism with certain specific differences:

- It is a simplified protocol, because it doesn't need to handle things like address reallocation that are specific to the Network Access case.
- It is fully integrated with the PCP header, so there are no overlapping fields that need to be check for consistency, etc.

So, if we re-titled our initial PCP-Specific proposal to be called "Simplified PANA Authentication for PCP", would that resolve all of your concerns?

I don't have a strong personal preference between these two approaches, because they aren't very different.  If we do end-up defining an encapsulated PANA mechanism, our draft will need to describe what subset of PANA needs to be implemented/supported for use with PCP, and it will need to explain how to consistency-check the PANA packet against fields in the PCP header.  So, we'll end up with a protocol that uses (a subset of) PANA and requires a bit more run-time processing and a few more error cases than a PCP-Specific solution (for the consistency checking), but one that is otherwise very similar.

As I have said over and over, all of these solutions have far more in common (conceptually, functionally and even in the bits they will send on the wire) than their differences.

Margaret