Got it.
Thanks!
Mark
Hi Mark,
Can you put 1262r0 into to agenda?
11-23-1262-00-00bh-lb274-cr-for-cid7-21-114.pptx
(live.com)
Thanks!
BR,
Okan
Hi Mark,
Thanks for the update.
I can prepare a document and present it on Wednesday session, if this time slot is okay. If not, Thursday session is also okay.
Thanks!
BR,
Okan
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments.
See http://nok.it/nsb
for additional information.
|
Graham/Okan (all),
Based on our discussion today, I’m going to assign CIDs 7, 21 and 114 to Okan.
@Okan Mutgan (NSB): If you would like to present a mechanism for (detecting
and) reporting duplicate addresses back to the non-AP STA, I’ll allocate you time on the agenda. Let me know when you’re ready. We can run Straw Poll(s) as appropriate to determine the desire of the group.
@All, If anyone has comments/suggestions for the duplication MAC address problem, please contribute to the discussion on this thread.
Mark
Hi Graham,
Reasonable cases. Please find my responses inline.
BR,
Okan
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments.
See http://nok.it/nsb
for additional information.
|
Hi Okan,
I see the way you are going. Let’s think about this:
1 – STA A comes in with MAC A and provides IRM B (for next time)
STA A goes or stays
2 – STA X comes in with MAC X and provides IRM B for next time.
That’s a duplicate which the AP can recognize.
[This is the case I was thinking about. Here,
- AP should tell STA X
à DUPLICATE
- STA X comes again with MAC X and provides IRM C for next time.
That’s not a duplicate so STA proceeds.]
3 – STA A comes in with MAC A and provides IRM B (for next time)
STA A goes away
4 – STA X comes in with MAC B (picked at random or first time IRM associate)
AP does not know, thinks it’s STA A. Can’t see how to recognize that.
[Yes, this case might be a problem. I guess using device ID might help here, i.e. STA using IRM and device ID at the same time. In this case, AP also checks
device ID for identification. But I think this case might need further thinking.]
Are there any other cases?
[Not that I think of right now]
How many IRM STAs might an AP have? If truly random, you need a lot of IRMs being saved to get a duplicate, but yes, it could happen.
[Yeah, we are talking about a really low possibility (duplicate IRM), but I guess addressing it would not hurt]
Graham
.
But how does it know if a STA came in with an IRM that was the same as a saved IRM but not the same STA?
Hi Graham,
Thanks for your feedback.
Yes, 7,21,114 concern the probability of selecting same IRM (by more than one STA).
Since the draft does not talk about how to generate IRM, making a note saying that making the selection as random as possible would help.
My thinking is a bit different. I guess a “feedback” might help here, such as:
- Currently, “IRM Status” field is defined for ACK/NACK (IRM recognized/not recognized). Maybe, we can define another field for DUPLICATE. By doing so, STA would know that it chose
a duplicated IRM so that STA would generate a new IRM and try again, expecting that the new IRM is unique (not a perfect solution but at least a mechanism).
- The same DUPLICATE can be realized with a reason code in deauthentication/dissassociaton frame.
These are just my initial thoughts.
We can continue to discuss further.
BR,
Okan
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments.
See http://nok.it/nsb
for additional information.
|
Hi Okan, Mark,
I see you want to address 7,21,114 which concern the probability of selecting same IRM, i.e., how random is PRN?
I am happy for your input on this. It has been put to me that the ‘problem’ seems to be the selection of the same random seed by STAs. Maybe a note needs to be added on making
the selection as random as possible, but I am more than happy for you to weigh in on this.
I think 81 is quite straightforward and I proposed an Accept.
Graham
Thanks, Okan.
Yes, where the CID is already assigned to someone, would you please work with the current Assignee (and if you mutually agree to change the Assignee to you, just let me know).
Otherwise, thanks for volunteering to take these!
Thanks. Mark
Hi Mark, Graham, Jay, and all,
I also plan to take these CIDs:
7, 18, 21, 81, 82, 83, 84, 85, 86, 87, 99, 111, 112, 113, 114.
I realize that some of these CIDs are already assigned. I would be happy to co-work with the assignees as well.
Thanks!
BR,
Okan
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments.
See http://nok.it/nsb
for additional information.
|
OK, as I volunteered on them I did not realize there were notes there already.
Graham/all,
I have incorporated your resolution comments/notes into the r4 of the comment tracking sheet (https://mentor.ieee.org/802.11/dcn/23/11-23-1152-04-00bh-ieee-802-11bh-lb274-comments.xlsx).
However, I note that this is a little complicated, in that some of those CIDs had Notes already (mostly “Submission Required”, etc., but might be more), so I had to do a ‘merge’,
and as a result it is a little unclear which notes are yours, Graham, and which were mine/pre-existing.
I also note that you commented on a few CIDs that are not assigned to you (Graham). And, one CID (214) didn’t have a comment from you. So, we can _mostly_ go through these
by filtering for ones assigned to you, but not 100%.
Bottom line, this is fine, for now, and we (I) can manage and sort things out. But, going forward it is probably better if anyone working on comments does actually post a document
themselves, with a unique DCN, (a subset copy of the comment tracking spreadsheet is fine, or another format, as appropriate), so that we can consider that document as a clearly distinct list of suggested response/proposed resolution from the given author.
Thanks! Mark
Hi Mark,
Please find attached copy of the CID excel. I have written text in the Notes column for all the CIDs allocated to me. May I suggest you copy them into your official spreadsheet
then they can be discussed.
If you prefer that I do a more official submission, let me know, but I think that this should work. If any note is unclear please let me know.
Obviously the question about whether to keep the Status fields is outstanding.
Thanks
Graham
Hi Mark, Jay,
I happily want Jay to address 40, 89, 137, 178, and 224. Thanks Jay.
I think 164 is a simple “accept”, but maybe Jay knows more?
Thanks
Graham
Thanks, Graham!
Note that I already have CIDs 40, 89, 137, 164, 178, and 224 assigned to Jay. Can you guys coordinate on any proposed resolution, please?
Thanks. Mark
Hi Mark,
I would be willing to look at following CIDs
2,3,4,5,7,21,22,23,25,37,40,49,51,81,89,114,128,135,137,140,148,149,164,168,169,178,193,196,197,198,207,208,224,240,214.
I will do my best to do these in a timely manner. Many require decision on the Status field.
Graham
All,
I have uploaded a slight update to the TGbh comment tracking spreadsheet, here:
https://mentor.ieee.org/802.11/dcn/23/11-23-1152-02-00bh-ieee-802-11bh-lb274-comments.xlsx
This update:
-
Assigned some CIDs to Jay Yang.
-
Marked some as "Submission Required" if the Proposed Resolution will need more specifics.
-
Marked a few Editorial ones "Technial" in the Notes, as they seemed like they needed TG review/approval that they are technically correct changes.
Talk to you all, tomorrow morning! Please be considering volunteering as Assignee for some CIDs.
Mark
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1