> task at hand. For example, you effectively have 18 different PANA > message types for what is largely a lock-step transport of EAP messages.
There are really 9 message types (answers are using the same message type with the 'R' bit set). In our design, we chose to have a separate dedicated message per action, rather than using fewer messages and decorating each with appropriate flags and AVPs to mean different things. For example, we could say "if the session lifetime is set to 0 in PANA-Foo message, it means the peer shall terminate the session". This could replace the "PANA-Termination-Request". But it'd get us into trouble as we need to define various permutations of AVPs, flags, and their values to define the semantics of each message. With the separate message types, boundaries are cleaner, IMHO. Comments? > As yet another simplification, what if you allowed any authenticated > PANA message update the source IP/port? This would seem to be of > considerable help to NAT traversal (e.g., if the PaC is issuing a > periodic Ping). Also, it would mean that you don't have to define a > specific message (e.g., the Ping, or reauth, etc. would all do the trick > just fine). I'm thinking this implicit semantics may hurt us down the road. There may be valid reasons to send messages with different source addresses in the future. I think a dedicated and explicit message type is better. > 2. With a little bit of work, I think you could eliminate the need for > the PCI and Pana-start messages. Using DHCP for discovery reduces the > need for these messages. In fact, one of the many "optimizations" > described here include carrying EAP directly in these messages, > existence proof that you don't need to provide your own handshake before > encapsulating EAP. I couldn't understand how DHCP helps. PCI is needed to let PaC trigger the PANA exchange. And the reason for a dedicated PSR is the aforementioned design choice. > > Another optimization allows optionally carrying the first > > EAP Request/Response message in PANA-Start-Request/Answer message as > > described in Section 4.3. > > > Another optimization. I'm feeling very sorry for the poor implementor... We could remove that. Thinking more about what we can toss away... How about getting rid of PANA-Error messages? We can include error AVPs in any response message if the request message had an issue. If the response message has an issue, we do nothing (silent discard). Alper _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
