Subject: [tsvwg] WGLC for draft-ietf-tsvwg-ieee-802-11-01 as PS, closes 31 Dec 2016

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 12 Dec 2016 17:27:29 +0000

This email announces a TSVWG Working Group Last Call (WGLC) on:

               DiffServ to IEEE 802.11 Mapping
               draft-ietf-tsvwg-ieee-802-11-01

  https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/

  This WGLC will last for about 3 weeks weeks (due to the holiday season).

  Comments should be sent to the [email-masked] list, although purely
  editorial comments may be sent directly to the authors. Please cc: the
  WG chairs at [email-masked]  if you would like the chairs to
  track such editorial comments as part of the WGLC process.

  No IPR disclosures have been submitted directly on
  draft-ietf-tsvwg-ieee-802-11-01

  Thanks,
  Gorry, David and Wes
  (TSVWG Co-Chairs)

---

From: Vincent Roca <[email-masked]>
Date: Tue, 20 Dec 2016 16:53:44 +0100

Dear authors,

I've read draft-ietf-tsvwg-ieee-802-11-01 and find the quality pretty good. 

I have a few comments but it's more for clarification purposes.

1- Abstract is pretty similar to the general introduction, but not totally. E.g., abstract
explains that the wireless/wired difference come from the presence of two independent
SDOs (only), while section 1 adds the nature of wireless communications. I'd suggest
to shorten the abstract and go deeper into details in Section 1 to avoid such differences.

2- Section 4.1.1: Could you please simplify the following sentence: 
	"So too SHOULD Network Control..."
and the end of this paragraph. I have problems understanding it.

3- Section 5.3: the notion of "DSCP trust" is a little bit strange.
For me, the notion of trust is associated to a security assessment.
For instance, marking could be trusted because it's handled by a secure mechanism,
because the packet integrity is verifiable, etc. From what I understand, "trusted" means
that DSCP marking is more accurate (6 bits) than UP marking (3 bits). That's totally
different.

4- Section 8, "Security considerations": 
this section is strange as it references a single threat. Do you mean that no other risk exists?
Whether this is the case or not, this should be clearly said.

5- Section 8, "Security considerations":  
More generally, if a end-host can cheat while marking its traffic, then DoS are pretty easy to
launch. Is there any solution to this problem? One can probably reduce risks, for instance by
rate limiting techniques on a per source MAC or IP address basis (assuming this address has
not been forged), but solving risks totally seems difficult without strong authentication.
Perhaps WPA/WPA2 could help here? I don't know what you think about it?

6- Section 8, "Security considerations":
I'm also wondering if the DSCP/UP mapping process can be considered secure? Section 3 gives
some insights ("all wireless endpoint devices support the ability to support fully-configurable mappings...").
A malware may corrupt this end-host mapping, no?

7- Section 8, "Security considerations":
Having an empty 8.1 Privacy considerations section is strange. Say explicitely that you don't
think this document has any impact here.

Typos and other details
--------------------------------

** Section 1.2 says: "... without reference to the service plan documented in Section 1.1".
It is not so obvious for me that section 1.1 refers to the "1.1 Related work" section or not, nor a specific reference in this section. Please clarify.

** Section 5.3:
        - "to achieve and end-to-end differentiated service" => an

** Section 6.3:
        - missing closing parenthesis in sentence: "(as a baseline"
        - "to be make in line with" => made

Best regards,

  Vincent