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.
MAY "convey" doesn't mean anything to an implementor. Normative language
should be used when you are talking about protocol constructs, not
abstract actions.
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.
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").
- Mark
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
