confusing narrative around redelivery of control packets

Update Section 4.4 as follows: Remove >> When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1] . This is the only circumstance where a Client or Server is REQUIRED to redeliver messages. Clients MAY re-send SUBSCRIBE and UNSUBSCRIBE Packets on reconnect but are not REQUIRED to do this. While a modern TCP network is unlikely to lose packets, a Client or Server is permitted to attempt redelivery of unacknowledged packets at other times. However, redelivery is not encouraged unless a network failure has been detected. The PUBLISH packet MUST have the DUP flag set to 1 when it is re-sent [MQTT-4.4.0-2] . Non Normative comment. Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments. << Replace with: >> When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1] . This is the only circumstance where a Client or Server is REQUIRED to redeliver messages. Non Normative comment. Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments. << Note: the clause "The PUBLISH packet MUST have the DUP flag set to 1 when it is re-sent [MQTT-4.4.0-2] ." is a dup of "The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver a PUBLISH Packet [MQTT-2.2.2-3] ." under Section 2.2.2.1. Removing it from 4.4 seems to make sense.