> >
> > 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.
Use of this feature is optional. That's the intent. So, the implementer
should implement this feature (AVP processing), and also implement a
configuration know to enable/disable its use. If we insert a text like
"Network discovery and selection is a feature that is optionally used."
> 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 PROTECTED] 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.
To contrast PANA, RFC 4284, and NAI-based solutions, I think we should use
the term "network discovery and selection".
Network discovery is how the PaC learns the identifiers of the available
ISPs/NAP to connect to.
ISP/NAP-info AVPs in PANA-Start-Request achieves that.
RFC 4284 achieves that.
The latter was designed by/for 3GPP (see IESG note) in the absence of any
"discovery" support by EAP lower layers, which is considered the right layer
to achieve this functionality. Hence, we provide that functionality in
PANA.
Network selection is how PaC tells the NAS its network selection (ISP to
connect to).
ISP-info AVP in PANA-Start-Answer achieves that.
Looking at realm of NAI can achieve that.
The latter has a limitation as it takes away the flexibility to connect to
an ISP other than the one indicated in the realm of the NAI.
Maybe, what we should do is, first describe the PANA solution in this
section, and at the end talk about the existing workarounds.
In the absence of such network discovery support from existing EAP
lower layers, RFC 4284 defined a workaround by advertising ISP
information in-band with the ongoing EAP method execution. A similar
workaround has been relying on the realm portion of NAIs as a
network
selection tool. It's a deployment decision which one of these
mechanisms is used in a PANA deployment.
Does this make sense?
Alper
>
> Yoshihiro Ohba
>
>
> >
> > - Mark
> >
> >
> >
> >
> > _______________________________________________
> > Pana mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/pana
>
> _______________________________________________
> Pana mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pana
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
