Re: [pcp] EAP-over-PCP

[Alper Yegin <[e-mail]>]

Margaret,

>> 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...
> 

The above statement, which existed in the previous version of the doc, is referring to EAP-over-PCP design. It's that design that's adopted from PANA, and that's still in the document.


>> 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?
> 

Yes, that's what I'm arguing.


> 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.

Address reallocation as supported by PANA base spec is nothing more than the PAA conveying a configuration parameter using a single bit. 
If that bit is not needed for PCP, then we just say it's not used for PCP. 


> - It is fully integrated with the PCP header, so there are no overlapping fields that need to be check for consistency, etc.
> 

Yes, using the PCP header. But that's all when it comes to "integration into PCP" (plus the common terminology, which is editorial). Otherwise, pcp-auth is a totally different protocol with its new messages, flow, state machine.

PANA-based solution is allocating three bits out of its reserved bits for PCP use for the sake using operating on the same port.
(Honestly, I don't know why PANA and PCP must operate on the same port. If someone can explain, I'd appreciate. Is it for saving ports? For firewall traversal? For some misconception about "binding"? At any rate, current solution is trivial, but I'm curious why people chose the "same port".)



> 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?
> 

My point is, 
- EAP-over-PCP design is not fundamentally PCP-based (using the same terminology and header, but anything else is different -- more essential things like the messages, flows, state machine). So, it's a cosmetic similarity.
- in it's essence, it's PANA. 
- So, why re-invent the wheel.

If you can identify the parts of PANA that appears to be extra, we can discuss if they are really not needed, and how we can go about not using them.
So far, this "IP address reconfig" is mentioned and it's a trivial feature that's easy not to use.   


> 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.  

We already described the use of those now-assigned three bits in the I-D.


> 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.
> 

Because EAP-over-PCP is re-invented PANA. Not in the vacuum, but specifically importing the design from PANA. As much as we are humbled about this, we are still wondering why not use PANA instead of creating a cosmetically-changed clone.


Alper



> Margaret
>