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 |