From 750e28200a07ceacd01126fcfe91ac029a4b30b3 Mon Sep 17 00:00:00 2001 From: Nils Andreas Svee Date: Thu, 13 Aug 2026 17:35:21 +0700 Subject: [PATCH] docs(server): scope the strict-mode restriction claim The environment notes said restriction scenarios were run both with and without --loose, but the matrix records a strict run for the packet-length restriction only; the interval and maximum-duration rows were --loose alone. Say that, so the artifact does not credit strict-mode coverage it never recorded. No implementation, test or protocol evidence changes. --- docs/validation/UPSTREAM_CLIENT_INTEROP.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/validation/UPSTREAM_CLIENT_INTEROP.md b/docs/validation/UPSTREAM_CLIENT_INTEROP.md index b9d7ec2..4c3e881 100644 --- a/docs/validation/UPSTREAM_CLIENT_INTEROP.md +++ b/docs/validation/UPSTREAM_CLIENT_INTEROP.md @@ -42,10 +42,12 @@ Flags used were taken from the executable's own `irtt help client` output: `--tstamp`, `--clock`. `--loose` is upstream's documented client-side switch for accepting -server-restricted test parameters instead of exiting non-zero. Restriction -scenarios were therefore run **both** ways: without it to confirm the client -detects and reports the restriction, and with it to confirm the restricted -session actually runs. +server-restricted test parameters instead of exiting non-zero. The +**packet-length** restriction was run both ways: without it, to confirm the +client detects and reports the restriction, and with it, to confirm the +restricted session actually runs. The interval and maximum-duration +restrictions were run with `--loose` only, so strict-mode refusal was observed +for packet length alone and is not claimed for the other two. ## Matrix