I was thinking about the description of the Disconnect packet, in particular the conformance statements I copied over from MQTT 5, such as: * After sending a DISCONNECT packet the sender MUST NOT send any more MQTT-SN Control Packets on that Virtual Connection

• After sending a DISCONNECT packet the Server MUST delete the Virtual Connection

which do not apply when the Client is expecting a reply, which is usually (always?) when the Client is going to sleep. Also when going to sleep, the Virtual Connection is kept intact - the only case when sending a Disconnect that this is true.
 
I am wondering therefore whether it would be better to have a SLEEP packet to be sent by a Client, with a corresponding SLEEPRESP response. This could allow:

• making DiSCONNECT non-retransmissable again
• never expecting a reply to a DISCONNECT
• not needing Packet ID or Sleep Duration in the DISCONNECT (they would be on the Sleep packet)
• making the DISCONNECT semantics much more like MQTT, including always deleting the Virtual Connection on sending a DISCONNECT
  P.S. Actually, do we still need a Packet ID in a DISCONNECT, for the case where it is a response to a request, say PUBLISH, but the receiver has no Virtual Connection, so the DISCONNECT is indicating that a new connection is needed? One way to avoid this would be to invent another packet explicitly for this purpose - ERROR or something like that.