State Machines for the Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-statemachine-13

Note: This ballot was opened for revision 13 and is now closed.

Lars Eggert No Objection

(Jari Arkko; former steering group member) Yes

(Adrian Farrel; former steering group member) (was Discuss) No Objection

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 steering group member) No Objection

(Cullen Jennings; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

(Lisa Dusseault; former steering group member) No Objection

(Magnus Westerlund; former steering group member) No Objection

(Pasi Eronen; former steering group member) (was Discuss) No Objection

(Ralph Droms; former steering group member) No Objection

(Robert Sparks; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

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]();