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 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. 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
