Subject: [Pana] Review of draft-ietf-pana-statemachine-08

From: Suresh Krishnan <[email-masked]>
Date: Fri, 16 Jan 2009 16:01:49 -0500

Hi Folks,
   I was requested by the chairs to review 
draft-ietf-pana-statemachine-08. I have reviewed the document and I have 
a few comments.

Overall
=======

* What is the intended status of this draft? I assume informational but 
please update the draft to include this.

Section 4
=========

* This sentence is a bit unclear.

"When a discrepancy occurs between any part of this document and any
  of the related documents ([RFC5191], [RFC4137] the latter (the other
  documents) are considered authoritative and takes precedence."

What does this mean exactly? e.g. In 4137 the actions are executed on 
entry into the state and in this document they are executed on exit. 
Does this mean there is a discrepancy?

Section 5
==========

* "On exit from a state, the exit actions defined for the state and the
    exit condition are executed exactly once, in the order that they
    appear on the page."

What page?

* "A state "ANY" is a wildcard state that matches the current state in
    each state machine."

Did you mean to say

"A state "ANY" is a wildcard state that matches any state in the current
  state machine."

* The state "ANY except foo" has not been defined here but has been used 
later.

* How do I send PANA messages with multiple flags set? e.g. I want to 
send a PAR with I and S bits set. The description language does not seem 
to allow this.

Section 6
=========

* I do not think that RTX_MAX_NUM can be a constant for the state 
machine since it can differ for different PANA messages. e.g. 0 for PCI 
and 10 for PAR.

Section 9.1
===========

* I am not sure what this section has to do with implementation of state 
machines. Can you please clarify?

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

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 20 Jan 2009 09:46:22 -0500

Hi Suresh,

Thanks for the review.

>
> * What is the intended status of this draft? I assume informational 
> but please update the draft to include this.

Ok.

> Does this mean there is a discrepancy?

I guess the sentence needs to be clarified. It was trying to imply that 
if some state transitions in this document is contradicting events 
and/or transitions in 4137 then 4137 is to be followed and that there 
are flaws in this document.

> Section 5

I think we can remove that term "on the page" which is mis-leading.

> "A state "ANY" is a wildcard state that matches any state in the current

Good point. thanks.

>
> * The state "ANY except foo" has not been defined here but has been 
> used later.

Yes. we should add clarifying text for this 'conditional' catch-all.

> send a PAR with I and S bits set. The description language does not 
> seem to allow this.

In Sec 6.1, the definition for Tx:PANA_MESSAGE_NAME[flag](AVPs) should 
allow for multiple bit settings. We can clarify the scenario for having 
multiple flags here, for example: PANA_MESSAGE_NAME[I, S](AVPs)

> machine since it can differ for different PANA messages. e.g. 0 for 
> PCI and 10 for PAR.

The procedure RtxTimerStart() would typically set RTX_MAX_NUM to an 
appropriate value (Sec 6.1). But we can also clarify this by expanding 
the description of the text for RtxTimerStart().

>
> Section 9.1
> ===========
>
> * I am not sure what this section has to do with implementation of 
> state machines. Can you please clarify?

Its suppose to comment on a general pattern on how to integrate PANA 
implementations to an existing system. I can re-factor the text to make 
that point clearer.

many thanks,
victor