State Machines for the Protocol for Carrying Authentication for Network Access (PANA)
RFC 5609
Yes
(Jari Arkko)
No Objection
Lars Eggert
(Alexey Melnikov)
(Cullen Jennings)
(Dan Romascanu)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 13 and is now closed.
Lars Eggert
No Objection
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2009-04-20)
Unknown
I'm clearing as Jari has pointed me at Section 4 that covers my most significant issue. There are two important points that are shown in the Abstract that I would like you to consider adding to the main body of the text. - "The statemachines and associated model are informative only." - "Implementations may achieve the same results using different methods."
Alexey Melnikov Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2009-04-27)
Unknown
Opening caveat: I am not really a state machine guy, so this may all be normal accepted practice. That is why it's a discuss discuss. I found the use of the eap_piggyback procedure in the exit conditions to be very confusing. I would expect exit conditions to be specified in terms of the rec'd messages and state variables, but not locally executed procedures. In a number of cases, there are two exit conditions that differ solely in the value returned by this procedure. It would make more sense to me if the exit condition was specified without eap_piggyback, and the call to eap_piggyback was the first step in the exit condition. This has an unfortunate side effect (multiple exit states, depending on the result), which may explain the methodology I will give one example to provide a basis for discussion. As dscribed above, note that collapsing the two states into one results in two different exit states: Current text, page 21: - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - - Rx:PAR[S] && EAP_Restart(); INITIAL PAR.exist_avp TxEAP(); ("EAP-Payload") && SessionTimerReStart eap_piggyback() (FAILED_SESS_TIMEOUT); Rx:PAR[S] && EAP_Restart(); WAIT_EAP_MSG PAR.exist_avp TxEAP(); ("EAP-Payload") && SessionTimerReStart !eap_piggyback() (FAILED_SESS_TIMEOUT); if (generate_pana_sa()) Tx:PAN[S]("PRF-Algorithm", "Integrity-Algorithm"); else Tx:PAN[S](); What I would have expected: - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - - Rx:PAR[S] && if eap_piggyback() INITIAL PAR.exist_avp EAP_Restart(); ("EAP-Payload") TxEAP(); SessionTimerReStart (FAILED_SESS_TIMEOUT); else EAP_Restart(); WAIT_EAP_MSG TxEAP(); SessionTimerReStart (FAILED_SESS_TIMEOUT); if (generate_pana_sa()) Tx:PAN[S]("PRF-Algorithm", "Integrity-Algorithm"); else Tx:PAN[S]();