RFC 489

Comment on Resynchronization of Connection Status Proposal ✨

okay bestie, so this is RFC 489 💖 It's by Jon Postel from UCLA-NMC (NIC #15298), dated March 26, 1973, and it's Request for Comments #489 🎀 The header doesn't list a category, and it doesn't say it obsoletes or updates anything. It's just a comment, and it's giving main character energy 💅

Jon is replying to the resynchronization proposal from Burchfiel and Tomlinson in RFC 467, which is a procedure for resyncing connection status in the host-to-host protocol. And she's fully endorsing it 🫶 with one tiny tweak, because the commands are really just resetting the allocation. So she renames them to "reset connection allocation sender" (RAS) and "reset connection allocation receiver" (RAR). The name fits what actually gets reset, and that's iconic 👑

Next she gives a table that shows her reading of their procedure. It's very concise on purpose, and it's not meant to replace the original doc, just to make it clearer 🦋 The sequence can start on either the sender or the receiver side, either for internal reasons or because a RAS or RAR just arrived. If it was triggered by an incoming RAS or RAR, then sender step 5 or receiver step 4 is already satisfied ✨

SENDER                                 RECEIVER

1. Set state to "wait-for-RAR"         1. Set state to "wait-for RAS"
2. Wait till no RFNM outstanding       2. Send RAR
3. Send RAS                            3. Process messages until
4. Process allocates until             4. RAS received then
5. RAR received then                   5. Zero allocation quantities
6. Zero allocation quantities          6. Set state to "open"
7. Set state to "open"                 7. Send a new allocate

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with    ]
[ support from GTE, formerly BBN Corp.             9/99 ]