Subject: Re: [Pana] Network selection section, 5.10

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Oct 2006 17:26:23 +0300

I generally agree with what you say below.
You could also remove the RFC 4284 reference,
I think. It might be useful to talk about the
general topic of how the different EAP lower
layer and EAP layer mechanisms interact, but
perhaps that is for other documents. And it
certainly can create more confusion than
needed.

Note that there should not be any direct relationship
between PANA selection and 4284; what you decide
to supply as the ISP name in the PANA protocol is
one decision, and then whatever you run inside EAP
(methods, NAIs, 4284 etc) should be completely
independent of that.

--Jari

Yoshihiro Ohba wrote:
> On Wed, Sep 27, 2006 at 11:37:54AM +0200, Mark Townsley wrote:
>   
>> I have read this paragraph again and again, and I still have a hard time 
>> making sense of it:
>>     
>>>   A PANA-Start-Request message sent from the PAA MAY contain zero or
>>>   one NAP-Information AVP, and zero or more ISP-Information AVPs.  The
>>>   PaC MAY indicate its choice of ISP by including an ISP-Information
>>>   AVP in the PANA-Start-Answer message.  The PaC MAY convey its ISP
>>>   even when there is no ISP-Information AVP contained in the PANA-
>>>   Start-Request message.  The PaC can do that when it is pre-configured
>>>   with ISP information.
>>>       
>> I read this as saying that the PaC may send ISP selection information, 
>> or it may not, it doesn't really matter. This is really terrible 
>> guidance for an implementor, I wouldn't have a clue what to do with this 
>> if I were trying to write a PANA implementation.
>>     
>
> The meaning of the paragraph in terms of ISP selection is:
>
> - The PaC may choose an ISP based on the information provided by PAA (using 
> one or more ISP-Information AVPs in PSR) or pre-configured on the PaC.
>
> - When the PaC chooses an ISP, then the choice is made based on
> carrying one ISP-Information AVP in PSA.
>
>   
>> MAY "convey" doesn't mean anything to an implementor. Normative language 
>> should be used when you are talking about protocol constructs, not 
>> abstract actions.
>>     
>
> I agree.  HowFrom [email-masked] Tue Oct 03 10:27:20 2006
Date: Tue, 03 Oct 2006 17:26:23 +0300
From: Jari Arkko <[email-masked]>
To: Yoshihiro Ohba <[email-masked]>
Subject: Re: [Pana] Network selection section, 5.10
Cc: Mark Townsley <[email-masked]>, [email-masked]

I generally agree with what you say below.
You could also remove the RFC 4284 reference,
I think. It might be useful to talk about the
general topic of how the different EAP lower
layer and EAP layer mechanisms interact, but
perhaps that is for other documents. And it
certainly can create more confusion than
needed.

Note that there should not be any direct relationship
between PANA selection and 4284; what you decide
to supply as the ISP name in the PANA protocol is
one decision, and then whatever you run inside EAP
(methods, NAIs, 4284 etc) should be completely
independent of that.

--Jari

Yoshihiro Ohba wrote:
> On Wed, Sep 27, 2006 at 11:37:54AM +0200, Mark Townsley wrote:
>   
>> I have read this paragraph again and again, and I still have a hard time 
>> making sense of it:
>>     
>>>   A PANA-Start-Request message sent from the PAA MAY contain zero or
>>>   one NAP-Information AVP, and zero or more ISP-Information AVPs.  The
>>>   PaC MAY indicate its choice of ISP by including an ISP-Information
>>>   AVP in the PANA-Start-Answer message.  The PaC MAY convey its ISP
>>>   even when there is no ISP-Information AVP contained in the PANA-
>>>   Start-Request message.  The PaC can do that when it is pre-configured
>>>   with ISP information.
>>>       
>> I read this as saying that the PaC may send ISP selection information, 
>> or it may not, it doesn't really matter. This is really terrible 
>> guidance for an implementor, I wouldn't have a clue what to do with this 
>> if I were trying to write a PANA implementation.
>>     
>
> The meaning of the paragraph in terms of ISP selection is:
>
> - The PaC may choose an ISP based on the information provided by PAA (using 
> one or more ISP-Information AVPs in PSR) or pre-configured on the PaC.
>
> - When the PaC chooses an ISP, then the choice is made based on
> carrying one ISP-Information AVP in PSA.
>
>   
>> MAY "convey" doesn't mean anything to an implementor. Normative language 
>> should be used when you are talking about protocol constructs, not 
>> abstract actions.
>>     
>
> I agree.  How about revising the last two sentences of the paragraph 
> something like:
>
> When the PaC is pre-configured with ISP information, it may choose an
> ISP even when there is no ISP-Information AVP contained in the
> PANA-Start-Request message.  In this case, the choice is communicated
> to the PAA by containing an ISP-Information AVP in the
> PANA-Start-Answer message.
>
>   
>> The next paragraph helps a little in trying to understand what "convey" 
>> means. I think it means that if the ISP information AVP doesn't exist, 
>> EAP can do the network selection within a method:
>>
>>     
>>>   In the absence of an ISP explicitly selected and conveyed by the PaC,
>>>   ISP selection is typically performed based on the client identifier
>>>   (e.g., using the realm portion of an NAI carried in EAP method).  A
>>>   backend AAA protocol (e.g., RADIUS) will run between the AAA client
>>>   on the PAA and a AAA server in the selected ISP domain.
>>>  
>>>       
>> Which suggests that EAP can do the network selection, but gets into 
>> specifics that are probably better left outside of this document.
>>     
>
> I think we can remove the above paragraph on NAI-based network
> selection.
>
>   
>> Finally, this same section refers to RFC 4284 in its final paragraph, 
>> which seems to be yet another way to do network selection inside EAP 
>> (or, is this the same as referred to in the above paragraph?).
>>
>> This section presents far too many ways to do the same thing, and 
>> without enough detail for an implementor to know what to do. This 
>> section either needs work to define the *PANA* way to do this (with 
>> normative language, preferably MUSTs or SHOULDs, referring to protocol 
>> constructs specific to PANA),  in the absence of an EAP method that does 
>> network selection. Or, network selection should be simply removed - it 
>> seems EAP does this anyway, so you could perhaps avoid this problem 
>> altogether by just letting EAP handle it (again, "Less is More").
>>     
>
> The functionality provided by PANA and provided by RFC 4284 is
> different.  RFC 4284 does not allow an EAP peer to choose an ISP using
> a single NAI such as [email-masked].  Also RFC 4284 has a limitation
> in number of ISPs contained in EAP message due to EAP MTU.  I am
> wondering if we can remove refernece to RFC 4284 from the PANA
> specification.
>
> Yoshihiro Ohba
>
>
>   
>> - Mark
>>
>>
>>
>>
>> _______________________________________________
>> Pana mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pana
>>     
>
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
>
>
>   

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana