> > 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? > > > It's not about the number of messages alone, number of AVPs alone, etc. > It's how all the different permutations are combined. As you imply here, > the message header, the message types, the AVPs, etc. are a hierarchy, > and one can draw the lines in different places. IMHO, the message header > should be best left to context lookup and transport (reliability and > sequencing) and message verification (hashing and the like) functions,
Are you suggesting we do not include "Message Type" in the PANA header? > the message types to major PANA state transitions or specific functions > (like ping), and the AVPs as options within the state change or > function. In order to better understand what you are suggesting, can you please tell us what we need to change in our current design? Given that: - We have phases (handshake, authentication and authorization, access, re-authentication, termination). - Each phase has a set of expected message types and specific flows (e.g., handshake: PCI, PSR, PSA; termination: PTR, PTA; etc.). - Message type is carried in the PANA header - Each message type is defined to include certain set of AVPs (e.g., PSR: EAP, Algo). > Finally, since PANA is effectively a transport protocol for > EAP, EAP should be treated as a Payload which can be carried over the > protocol's different modes of transport with as little linkage to the > state of PANA beneath as possible. I don't see any of these lines > clearly drawn, which may be the source of some of your headaches at this > stage. > >>> 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. > > > I'm not sure you want to, I would think that it would be the preferred > method of operation in fact. > > Now, if you completely decouple your PANA states from the type of EAP > message being carried, and position the EAP message as something that > can effectively show up as a Payload AVP at anytime, then perhaps you > can have the best of both worlds here. Alper > > - Mark _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
