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

The behavior I mentioned is stated in RFC 5191:

"
   I (IP Reconfiguration)

      If set, it indicates that the PaC is required to perform IP
      address reconfiguration after successful authentication and
      authorization phase to configure an IP address that is usable for
      exchanging data traffic across EP.  This bit is set by the PAA
      only for PANA-Auth-Request messages in the authentication and
      authorization phase.  For other messages, this bit MUST be
      cleared.
"

I think the right thing is to just refer to RFC 5191 for the behavior
iwth the 'I' bit set.

Yoshihiro Ohba

(2012/02/13 18:01), Yoshihiro Ohba wrote:
> 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
>>
> 
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www.ietf.org/mailman/listinfo/pana
> 