diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index 66d539e5e..e26762645 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -794,9 +794,15 @@ is destined, is described in [BOLT #4](04-onion-routing.md).
 #### Requirements
 
 A sending node:
-  - MUST NOT offer `amount_msat` it cannot pay for in the
-remote commitment transaction at the current `feerate_per_kw` (see "Updating
-Fees") while maintaining its channel reserve.
+  - if it is _responsible_ for paying the Bitcoin fee:
+    - MUST NOT offer `amount_msat` it cannot pay for in the remote commitment
+    transaction at the current `feerate_per_kw` (see "Updating Fees") while
+    maintaining its channel reserve.
+  - if it is _not responsible_ for paying the Bitcoin fee:
+    - MUST NOT offer `amount_msat` if the remote cannot pay the fee for the
+    updated commitment transaction at the current `feerate_per_kw` (see
+    "Updating Fees"). In that case the remote may temporarily dip into its
+    channel reserve to pay the fee, but only for one pending non-dust HTLC.
   - MUST offer `amount_msat` greater than 0.
   - MUST NOT offer `amount_msat` below the receiving node's `htlc_minimum_msat`
   - MUST set `cltv_expiry` less than 500000000.
@@ -863,6 +869,10 @@ seconds, and the protocol only supports an expiry in blocks.
 specification; larger amounts are not necessary, nor wise, during the
 bootstrap phase of the network.
 
+The node _responsible_ for paying the Bitcoin fee should be allowed to dip into
+its channel reserve to accomodate a fee increase, otherwise the channel may end
+up in an unusable state (see [#728](https://github.com/lightningnetwork/lightning-rfc/issues/728)).
+
 ### Removing an HTLC: `update_fulfill_htlc`, `update_fail_htlc`, and `update_fail_malformed_htlc`
 
 For simplicity, a node can only remove HTLCs added by the other node.