Fee requirement for closing_signed is unclear

[TheBlueMatt]

closing_signed only requires that no HTLCs remain in either commitment transaction, but then goes on to say that fee_satoshis must be less than or equal to the base fee of the "final commitment transaction". It is, however, not clear which commitment transaction it references especially if you have in-flight update_fee updates waiting on the full commitment dance. eg in case of async message delivery:

update_fee        -.
commitment_signed -.
                  <-    shutdown
update_fee         >
commitment_signed  >

SHOULD A now have to send its closing_signed? It has no HTLCs in either commitment transaction, but has different commitment transactions here. And if it should, which fee does it have to meet?

I guess there are two obvious solutions, change the closing_signed SHOULD timing to say that the two commitment transactions have to be the same tx number (which seems way simpler), or clarify which fee needs to be met.

[nayuta-gondo]

change the closing_signed SHOULD timing to say that the two commitment transactions have to be the same tx number (which seems way simpler),

I agree to try to strict the conditions.
However, the condition that both tx numbers (commitment numbers?) are the same is meaningless.
For example, when the sequence in the figure below is completed, the status of the commitment transaction matches. But both commitment numbers do not match.
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#normal-operation

I think that closing_signed should be sent in the following state.

• There are no HTLCs on both sides.
• There is no pending update_fee on both sides.
• There is only one valid (non-revoked) commitment transaction on both sides.

[nayuta-gondo]

Same but concise expression

• the channel is empty of HTLCs and all updates are irrevocably committed

[ysangkok]

I am a bit curious if anybody knows if there is any programmatic/tool-based way to write a protocol spec to avoid issues like this?

[t-bast]

Hopefully this becomes much better with #1096.