Subject: [Last-Call] Opsdir last call review of draft-ietf-rmcat-wireless-tests-08

From: Fred Baker via Datatracker <[email-masked]>
Date: Mon, 13 Jan 2020 11:31:52 -0800

Reviewer: Fred Baker
Review result: Has Nits

Reviewer: Fred Baker
Review Result: I have a few comments

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

My first comment will probably be addressed by the RFC Editor, but I'll bring
it up. In several places, the language of the document is awkward at best. One
that sticks in my mind is the description of a network containing an 802.11b
domain as containing an "abnomaly". I'm pretty sure it's a typo that a standard
spell checker would have complained about, but Google thinks it's also a skin
care product. The document would benefit from a spell check and an editing pass
by a native English speaker.

The second relates to a specific recommendation in the document concerning
802.11b networks. The issue is that the dynamic range of 802.11 network speeds
is very wide - 802.11b is theoretically capable of 11 MBPS, but typically
achieves something on the order of 2-5 MBPS, while 802.11ac is theoretically
capable of 1.3 GBPS. The difference in speed an introduce issues in network
behavior. Where 802.11b is relevant, the document suggests that "additional
test cases can be added" to cover the case. I suspect that the real issue isn't
802.11b, although the paper cited refers to it; the issue is a network
containing a mix of speeds with a broad range, with the slower ones perturbing
the behavior of the faster ones. I'd suggest that the authors think about the
fundamental issue, and make specific recommendations appropriate to the case
(such as defining effective ranges for link speeds).

(for the record, I sent this to ops-dir@, but don't seem to be able to link to
the post.)