Network Working Group                                     Jon PostelRequest for Comments: #489                                UCLA-NMCNIC #15298                                                March 26, 1973       Comment on Resynchronization of Connection Status PRoposalThis is a comment on the proposal by Burchfiel and Tomlinson in RFC467for a procedure in the host-to host protocol for resynchronization ofconnection status.  I endorse their proposal with the following trivialchange.  The commands proposed might be more appropriately be called"reset connection allocation sender" and "reset connection allocationreceiver" since the only aspect of the connection which is reset is theallocation.  I therefore use the names RAS and RAR respectively.The table below shows in overly concise notation my interpretation ofthe resynchronizing procedure proposed by Burchfiel and Tomlinson, thispresentation is not intended to supersede their document but to clarifythe procedure.  The sequence shown here can be initiated by either thesender or receiver either for internally generated reasons or upon thereceipt of a RAS or RAR, if this latter is the case then sender step 5or receiver step 4 is satisfied.SENDER                                 RECEIVER1. Set state to "wait-for-RAR"         1. Set state to "wait-for RAS"2. Wait till no RFNM outstanding       2. Send RAR3. Send RAS                            3. Process messages until4. Process allocates until             4. RAS received then5. RAR received then                   5. Zero allocation quantities6. Zero allocation quantities          6. Set state to "open"7. Set state to "open"                 7. Send a new allocate       [ This RFCwas put into machine readable form for entry ]       [ into the online RFCarchives by Alex McKenzie with    ]       [ support from GTE, formerly BBN Corp.             9/99 ]