| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
1.7.17 CID 6226 and CID 5070
1.7.17.1 These CIDs have a fixe that is included in Matthew Fischer’s proposal, but these CIDs were not referenced, and some word smithing and some added text that needs to be created to allow for the Element to be included.
1.7.17.2 ACTION ITEM #1: - All BRC members need to review proposal prior to discussion.
1.7.19 CID 5141 (MAC)
1.7.19.1 Final review
1.7.19.2 ACTION ITEM #2 – Mark RISON and Mark HAMILTON to review, if there is any controversy, we can reject and move one, but if the resolution is reasonable we can complete it.
1.8.15 CID 6374 (MAC)
1.8.15.1 Assign to Carlos Cordiero
1.8.15.2 If a resolution is not coming this week we may reject
1.8.15.3 Mark RISON has a proposed change to make the rules for non-DMG and DMG the same.
1.8.15.4 ACTION ITEM #3: Mark RISON to check with Carlos and see if the proposed change would be acceptable.
1.8.17 CID 5035 (MAC)
1.8.17.1 Review comment
1.8.17.2 Propose to assign to Carlos.
1.8.17.3
ACTION ITEM #4: – Adrian STEPHENS
to check with Carlos for a proposed
1.8.20 CID 5039 (MAC)
1.8.20.1 Return to review if the changes in CID 6583 made enough changes to address CID 5039.
1.8.20.2 Concern on what the value “0” means – is it valid? Is it a zero offset?
1.8.20.3 If zero is valid, how to phrase it? – just delete the cited sentence.
1.8.20.4 Proposed Draft Resolution: Revised – Delete the cited sentence
1.8.20.5 ACTION ITEM #5: Mark Hamilton to see if Carlos is agreeable, if so, then we will use the draft resolution.
2.6.3 CID 5145 (MAC)
2.6.3.1 Review Comment
2.6.3.2 Discussion from the Doc: “MCCA enabled mesh STAs use Management frames to make reservations for transmissions. …. The MCCAOP owner and the MCCAOP responders advertise this MCCAOP reservation to their neighbors via an MCCAOP advertisement. The MCCA enabled neighbor mesh STAs that could cause interference to transmissions during these reserved time periods, or that would experience interference from them, shall not transmit during these reserved time periods.”
The intent of the text is clear, it referes to mesh STAs that would interfere if they transmitted, i.e. they are close enough that tif they transmitted at the same time as their neighbour, they would mutiually block each other. The underlying “shall” is that neighbour STAs shall not transmit during MCCAOPs between neighbors.
As the commenter found this confusing I suppose we should make it clearer.
2.6.3.3 Discussion on what a neighbour vs peer
2.6.3.4 “That could cause interference” is part of the condition rather than a constraint.
2.6.3.5 Question on how do you know if you are interfering…the proposed change basically says you are always interfering, so don’t transmit, but that is not quite what is thought correct.
2.6.3.6 ACTION ITEM #6: Graham to contact Guido to see about this MESH issue.
3.5.2 CID 5127 (MAC)
3.5.2.1 Review Rejection Reason from prior to the break
3.5.2.2 Review discussion on the rejection in 11-15/1249r2.
3.5.2.3 Proposed Resolution: Reject; The octets that are stripped and re-inserted are described in 6.3.26.2
3.5.2.4 ACTION ITEM #7: Graham and Mark H to craft the wording that is responsive and bring back later.
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________