| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Good point; I personally prefer to keep DMG as is (A-MSDU limit explicit, MPDU limit implicit), which means agreement with your proposed resolution. I think group
can discuss and decide this afternoon.
From: Mark
Rison [mailto:m.rison@xxxxxxxxxxx] Hello Payam, I agree with your comment that there is no normative constraint on DMG MPDU size in the current text; although we practically have one driven by the maximum A-MSDU
size. Resolution is to formalize MPDU maximum size in the table similar to other PHYs and drop it from the unrelated NOTE. Except that no PHY currently has both an explicit normative constraint on the A-MSDU size and an explicit normative constraint on the MPDU size. Currently it's either: - A-MSDU limit explicit and MPDU limit implicit (everything but VHT, including DMG, i.e. "practically
have one driven by the maximum A-MSDU size"), or - MPDU limit explicit and A-MSDU limit implicit (VHT) Are you saying that DMG should have both an explicit normative constraint on the A-MSDU size and an explicit normative constraint on the MPDU size (i.e. a third pattern, not "similar to other PHYs")?
Presumably you'd have to satisfy both (would this need at least a NOTE?)? 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: Payam Torab Jahromi [mailto:ptorab@xxxxxxxxxxxx]
Hi Mark – - CID 6252: I'm confused by the apparent contradiction between Payam's "I agree with the comment" that there is no direct normative constraint on the max MPDU size for DMG, and the resolution, which adds a direct normative constraint on the max MPDU size for DMG I agree with your comment that there is no normative constraint on DMG MPDU size in the current text; although we practically have one driven by the maximum A-MSDU
size. Resolution is to formalize MPDU maximum size in the table similar to other PHYs and drop it from the unrelated NOTE. Payam From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Mark Rison --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Thanks for this, Adrian. - CID 6235: I'm happy to take this one - CID 6252: I'm confused by the apparent contradiction between Payam's "I agree with the comment" that there is no direct normative constraint on the max MPDU size for DMG, and the resolution, which adds a direct normative constraint on the max MPDU size for DMG - CID 6343: it may be the case that at present all Action No Acks carry information such as beamforming that is of time critical but transient value, but this is not a requirement of the frame subtype per se. If we want to say that this is the case for <all the current ANA flavours (because they are all time-critical)>, and so they don't need a MICE (or AMPEE), fine, but we should in principle allow these in ANAs - CIDs 6057 and 6335-6339: we describe the exact contents and order for all other frames; there is no justification to allow DMG to be sloppy about this (I don't think it is clear what is "necessary for correct operation or assists scanning"). I vote for "want the elements listed" in the SP - CID 5955: I disagree with the suggestion that only (T)VHT STAs can (usefully) do OMN. I think non-VHT HT STAs can too, for example - CID 6226: if we decide to do 2 (add a new Extended Request element), we need to somehow indicate how this will interwork with existing devices (which won't understand this). At the moment we have text like "If there was a Request element in the Probe Request frame, then: [respond to the request]". If we add parallel "If there was an Extended Request element in the Probe Request frame, then: [respond to the extended request]" there would need to be a NOTE to say that devices compliant with 802.11-2012 and earlier might not in fact respond to the extended request - CID 6068: there is one instance of "This string is not null terminated." in Clause 8 for an UTF-8 string, which should be added to the general statement. Also, at 968.2 there is "“ES_ALERT” is treated as a sequence of ASCII-encoded octets without a terminating null" which should just become "“ES_ALERT” is an ASCII string" and in Clause 11 there are 5 instances of "terminating null", which should be simplified, after adding similar interpretation text in a new Conventions subclause in Clause 11 - CID 6470: paging Graham SMITH! - CID 5027: missing the canonical "and is not present otherwise". The original mistake was to get rid of the "if and only if"s. I should have spoken up more strongly then. However, now that we have done that, we have fallen back to saying that we should always spell it out, i.e. set to 1 if $blah, and to 0 otherwise. See also CID 6198 - CID 6669: the answer is: because they're merged for non-HT duplicate PPDUs (middle case), and otherwise it suggests there's a subtle difference - CID 6531: should "Annex" be uppercased? None of the "this clause"s in D4.0 seem to be, for example - CID 6396: are we saying that a Clause 16-19 PHY's PPDU is not a "non-HT PPDU"? I think we will enter a world of pain if an OFDM PPDU sent by an HT PHY is a non-HT PPDU, but when sent by an OFDM PHY is not a non-HT PPDU - CID 6297: giving explicit lists like this is a bad idea, because it is duplication, which is the leading cause of spec rot. If you don't like "in a frame" then leave it as "in certain frames" - CID 6525: both the commenter and the resolver are wrong to say there is no definition of "base channel". There is: "Channel on which the tunneled direct-link setup (TDLS) peer station (STA) is associated with an access point (AP)." However the question of whether a TDLS "off-channel" can overlap with secondary channels of the base channel stands - CID 6565: please pull; I am working on resolutions for the CS zoo comments which will encompass this - CID 6433: I agree with the strawman - CID 6560: I vote for change - CIDs 6802, 6803: happy to take these - CID 6789: I think the "ISO -1"s and "ISO -2"s are in fact supposed to be "ISO 3166-1"s and "ISO 3166-2"s. BTW, I note the former is in Clause 2 and Subclause 3.1 but the latter isn't. Note also "ISO/IEC -1" and "ISO.-2" in the MIB. And "14977 : 1996" in Annex G. And "ISO/IEC 7498- 1: 1994" has two spurious spaces - CID 6787: I think the two pairs of parens at 2203.34 should be deleted, as they are ambiguous (has the multiplication been performed or not?). Also, I think the "Octets" should be "LENGTH<prime>" - CID 6737: the point of the comment is that FIPS PUB documents are immutable, e.g. there will be no version of FIPS PUB 197 other than the one dated 2001-11-26. Hence we should just refer to it as "FIPS PUB 197" not "FIPS PUB 197-2001", and ditto "FIPS PUB 180-3" (I take no position on whether we should update this to "FIPS PUB 180-4") 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: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Stephens, Adrian P --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Dear TGmc participants, I have updated my document
https://mentor.ieee.org/802.11/dcn/15/11-15-1010-08-000m-revmc-sb0-stephens-resolutions-part-2.doc to address comments from Mark Rison. I’ve also been working with Payam and Carlos C on some of the TGad-related comments. Updated Resolutions are tagged “R8”. Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office) ---------------------------------------------- _______________________________________________________________________________
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 _______________________________________________________________________________
_______________________________________________________________________________
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 _______________________________________________________________________________
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 _______________________________________________________________________________ |