| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Yunsong, Re-reading your shortened sentence highlights what I guess is the problem I see. When the variable is true "a non-AP STA shall periodically change its MAC address". That's the idea here. Every <whatever> increments of time you change your MAC address. But "a non-AP STA shall not perform MAC randomization during transactional exchanges." So you could change a MAC address every 30 seconds. That's the period you choose. And in that period you can do a transactional exchange with the random MAC address. But if the period expires and you're in the middle of the transactional exchange you don't change your MAC address, because it is "during [the] transactional exchange." Your suggested change is "a non-AP STA shall periodically change its MAC address…except when the non-AP STA is performing transactional exchanges." Which sounds like as long as you do some kind of transactional exchange you don't randomize your MAC. It could be read to mean that doing transactional exchanges is a kind of veto on the variable setting—if the variable is set do this, except under this circumstance. And that is not the intent. That's why I think it's better to say, "the idea here is you set a period and when the period expires you change your MAC address, when it expires again you change your MAC address." Period. The concept is established. Now, "you shall not change your MAC address during a transactional exchange." This makes the exception more explicitly placed. We want the flag to overrule a MAC change to be set when engaged in a transactional exchange and cleared when the transactional exchange is over. We don't want to have a flag that effectively turns off MAC randomization simply because one is doing transactional exchanges. Am I making sense? regards, Dan. On 4/20/17, 12:40 PM, "Yangyunsong" <yangyunsong@xxxxxxxxxx> wrote: Hi Dan, Thank you for considering my comments and suggestions. My view is that the first paragraph not only introduces the concept, but also defines certain mandatory (because of the “shall”) behaviors of the non-AP STA, i.e., changing
the MAC address periodically. If there is no “shall” in the second sentence, it would be perfectly OK to mention the exception at a later place. But once we use “shall” and indeed there are exceptions, we should include the exceptions right in the “shall”
sentence. Otherwise, we are introducing two conflicting mandatory behaviors. That was the reason behind my 1st and 3rd suggestions. Between you and I, we are perfectly clear on what we are talking about here. But for developers who come
aboard at a later time to implement this standard, having conflicting “shall” statements may confuse them. Yes, as you pointed out that the second sentence became longer with the suggested change. I wonder if it would help to make it simpler by breaking it into two sentences
as follows: “When dot11MACPrivacyActivated is true, a non-AP STA shall periodically change its MAC address to a random value except when the non-AP STA is performing transactional exchanges. Examples
of transactional exchanges include transmitting and receiving public action frames for pre-association discovery.”
Let’s also hear what other members think of this. Thank you. Best regards, Yunsong Yang Huawei Device USA Inc. 10180 Telesis Court, STE 165 San Diego, CA 92121 Phone: +1-858-754-3638 From: Harkins, Daniel [mailto:daniel.harkins@xxxxxxx]
Hi Yunsong, Thank you for your comments. Your second comment is a great one and I will update the draft. But I would like to discuss your first and third comments. They are basically the same comment, just moving the text about transactional exchanges up into the description of the period when one changes MAC addresses. My view is that the first paragraph is introducing the concept—periodically change the MAC address if this variable is true. Once the concept is introduced an exception is made: don't do this during transactional exchanges. If the exception is included in the general introductory statement I think it takes away from the flow and understanding of the concept. It makes the sentence more complex. My feeling is I would like to respectfully decline those two comments (accepting the other one) but I would like to know how strongly you feel about them. Please let me know, I'm updating the submission. regards, Dan. On 4/18/17, 4:50 PM, "Yangyunsong" <yangyunsong@xxxxxxxxxx> wrote: Sorry for sending this to the WG e-mail list. This was meant for TGaq only. Best regards, Yunsong Yang Huawei Device USA Inc. 10180 Telesis Court, STE 165 San Diego, CA 92121 Phone: +1-858-754-3638 From: *** IEEE stds-802-11 List *** [mailto:STDS-802-11@xxxxxxxx]
On Behalf Of Yangyunsong --- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Dan, Thank you for updating the text. I would like to suggest a few editorial changes to clause 12.2.10, as attached. Thanks, Yunsong Yang Huawei Device USA Inc. 10180 Telesis Court, STE 165 San Diego, CA 92121 Phone: +1-858-754-3638
_______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.
If there is no LEAVE button here, try
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO. Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect. Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-tgaq and then press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |