[tsvwg] Mirja Kühlewind's No Objection on draft-ietf-tsvwg-ieee-802-11-09: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tsvwg-ieee-802-11-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two (important) high level comments:

1) I really think this doc should not redefine normative mapping that are
already defined in RFC4594. I would srongly recomend to repharse without using
normative language and just refer to RFC4594. One example:

OLD
"The RECOMMENDED DSCP marking for Network Control is CS6, per
   [RFC4594] Section 3.2;"
NEW
"The recommended DSCP marking for Network Control is CS6, per
   [RFC4594] Section 3.2;"
OR (you can use a literal citation):
"As stated in [RFC4594], Section 3.2: "The RECOMMENDED DSCP marking [for
Network Control] is CS6"."

2) Further, I’m wondering if this document should be rather BCP than Standards
Track as it does not define a protocol but gives normative recommendations?

----
Other comments:

1) EIFS is not defined/extended

2)  in sec 4.2.2:
„(as recommended above and following the EDCAF treatment logic described in
Section 4.“ maybe s/described in Section 4/described at the beginning of this
Section/ I was a bit confused where in section 4 given this text is in section
for.

However, maybe it might be good to actually move that paragraph at the
beginning of section 4 explaining implementations of UP differentiation
somewhere to section 1 or in an own section, as it rather provides background
info than making any recommendations.

3) in sec 4.2.5:
„The Multimedia Streaming service class is RECOMMENDED for
   applications that require near-real-time packet forwarding of
   variable rate elastic traffic sources.  Typically these flows are
   unidirectional.“
Not sure if streaming is typically unidirectional, but why is this important
here?

4) Sec 5:
„This is RECOMMENDED whenever supported.“
Actually not sure what this means or why it is necessary to say this
(normatively).

5) Sec 5.2:
„Therefore, it is NOT RECOMMENDED that wireless access points leverage Layer 2
   [IEEE.802.11-2016] UP markings as set by wireless hosts…“
I think this could be made even stronger and say MUST NOT instead (where NOT
RECOMMENDED is a SHOULD NOT)

6) sec 5.3:

„CS6 and CS7 SHOULD NOT be passed through to the wired network in the upstream
 direction unless…“
Should this maybe also be a „MUST NOT“?

7) Section 6:
I would recommend to actually move the background described here (mainly
section 6.1) to an appendix at the end of the doc, given the intro says that.
Further, section 6.3 should be moved to an own section (that stays in the body
of the document) as it actually provides normative recommendations. I would
further recommend to keep section 6.2 also in the body but move it before
section 2 as this is the needed background to understand the terminology in
this doc. Respectively terminology that is only used (and explained) in section
6.1 could be removed from section 1.6.

8) Section 8.1
„Policing EF marked packet flows, as detailed in [RFC2474] Section 7 and
[RFC3246] Section 3.“ This doesn’t appear to be full sentence.

9) Also section 8.1:

„This is especially relevant for IoT deployments, where tens-of-billions of
      devices that may have little or no security are being connected to IP
      networks.“
I really don’t see why this is more relevant for IoT than other devices that
connected to a wifi network. Is this sentence actually needed here?

Also, this document, recommends bleaching, however, isn’t there another
DiffServ RFC that discusses forwarding policies that should be references
(maybe even instead of making an explicit normative recommendation in this
doc)? Maybe RFC8100 (didn’t look it up…)?

10) Also section 8.2:
„… it is RECOMMENDED that all packets marked to Diffserv Codepoints not in use
over the wireless network be mapped to UP 0…“ I’m actually not certain what
„not in use over the wireless network“ means here. Can you please further
specify this!

11) Question regarding section 5.1 and 8.2 respectively: 
I assume e.g. DHCP
traffic is not considered as control traffic then? Might be good to state this
explicitly… Or should it?