diff --git a/documentation/general/design/dash-handling-fragmented-packets.md b/documentation/general/design/dash-handling-fragmented-packets.md
index 3742cb879..12cfcf75b 100644
--- a/documentation/general/design/dash-handling-fragmented-packets.md
+++ b/documentation/general/design/dash-handling-fragmented-packets.md
@@ -123,9 +123,17 @@ The figure below shows the TCP header format. For more information, see [RFC 793
 result in an **entry** into the **flow table** to **enable fast path
 processing** for the duration of the connection.
 
-1. If a subsequent packet arrives that is the start of a fragmented packet, the
+1. If a subsequent packet arrives that is the first fragment of a fragmented packet (i.e. the Fragment Offset field is 0), the
 **Frag ID** must be used to create a **new temporal flow** that can be
 **uniquely identified** by the (**Frag ID**, **DST**, **SRC**, **Protocol ID**) tuple.
+This **temporal flow** must record the relevant layer 4 header fields
+from the packet that are needed for classification, e.g. source &
+destination port, for retrieval by later arriving non-first IP
+fragments that match this **temporal flow**.
+
+1. If a packet arrives that is a non-first fragment (i.e. the Fragment Offset field is not 0), and there is not already a **temporal flow** that matches
+this packet, the packet must be dropped, and no **temporal flow** will be
+created.
 
 1. The temporal flow should be **maintained until the last fragment arrives** or
 the flow is **aged** or the connection is **closed**.