Hi Mark,
I am ordering in the order I received the request. We can reorder at the beginning of the call to accommodate your request.
Regards;
Osama.
From: ***** 802.11 REVm - Revision Maintainance List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Mark Rison
Sent: Thursday, April 26, 2018 5:23 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] REVmd update to MAC ad hoc comment spreadsheet
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
- CID 1391. The new 10.25.3 says nothing about the promised Ack frames
("Once the block ack exchange has been set up, Data and Ack frames are
transferred using the procedure described in 10.25.3(#57).")
GS – That was not the 1391 comment. The comment was what does “sent under block ack policy’ mean? This was answered and sorted out.
CID 1308 (same document 0672r1) put 10.25.3 back in as originally agreed in D0.1. This, I think, answers your question.
Hm, OK, will raise on D2.0 then!
- CID 1347. The point has been missed. The proposed change aligns
DCF with EDCA (and presumably with what DCF implementations already
do)
GS – I spent a lot of time on this one and went through the steps as defined for EDCA. EDCA is basically the same backoff scheme as DCF but uses AIFSN x Slottime in place of DIFS. DCF uses DIFS
when it know the duration of the received external packet, and EIFS when it does not (e.g. FCS error). The condition a) in EDCA corresponds to the DCF case where DIFS is used, with DIFS replaced with AIFSN x Slottime. Condition b) corresponds to the case
where EIFS is used because, for example, the FCS failed. Hence EDCA and DCF are aligned.
OK, so yes, the point has been missed. Can we pull this until I get
an opportunity to go through it (probably best in person)?
- CID 1356. "data or management frames" should be "Data or Management frames"
GS – I don’t know, but I assume the editor will correct.
I am not convinced the Editor has the power to make such changes unless
specifically motioned to do so. Let's fix it now.
- CID 1356. Why is "If dot11RTSThreshold is 0, an RTS/CTS exchange shall precede all frame exchanges including
an individually addressed data or management frame"
needed? This is covered by the previous para's "A STA using the DCF shall use an RTS/CTS preceding a frame
exchange including an individually addressed data or management frame when the length of the PSDU is greater than the length threshold indicated by dot11RTSThreshold." (except for the
"using the DCF", which
should either be deleted or replaced with "using the DCF or EDCA")
GS – We felt that a value of 0 is a special case because it is a “shall” and should be spelt out. We did clarify it I feel.
Again, "use RTS/CTS if PSDU_Len > dot11RTSThreshold" covers
"use RTS/CTS if dot11RTSThreshold == 0". At most it should be a NOTE.
And the "using the DCF" bit should be addressed too.
- CID 1356. "A STA may also use an RTS/CTS exchange for individually addressed
frames when it is necessary to distribute the NAV or when it is necessary to establish protection (see 10.27 (Protection mechanisms)).
A STA may also use an RTS/CTS exchange for other purposes.
" would be nicer as "A STA may also use an RTS/CTS exchange for individually addressed frames when it is necessary to
distribute the NAV, or when it is necessary to establish protection (see 10.27 (Protection mechanisms)), or for other purposes."
GS – Maybe, but I made the minimum changes and followed the commenter’s proposal.
No, the commenter said to delete the last two sentences of the first para.
You kept the first one of the two.
- CID 1358. Is the NOTE still appropriate under the new reduced para,
or should it be moved to 10.3.5 or deleted?
GS – I think it is OK here but agree it could go into 10.3.5. But that’s a separate comment.
No, it's part of this comment, since it results from the proposed
resolution of moving text to 10.3.5.
- CID 1398. I don't think reference should be made to
"or the STA Channel Width field in the HT Operation element". NCW
is at its core about non-AP STAs changing their operating width.
An AP always has the option of fiddling with the HT Operation, but
that's a different thing, and is an option whether or not
the peers support OMN
[MAH] OK. I can live without the added phrase. The net result will change the CID to ACCEPTED. We can discussion on the call, and see if there is any objection.
OK.
- CID 1469, 1477. I'd like these pulled for now for more time to consider
- CID 1382. For dot11BSSTransitionActivated to be true, logically,
dot11BSSTransitionImplemented must also be true, yes, but the spec
should not (and does not) rely on such inferences (e.g. in 11.25.2
"If dot11SCSActivated is true, dot11SCSImplemented shall be true.")
[MAH] This whole mess of *Activated and *Implemented is being discussed ad nauseum in ARC, and all agreement is that both attributes should not be used for the same feature. While we have lots of examples of other
places where the duality is ignored (granting you that you have found one where it is handled cleanly), at this point, my suggestion is to change the surrounding text, to simply remove the *Implemented version completely. Thus, a new proposed resolution:
REVISED.
At 2170.37, delete the sentence, “A STA that implements BSS transition management has dot11BSSTransitionImplemented equal to true.”
At 2170.39 ½, change “dot11BSSTransitionImplemented” to “dot11BSSTransitionActivated”.
And delete dot11BSSTransitionImplemented from C.3?
(And delete dot11FastBSSTransitionImplemented from C.3? It's not used
anywhere outside C.3.)
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From: ***** 802.11 REVm - Revision Maintainance List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Mark Hamilton
Sent: 16 April 2018 22:44
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] REVmd update to MAC ad hoc comment spreadsheet
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
All,
I have uploaded an updated REVmd MAC ad hoc comment spreadsheet, here:
https://mentor.ieee.org/802.11/dcn/17/11-17-0927-16-000m-revmd-mac-comments.xls
This includes resolutions that will be considered for MOTION at the Warsaw meeting, for CIDs: 1391, 1299, 1308, 1313, 1347, 1356, 1358, 1381, 1147, 1390, 1554, 1392, 1398, 1425, 1504, 1469, 1528, 1477, and 1382, as discussed on recent teleconferences
or at the Fort Lauderdate ad hoc session.
I am still looking for volunteers to look at comments on MAC-level material that is PHY-specific, for DMG and S1G support. If anyone is willing to contribute in these areas, please let me know.
Thanks. Mark
To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
|
|
|
|
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1