An alternative interpretation is that by forbidding the host from issuing any commands for that initial period, the target device could (if it happens to be exp

An alternative interpretation is that by forbidding the host from issuing any commands for that initial period, the target device could (if it happens to be expedient) do all sorts of otherwise spec-violating things, safe in the knowledge that nobody will ever find out[2]. After that grace period, it has to go back to playing by the rules, but doesn't necessarily have to be operational. Whether or not it's operational yet can be queried[1] (after the first timeout), and a decision to use it, retry the query after a fixed or variable additional fallback, or mark it as failed. A better spec might recommend or mandate values for fallback quanta and repetitions, or a maximum bound on the delay, rather than leaving it vendor-gets-to-choose. I didn't look too hard, but a decently marked timing diagram would be nice, and might make it easier to spot the unbounded nature of it, rather than having to cross-reference the inline '10ms' value with the minmax table elsewhere. [1] At least, if I understand it correctly. If accessing the status info uses the same mechanism as general traffic, it's obviously subject to the flaw described, and this interpretation is wrong. [2] c.f. https://en.wikipedia.org/wiki/Don%27t-care_term https://en.wikipedia.org/wiki/Don%27t-care_term and perhaps https://en.wikipedia.org/wiki/Virtual_particle https://en.wikipedia.org/wiki/Virtual_particle