Subject: [[email-masked]: Re: [Pana] Comments on draft-ohba-pana-statemachine-01 from Dan]

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 02 Mar 2005 03:42:16 -0500

----- Forwarded message from Victor Fajardo <[email-masked]> -----

From: Victor Fajardo <[email-masked]>
Subject: Re: [Pana] Comments on draft-ohba-pana-statemachine-01 from Dan
To: Yoshihiro Ohba <[email-masked]>
Cc: [email-masked], Victor Fajardo <[email-masked]>
X-VirusChecked: Checked
X-Env-Sender: [email-masked]
X-Msg-Ref: server-4.tower-94.messagelabs.com!1109798244!11097328!1
X-StarScan-Version: 5.4.11; banners=-,-,-
X-Originating-IP: [128.96.41.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hi Dan,

Thanks for the review. Comments below:

>
>State machine comments
>----------------------
>
>Section 6.4. PAC State machine
>
>   State WAIT_EAP_MSG_IN_DISC: How about PAA retransmitting PSR, or is
>   it queued and consumed in WAIT_PAA state?
>
Good point. I guess there is two(2) approach to this. First opition is
not to handle PSR retransmission (retransmission is ignored as it is
now) and we simply let EAP provide the outcome for the next state
transition (i.e. via timeout or response). Second option is to provide
an explicit PSR handler and we pass the retransmitted EAP request to the
EAP peer (EAP will also take care of retransmission). It maybe best to
use the first option since we really don't need to process
retransmission. We already got the initial packet and already processing it.

>
>   State WAIT_PAA, 2nd EAP result, 6th transfer: what is the meaning
>   of this? I.e. PAA sends PANA_SUCCESS as result code without
>   EAP_Payload AVP and alt_reject() is executed. Is this really
>   possible?
>
I agree. This is state transition also present in 1st EAP result and
should be removed.

>
>   States WAIT_EAP_RESULT_CLOSE, WAIT_1ST_EAP_RESULT, and
>   WAIT_1ST_EAP_RESULT_CLOSE. Should EAP_RESP_TIMEOUT be here as well.
>
I agree.

>
>Section 7.4 PAA State machine
>
>   None for now.   
>   
>Editorial comments
>------------------
>
>Possibly a terminology section needed:
>
>   "state block", "variable", "event variable", "configuration
>   variable?" (i.e. explain the variables, their "scope" and
>   differences).
>
Ok.

>
>Chapter 4. 
>
>   3rd paragraph: There could a figure showing the triplet before the
>   text that starts with "All conditions are expressions that...".
>
>
Mmm ... I'm not sure this can provide additional information since the
figure would be very primitive, i.e. ascii figure: exit condition -->
exit action --> exit state. I think maybe the triplet can already be
easily implied from the state diagram/table itself.

>   4th paragraph: Fragment the sentence starting with "The exit
>   actions in only one state block execute at a time, even if the
>   conditions..".
>
Ok.

>
>   5th paragraph: What is the reason for this? To simulate
>   polling/event notification system.
>
I think it attempts to state that in an event driven system, however
means those events are generated ... via polling or some other means,
that each event is evaluated if it meets conditions for the current
state. In this sense, we can re-word the paragragh from:

On completion of the transition from the previous state to the
current state, all exit conditions for the current state (including
exit conditions defined for the wildcard state) are evaluated
continuously until one of the conditions is met.

to:

On completion of the transition from the previous state to the
current state, all exit conditions occurring during the current state
(including exit conditions defined for the wildcard state) are evaluated
until an exit conditions for that state is met.

>
>Section 5.1
>
>   EAP_Restart(): New session or eap reauth?
>
reauth in some sense. Mostly has to do more with re-initializing an
existing EAP session. The can re-word the descriptions from:

"A procedure to (re)start an EAP conversation."
to:
"A procedure to (re)start an EAP conversation resulting in the
re-initialization of an existing EAP session"

>
>Section 5.3
>
>   Add new line between the two last bullets.
>
Ok.

>
>Section 5.6
>
>   "The following transitions can occur at any state.", but the state
>   CLOSED is used in the end.
>
I agree. I will add more appropriate heading for the CLOSED transition.

>
>   s/retransmission/transmissions/
>
>   Could rephrase the "Reach maximum number of retransmission" or move
>   it before the exit conditions where the exit action is
>   Disconnect().
>
Ok.

>
>Section 6.1.1 and 7.1.2.
>
>   "this procedure is enabled only after..." Could explain when
>   disabled to get better picture (i.e. to say that it happens
>   implicitly via the session termination?).
>
Ok. We can re-word from:

"..... This procedure is enabled only after an EAP restart event is
notified to the EAP peer."

to:

"..... This procedure is available after an EAP restart event is
notified to the EAP peer
and before any event resulting in a termination of the EAP peer session"

Same can be done for 7.1.2

>
>Section 6.1.5
>
>   alt_reject() procedure example could help to understand.
>
Mmmm ... I think the description regarding altReject variable in the EAP
statemachine already well describes alt_reject()'s behavior.

>
>Section 6.2 and 7.2
>
>   Could separate event variables from the "others"? Are there for
>   example configuration variables. [could even add a prefix like
>   EVENT_, or CONF_, or STATIC_].
>
>
This is probably a good idea.

>Section 6.4
>
>   State OFFLINE: 4th PSR processing transition, exit condition:
>   s/PSA.S_flag/PSR.S_flag/
>
Ok.

>
>   State WAIT_EAP_RESULT (return PSA). Authorize() and
>   SessionTimerStart() order differs in the 2 first
>   transitions. (consistency).
>
>
Ok.

>Chapter 7.
>
>   Explain that the PAA state machine is session specific, i.e. not
>   supporting multiple session simultaneously.
>
I agree. Additional text should be added to clarify this.

>
>Section 7.2
>
>   Add new line before EAP_FAILURE entry.
>
Ok.

>
>Section 8.
>
>   s/be seamlessly be/be seamlessly/
>
Ok.

>Section 9.3
>   s/be bounded/be bound/
Ok.

>
>Section 12 (references)
>
>   Add other authors to the draft-ietf-pana-mobopts-00.
>----
>
>
Ok.

Thanks very much for your help,
-- victor

----- End forwarded message -----

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana