Diffserv to IEEE 802.11 Mapping

Note: This ballot was opened for revision 09 and is now closed.

Spencer Dawkins Yes

Alia Atlas No Objection

Deborah Brungard No Objection

Comment (2017-11-29 for -09)
Agree with Mirja's comments, especially the category, I think this should be a BCP.
A BCP is a way to standardize practices and the results of community deliberations.
While the working group noted their desire for PS to "encourage consistent
implementation", this is the definition of a BCP.
A BCP "is designed to be a way to standardize practices" (RFC2026), it is not

Ben Campbell No Objection

Comment (2017-11-29 for -09)
Editorial Comments:

- It might be helpful to make it clear early in the draft that "wireless" means 802.11, not LTE, etc. Section 1.2 sort of does that, but I think there's room for stating it earlier and more strongly.

-1.5: There are a number of lower case instances of "must" and "should". If that is intentional, please consider using the boilerplate from 8174 instead of 2119.

Alissa Cooper No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2017-11-28 for -09)
Firstly, I'd like to thank David Black for one of the best shepherd writeups I've seen in a very long time.
I'd also like to thank Sarah Banks for the nice OpsDir writeup.

I had many of the same questions as Mirja - hopefully, they are being addressed/answered.

Mirja Kühlewind No Objection

Comment (2017-11-14 for -09)
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:

"The RECOMMENDED DSCP marking for Network Control is CS6, per
   [RFC4594] Section 3.2;"
"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
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?

Terry Manderson No Objection

Alexey Melnikov No Objection

Kathleen Moriarty No Objection

Eric Rescorla No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2017-11-29 for -09)
Please expand the following acronyms upon first use; see
https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - RF - radio frequency
 - IPX - Internetwork Packet Exchange
 - BSS
 - NVO3