[Pana] Fwd: Re: I-D Action: draft-yegin-pana-unspecified-addr-05.txt

Forgot to include pana mailing list..

-------- Original Message --------
Subject: Re: [Pana] I-D Action: draft-yegin-pana-unspecified-addr-05.txt
Date: Mon, 13 Feb 2012 17:52:36 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
To: Alper Yegin <alper.yegin@yegin.org>

(2012/02/09 18:11), Alper Yegin wrote:

(snip)

>> ---------------------------------------------------------------------
>>
>> (3) Page 6, Paragraph 3
>>
>> I have no idea which PAR should have 'I' bit. Every PAR sent by
>> PAA should have 'I' bit? Or, only a PAR with 'C' bit should have
>> 'I' bit? (I think the latter is preferable.)
>>
>> I've referred to RFC 5191, but I've not found the answer.
>>
> 
> I think this is an ambiguity with the RFC 5191. PAR with 'C' bit makes sense.
> 

I have been interpreting the original text as setting 'I' bit for all
PAR messages sent by the PAA in the authentication and authorization
phase and clearing the bit for subsequent PAR messages.  With this
behavior, the PAA can set the 'I' bit from the very first PAR message
and the PaC can immediately stop PANA authentication if the PaC does
not expect IP address update.  I think we need a bit more discussion
on this.

Yoshihiro Ohba

> 
>> [original]
>>   The PAA SHALL set the 'I' (IP Reconfiguration) bit of PAR messages
>>   in authentication and authorization phase so that the PaC proceeds
>>   to IP address configuration.
>>
>> ---------------------------------------------------------------------
>>
>> (4) Page 6, Paragraph 7
>> I don't think that the description about the size of the largest PANA
>> is correct. This is because the initial PAR could have multiple
>> Integrity-Algorithm AVPs and PRF-Algorithm AVPs. This specification is
>> described in Section 4.1, RFC 5191.
>>
>> [Section 4.1. in RFC 5191]
>>    the PAA sends the initial PANA-Auth-Request carrying one or more
>>    PRF-Algorithm AVPs and one or more Integrity-Algorithm AVPs for the
>>    PRF and integrity algorithms supported by it, respectively.
>>
>> In my understanding, it is sufficient to consider a PANA Message which
>> has only one EAP-Payload AVP for "Message Size Considerations". In
>> other words, the minimum PANA MTU size is equivalent to the size of a
>> PANA message which has only one EAP-Payload AVP.
>>
> 
> 
> We are trying to find the the size of the largest PANA message.
> The largest PANA message is possibly not the very first PAR from the PAA (unlike the current draft states).
> Such a PAR can be carrying a EAP-Request/Identity, hence not really be caring a minimum EAP MTU size.
> A subsequent PAR can be carrying that (and it'd not have the Integrity-Algorithm, PRF-Algorithm, and Token AVPs).
> 
> Are you using the same reasoning for your above suggestion?
> 
> Alper
> 
> 
> 
>> ---------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Pana mailing list
>> Pana@ietf.org
>> https://www.ietf.org/mailman/listinfo/pana
> 
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www.ietf.org/mailman/listinfo/pana
> 