Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/15/11-15-1010-08-000m-revmc-sb0-stephens-resolutions-part-2.doc updated



--- 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.

 

6252

616.46

8.3.2.2.2

There is no direct normative constraint on the max MPDU size for DMG, just on the max MSDU/A-MSDU size (7920/7935)

Delete "and 7995 octets for DMG STAs" at the referenced location

MAC

 

 

From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Sunday, September 13, 2015 10:58 PM
To: Payam Torab Jahromi; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/15/11-15-1010-08-000m-revmc-sb0-stephens-resolutions-part-2.doc updated

 

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]
Sent: 14 September 2015 06:20
To: Mark Rison; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/15/11-15-1010-08-000m-revmc-sb0-stephens-resolutions-part-2.doc updated

 

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
Sent: Friday, September 11, 2015 7:15 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/15/11-15-1010-08-000m-revmc-sb0-stephens-resolutions-part-2.doc updated

 

--- 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
Sent: 10 September 2015 05:01
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/15/11-15-1010-08-000m-revmc-sb0-stephens-resolutions-part-2.doc updated

 

--- 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)
Tel: +1 (971) 330 6025 (mobile)
ç please note new number

 

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

 

_______________________________________________________________________________

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 _______________________________________________________________________________