General Internet Signaling Transport (GIST) State Machine
RFC 5972

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

(Lars Eggert) Yes

(Stewart Bryant) No Objection

Comment (2010-04-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
In Appendix A the authors state: "This appendix contains the state diagrams in ASCII format. Please use the PDF version whenever possible: 
it is much easier to understand."

It would be useful if the authors made it clear to the readers at the beginning of the document that a PDF version existed and that in their view this was a clearer representation of the state machine. In particular it should be noted at the top of section 6 that a more readable version exists.

The authors also need to add a note stating which version the reader should take as correct in the event of a difference between the two documents.

Given the authors' stated preference for the .pdf version, and the informational nature of this document have they considered eliminating any version ambiguity by reducing the content of the ASCII version to a shell that points to the .pdf version?

(Gonzalo Camarillo) No Objection

(Adrian Farrel) No Objection

Comment (2010-04-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 7 says...

   This document does not raise new security considerations. Any
   security concerns with GIST are likely reflected in security related
   NSIS work already (such as [1] or [6]).

Could you manage to be any less certain of the fact? :-)

(David Harrington) No Objection

Comment (2010-04-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
COMMENTS (general):
1) I realize this is informational, but I think it still needs to be
clear. I have difficulty understanding the variables defined in 5.2.
The definitions do not describe who sets these values when, and who
uses the values when, and what the acceptable values are. 
2) Cmode and Dmode are defined by self-reference: "Cmode: The message
MUST be transmitted in Cmode."  (and is CMode the same as C_mode in
section 5.2?)
3) There are numerous spelling and grammar mistakes that lessen the
quality of this specification. (a spell-check is likely to miss the
use of bellow, where below should be used.) 
4) There are two Figure 1's, and no Figure 2's in the document. Any
references to figures need to be checked to make sure they point to
the correct figure.

COMMENTS (detailed):
1) section 5 has some acronymns that have not been defined yet.
2) I did not understand the sentence starting "Presented in this
document state machines ...". 
Does this mean "The state machines presented in this document ..."?
3) section 5,1 is entitled procedures, but, for example, a
T_No_Response timer is not a procedure. If this is meant to be about
procedures, than each entry should include a verb.
4) The Tx/Rx entries are sorted sometimes by listig all the Tx words
then the rx words, but sometimes in Tx/Rx pairs.
5) some procedures are mixed case (Install) and some are capitalized
(DELETE).
6) some procedures are verbs (DELETE MRS) and some are nouns
(Established MA)
7) section 5.2 'policy) is provided." Provided by whom?
8) Cmode is not defined before use
9) I didn't understand the definition of NewPeer. When is this
variable set, and when is it used? 
10) section 6.2 points to the .txt version in Appendix A; Appendix A
says to use the PDF version. I think there are three different
versions, and maintaining consistency will be difficult. Which diagram
form is the normative diagram? And the normative reference is to the
GIST standard [1]. This multitude of versions doesn't strike me as
clear and unambiguous. I recommend the Apppendix be called the State
Tables, while section 6 is a state diagram, supplemented by a PDF,
that reflects the normative state machine defined in [1].
11) 6.2 point 4) is this the "currently established" MRS? It appears
there might be more than one MRS - a currently established and a
pending-established MRS.
12) 6.2 5) "NSLP applications requests sending data." Does this mean
the applications requests that data be sent? or is it requesting the
data to be sent? 
13) 6.2 17) "Confirm message has not been received by downstream GIST
peer." How would one know if the downstream peer recieved it or not?
Is there an ACK? Then 17) should priobabyl say the ACK was not
recieved.
14) 6.3 "based on local policy" seems to imply that the pervious part
of the sentence is conditional. "If local policy permits, then MRS is
installed immediately." and "If local policy requires an explicit
confirm for MRS installation, then ..."
15) Security Considerations should be clearer than "likely reflected
in ..."
16) I recommend moving the Acknowledghement of Christian into the
acknowledgement section and eliminating the contributors section. And
"since 01 version" seems superfluous in the 09 version.
17) Appendix says see PDF version; where is the PDF version to be
found?

(Russ Housley) No Objection

(Tim Polk) No Objection

Comment (2010-04-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
[I found the following very confusing, but can't see any real harm so I
am making this a comment...]

The state machine is inconsistent with respect to transition numbering:
 
In the querying node state machine (figure 1), transition numbers are
shared if the conditions and actions are identical (transitions 4 and
5), but differe where the conditions are identical but the actions are
the different (i.e., transitions 5 and 14).

In the responding node state machine (Figure 3), the two instances of
transition 5 have identical conditions and different actions. However,
transactions 6 and 12 also have identical conditions and different
actions.

Is there a rationale behind the transaction numbering?

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection