Re: [pcp] Comparison of PCP authentication

[Alper Yegin <[e-mail]>]

Hi Yoshi,

>>> 
>>> If we specify a new use of PANA "Reserved" field, it cannot be an
>>> Errata because it is not a specification error.  It needs to be a new
>>> RFC that updates RFC 5191.
>> 
>> 
>> Those bits are reserved for "future."
>> And because of this demux design, "now" we want to make sure no one will ever set bit#7.
> 
> I think "no one will ever set bit#7" is too much restricted.
> 
> Because of in-band key management, a bit in the PANA "Reserved" field
> to be used for demultiplexing "over PCP port" can be meaningful only
> when PANA message is carried "over the PCP port".   The bit could also
> be used for demultiplexing other application carried over another port
> if the other application allows to use the bit for demultiplexing
> purpose as well.


We can either say:

Bit#7 is reserved for use with PCP. (And it's always set to 0).

Or,

When used over PCP port, Bit#7 is always set to 0.
When used over other ports, its reserved for future use (as it currently is).


Latter one is more conservative about bit usage, but a bit more cumbersome. Not sure which way to go.


> 
> From PANA perspective, we can now allocate the whole 16-bit "Reserved"
> PANA field for "in-band key management usage", and let each
> application including PCP define how to demultiplex using the 16-bit.
> I think this is a cleaner and extensible approach.
> 

We may not want to give up on the 16-bit space for encoding one type of usage (in-band). Let's think about this…..

Alper




> Yoshihiro Ohba
> 
> 
>> What we need is to allocate that bit and state it's always set to 0. I don't think we need a separate RFC for this, this'd be the RFC that defines how PANA and PCP are used together.
>> 
>> Alper
>> 
>> 
>> 
>> 
>> 
>