I have reviewed this document. The chairs believed that this draft could
progress to the IESG, if certain scope reductions would be done and
those are now in effect in -07.
Section 3: you should make it clear at the beginning what you expect as
the output of the discovery process. I believe you are expecting an IP
address of the PAA. Similarly, you should state that the PANA exchange
happens between the client and the CPAA (and not, for instance, somehow
proxied via SPAA).
The security considerations section seems thin. I'm sure there are more
aspects to consider. For instance, what about DoS attacks where an evil
client creates unnecessary state in a large number of networks? What
about opening firewalls up for PANA traffic from the Internet -- it
would seem that at the very least, there's an issue of fraudulent
clients attempting to start EAP negotiations, creating partial session
entries in PANA, AAA, and EAP state machines.
802.21 is mentioned to be the default discovery mechanism. But the text
that says this is very thin on how 802.21 should be used. And the
reference is informative. Maybe there's a part of 802.21 that explains
exactly how to do it and what attributes are used. But I doubt it.
Perhaps it would be better to not claim that 802.21 is the default
mechanism.
Overall, I think this draft is reasonably simple and can move forward.
However, given that we have no real specification of the discovery
phase, and given the general lack of wide-spread working group interest,
I'd say Experimental extension is the right classification.
Jari
_______________________________________________
Pana mailing list
Pana@ietf.org
https://www.ietf.org/mailman/listinfo/pana
