Skip to main content

General Internet Signaling Transport (GIST) State Machine
RFC 5972

Revision differences

Document history

Date Rev. By Action
2015-10-14
10 (System) Notify list changed from nsis-chairs@ietf.org, draft-ietf-nsis-ntlp-statemachine@ietf.org to (None)
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2010-10-06
10 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2010-10-06
10 Amy Vezza [Note]: 'RFC 5972' added by Amy Vezza
2010-10-06
10 (System) RFC published
2010-04-28
10 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-04-28
10 (System) IANA Action state changed to No IC from In Progress
2010-04-28
10 (System) IANA Action state changed to In Progress
2010-04-28
10 Amy Vezza IESG state changed to Approved-announcement sent
2010-04-28
10 Amy Vezza IESG has approved the document
2010-04-28
10 Amy Vezza Closed "Approve" ballot
2010-04-28
10 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2010-04-26
10 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner
2010-04-26
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-04-26
10 (System) New version available: draft-ietf-nsis-ntlp-statemachine-10.txt
2010-04-09
10 (System) Removed from agenda for telechat - 2010-04-08
2010-04-08
10 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-04-08
10 Tim Polk
[Ballot comment]
[I found the following very confusing, but can't see any real harm so I
am making this a comment...]

The state machine is …
[Ballot comment]
[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?
2010-04-08
10 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-04-08
10 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-04-08
10 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-04-08
10 Stewart Bryant
[Ballot comment]
In Appendix A the authors state: "This appendix contains the state diagrams in ASCII format. Please use the PDF version whenever possible:
it …
[Ballot comment]
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?
2010-04-07
10 Sean Turner
[Ballot discuss]
The first and second sentence in the security considerations are somewhat contradictory.  If this document doesn't add any new considerations, then the second …
[Ballot discuss]
The first and second sentence in the security considerations are somewhat contradictory.  If this document doesn't add any new considerations, then the second sentence should be modified to be less vague.  If there are considerations not addressed in the two referenced RFCs then they need to be added in to this document.
2010-04-07
10 Sean Turner
[Ballot discuss]
The first sentence and the second in the security considerations are somewhat contradictory.  If this document doesn't add any new considerations, then the …
[Ballot discuss]
The first sentence and the second in the security considerations are somewhat contradictory.  If this document doesn't add any new considerations, then the second sentence should be modified.  If there are considerations not addressed in the two referenced RFCs then they need to be added in to this document.
2010-04-07
10 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner
2010-04-07
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-04-07
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-04-06
10 David Harrington
[Ballot comment]
COMMENTS (general):
1) I realize this is informational, but I think it still needs to be
clear. I have difficulty understanding the variables …
[Ballot comment]
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?
2010-04-06
10 David Harrington [Ballot Position Update] New position, No Objection, has been recorded by David Harrington
2010-04-06
10 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-04-06
10 Adrian Farrel
[Ballot comment]
Section 7 says...

  This document does not raise new security considerations. Any
  security concerns with GIST are likely reflected in security …
[Ballot comment]
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? :-)
2010-04-01
10 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre
2010-03-31
10 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2010-03-31
10 Lars Eggert Ballot has been issued by Lars Eggert
2010-03-31
10 Lars Eggert Created "Approve" ballot
2010-03-31
10 Lars Eggert State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert
2010-03-31
10 Lars Eggert Placed on agenda for telechat - 2010-04-08 by Lars Eggert
2010-03-31
10 Lars Eggert [Note]: 'Jukka Manner (jukka.manner@tkk.fi) is the document shepherd' added by Lars Eggert
2010-03-17
10 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sam Weiler.
2010-03-16
10 Magnus Westerlund Responsible AD has been changed to Lars Eggert from Magnus Westerlund
2010-03-12
10 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-03-10
10 Amanda Baber IANA comments:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2010-03-03
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Weiler
2010-03-03
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Weiler
2010-02-26
10 Cindy Morgan Last call sent
2010-02-26
10 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2010-02-26
10 Magnus Westerlund State Changes to Last Call Requested from AD Evaluation::AD Followup by Magnus Westerlund
2010-02-26
10 Magnus Westerlund Last Call was requested by Magnus Westerlund
2010-02-26
10 (System) Ballot writeup text was added
2010-02-26
10 (System) Last call text was added
2010-02-26
10 (System) Ballot approval text was added
2010-02-12
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-02-12
09 (System) New version available: draft-ietf-nsis-ntlp-statemachine-09.txt
2010-01-26
10 Magnus Westerlund State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Magnus Westerlund
2010-01-26
10 Magnus Westerlund AD comment sent to authors and list.
2010-01-26
10 Magnus Westerlund State Changes to AD Evaluation from Publication Requested by Magnus Westerlund
2010-01-26
10 Magnus Westerlund [Note]: 'Jukka Manner (jukka.manner@tkk.fi) is the document shepherd' added by Magnus Westerlund
2009-07-28
08 (System) New version available: draft-ietf-nsis-ntlp-statemachine-08.txt
2009-07-24
10 Cindy Morgan Intended Status has been changed to Informational from None
2009-07-24
10 Cindy Morgan
    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of …
    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The document shepherd is Jukka Manner. The chairs believe the document
is ready for publication.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has been extensively reviewed and updated during the
development of the NTLP. There is nothing more to be done.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No concerns.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

Although the document has been discussed and updated regularly, it is
still a bit unclear how much it has influenced the actual protocol
implementations. The document itself looks good and helps understand now
GIST (the NTLP) works, so there is a demand for it. Moreover, the
intended status is Informational.


    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

See above. There is no concern that the document would be harmful or the
like in any way.


    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

The current version has a few nits that have been handled. A new version
has been submitted and will appear once the submission tool opens.

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document has a normative reference to the NTLP spec which has been accepted by the IESG.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

There are no IANA actions for this document.


    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no such needs.


    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary


  This document describes the state machines for the General Internet
  Signaling Transport (GIST). The states of GIST nodes for a given flow
  and their transitions are presented in order to illustrate how GIST
  may be implemented.

          Working Group Summary

The document is a product of the NSIS working group. The WG has reviewed
the document thoroughly, and it has helped a number of implementations,
and in general people to understand how GIST works.

          Document Quality

There exists about half a dozen implementations of GIST, and many of
them have benefited from the state machine specification.
2009-07-24
10 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-07-24
10 Cindy Morgan [Note]: 'Jukka Manner (jukka.manner@tkk.fi) is the document shepherd' added by Cindy Morgan
2009-05-26
07 (System) New version available: draft-ietf-nsis-ntlp-statemachine-07.txt
2008-11-03
06 (System) New version available: draft-ietf-nsis-ntlp-statemachine-06.txt
2008-02-25
05 (System) New version available: draft-ietf-nsis-ntlp-statemachine-05.txt
2007-07-12
04 (System) New version available: draft-ietf-nsis-ntlp-statemachine-04.txt
2007-03-07
03 (System) New version available: draft-ietf-nsis-ntlp-statemachine-03.txt
2006-06-29
02 (System) New version available: draft-ietf-nsis-ntlp-statemachine-02.txt
2005-10-27
01 (System) New version available: draft-ietf-nsis-ntlp-statemachine-01.txt
2005-07-07
00 (System) New version available: draft-ietf-nsis-ntlp-statemachine-00.txt