They conclude that it functions more like a request "staging" ID rather than an HTLC ID. The inclusion of modifications is enumerated by including both parties' highest HTLC ID (two of them) in each commitment signature message. They also mention the importance of ensuring that all messages sent are in order, and if the replyer skips the requester's Add Requests when replying, the skipped requests are assumed to be request rejections or a channel closeout. Joseph suggests disallowing skipping as a protocol violation. In another email thread, Rusty and Joseph discuss the process of HTLC modification requests and how they are staged into the next commitment signature. The inclusion of modifications requires two IDs, one for each party, to allow for timing issues with HTLC Add responses. They clarify that the process is asynchronous but must be done in order. Rusty expresses his gratitude towards Joseph for explaining the process.Rusty and Joseph also discuss the Lightning Network's protocol for handling transactions. They explain the steps involved in securely committing to a transaction, including the requirement for each party to receive the signature for the N+1 commit tx before handing over the Nth revocation preimage. They mention the simplicity of the three-way handshake protocol and the enumeration of modifications in the commitment signature message. They note that updates to lnstate are expected soon.The conversation between Rusty and Joseph further delves into the number of steps required for a secure commit transaction. They discuss the necessity of a three-way handshake at every stage to simplify orchestration and avoid locking across-the-wire. They also touch upon the issues of knowing what a signature covers and whether it's necessary to wait for accept/reject message replies before committing. Rusty questions whether the commit message includes a counter and whether updates should be offered in parallel for good throughput.In a separate communication, Joseph suggests that for synchronous across-the-wire commit steps, it is safer to have three steps instead of two. He explains that keeping everything asynchronous can simplify orchestration and eliminate the need for locking across-the-wire.The context presents a strawman protocol that addresses the need for a more sophisticated approach to overlapping requests. The protocol involves each side maintaining two sets of proposals, one for adding to their HTLCs and another for removing from their HTLCs. The author acknowledges that the protocol is complex and welcomes suggestions for improvement.Rusty asks Joseph and ml to describe their HTLC negotiation protocol as he wants to adapt his code to do the same. He outlines the c-lightning protocol exchange involving sending various packets such as add/fulfill/fail/timeout and receiving acceptance/decline. Rusty proposes variants of the first two steps without a new revocation hash to allow for the addition of multiple changes before commitment. He seeks clarification on the similarity between Joseph and ml's protocol and his own.