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

[STDS-802-11-TGM] Fwd: [STDS-802-11] 2020 January - March TGmd CRC teleconference and ad-hoc agenda document posted

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---


---------- Forwarded message ---------
From: Mark Rison <m.rison@xxxxxxxxxxx>
Date: Thu, Jan 30, 2020 at 5:30 PM
Subject: RE: [STDS-802-11] 2020 January - March TGmd CRC teleconference and ad-hoc agenda document posted
To: M Montemurro (montemurro.michael@xxxxxxxxx) <montemurro.michael@xxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>


Hello Mike,

 

> Mike Montemurro, TGmd Vice Chair, will chair the call since I will be traveling.

 

Ah.  Unfortunately this term my younger daughter is doing gymnastics club

on Friday afternoons, so I will be in the middle of the school run during

the TGm teleconf.  I will try to listen in while driving, but I will

not be able to speak while doing so; I will only be able to do so when

I am parked up (probably about 15:30-16:00 and maybe about 16:35 onwards,

UK time).

 

I have done my best to provide all my input to Edward's and Graham's

submissions in advance, so please be kind enough to put this to the group

(where it was not accepted by Graham).  I attach the emails to Graham

and (to Dorothy because I cannot email Edward privately) regarding

Edward's resolutions (I also emailed some comments on 19/2163r7 to

the reflector, which I think Edward mostly addressed in r8, but see

below).

 

In addition, regarding Edward's CID 4235 resolution in 20/0235r0 (which

in general I think are preferable to Graham's in 20/0233r2, where they

overlap), I note the current wordings re 25.3.10 xrefs are:

 

A CMMG STA shall transmit an RTS frame carried in CMMG or CMMG duplicate format (see 25.3.10

transmitted (#2037)in duplicate format as defined in 25.3.10

transmitted (#2037)in duplicate format as defined in 25.3.10

transmitted (#2037)in duplicate format as defined in 25.3.10 [three NOTEs essentially saying the same thing…]

transmitted in duplicate format as defined in 25.3.10

symbols are duplicated as described in 25.3.10

symbols are duplicated as described in 25.3.10

symbols are transmitted using duplication style as described in 25.3.10 [this is what the comment is about]

signal is resampled as  defined in 25.3.10

 

So I'm not sure Edward's

 

symbols are duplicated as described in 25.3.10 and then transmitted

 

is consistent.  I think just

 

symbols are duplicated as described in 25.3.10

 

would be more consistent, and the triplicated NOTE should be detriplicated too.

 

And regarding CID 4073/4074 in 19/2163r8 note a typo in

"initiatior" in the proposed resolution (the new text).

Also I don't think the replacement at 2064.24 should be made as shown.

(only the one at 2064.25).  The 2064.24 one should be

just "following"->"next".

 

And regarding CID 4261 in the same doc, I'm not persuaded by the

"The BIP Additional Authentication Data (AAD) shall be constructed from the MPDU header."

It's just "is constructed" at 2604.23, which seems correct to me

as it's just a statement of fact.

 

And regarding CID 4125/4126 in the same doc, it still refers to r7

for the resolution.

 

I also attach a couple of other Chair requests.

 

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: Dorothy Stanley <dstanley1389@xxxxxxxxx>
Sent: 30 January 2020 19:34
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] 2020 January - March TGmd CRC teleconference and ad-hoc agenda document posted

 

--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

 

An updated agenda document for the Friday 2020-01-31 TGmd CRC 10am Eastern teleconference is now posted, see

 

Adjustments as needed will be made on the call, during discussion of the agenda.

 

Mike Montemurro, TGmd Vice Chair, will chair the call since I will be traveling.

 

Thanks,

 

Dorothy

 

----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, dstanley@xxxxxxxx
Hewlett Packard Enterprise
dorothy.stanley@xxxxxxx
dstanley1389@xxxxxxxxx
+1 630-363-1389

 

 

On Fri, Jan 24, 2020 at 7:43 AM Dorothy Stanley <dstanley1389@xxxxxxxxx> wrote:

All,

 

 

which contains the draft agenda document for the upcoming TGmd CRC teleconferences and February ad-hoc meeting.

Teleconferences: January 31, February 7, 14 and March 13th at 10am Eastern (2 hours)

Adhoc meeting Sunrise Florida February 18-19-20

 

The proposed comment resolution topics for the first 2 teleconferences are copied below.

These are subject to change; please let me know of any additional agenda topics.

 

Thanks,

 

Dorothy

=============

See the dial-in instructions: Webex meeting: Join Meeting number: 796 002 752 Meeting password: wireless Join by phone: +1-510-338-9438 USA Toll +44-20-3198-8144 UK Toll Access code: 796 002 752

more details»  copy to my calendar

  1. 2020-01-31
    1. Edward Au - https://mentor.ieee.org/802.11/dcn/20/11-20-0235-00-000m-resolution-for-cmmg-related-comments.docx 25 mins
    2. Graham SMITH - https://mentor.ieee.org/802.11/dcn/20/11-20-0233-00-000m-cids-for-graham-from-mike.docx 25 mins
    3. Menzo Wentink - https://mentor.ieee.org/802.11/dcn/20/11-20-0150-05-000m-assorted-crs-revmd-draft-3-0.docx  60 mins
  1. 2020-02-07
    1. GEN CIDs – Jon ROSDAHL – 60 mins
    2. Menzo Wentink - https://mentor.ieee.org/802.11/dcn/20/11-20-0150-05-000m-assorted-crs-revmd-draft-3-0.docx  60 mins

Teleconferences are subject to applicable policies and procedures, see below.

 

•       IEEE Code of Ethics

–       https://www.ieee.org/about/corporate/governance/p7-8.html  

•       IEEE Standards Association (IEEE-SA) Affiliation FAQ

–       https://standards.ieee.org/faqs/affiliation.html

•       Antitrust and Competition Policy

–       https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/antitrust.pdf

•       IEEE-SA Patent Policy

–       http://standards.ieee.org/develop/policies/bylaws/sect6-7.html  

–       https://standards.ieee.org/about/sasb/patcom/

 •       IEEE 802 Working Group Policies &Procedures (29 Jul 2016)

–       http://www.ieee802.org/PNP/approved/IEEE_802_WG_PandP_v19.pdf

•       IEEE 802 LMSC Chair's Guidelines (Approved 13 Jul 2018)

–       https://mentor.ieee.org/802-ec/dcn/17/ec-17-0120-27-0PNP-ieee-802-lmsc-chairs-guidelines.pdf

•       Participation in IEEE 802 Meetings

–       https://mentor.ieee.org/802-ec/dcn/16/ec-16-0180-05-00EC-ieee-802-participation-slide.pptx

•       IEEE 802.11 WG OM: (Approved 10 Nov 2017)

–       https://mentor.ieee.org/802.11/dcn/14/11-14-0629-22-0000-802-11-operations-manual.docx

----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, dstanley@xxxxxxxx
Hewlett Packard Enterprise
dorothy.stanley@xxxxxxx
dstanley1389@xxxxxxxxx
+1 630-363-1389

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&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

--- Begin Message --- 
Hello Dorothy,

Should I be unable to speak up during the presentation of this on Friday,
would you be kind enough to put the following across?

I don't understand "it may support MCS 4 – 8 for SC MIMO transmission"
in the discussion.  As far as I can tell from e.g.
Table 25-39—CMMG SC MCSs for optional 540 MHz, Nss=2 (Optional)
it can support it for MCS 1-3 too.

Similarly I don't understand the proposed change to (note typos in first two nouns too)
"Transmittion and receptopn of CMMG SC mode PPDUs with MIMO in MCSs 4 to 8 may be supported"
It may be supported for other MCSes too.  I think the proposed change should
just be ACCEPTED, so the sentence ends up being
"Transmission and reception of CMMG SC mode PPDUs with MIMO may be supported.".

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

> -----Original Message-----
> From: ***** 802.11 REVm - Revision Maintainance List ***** <STDS-802-11-TGM@xxxxxxxx> On Behalf Of
> Edward Au
> Sent: 24 January 2020 09:02
> To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> Subject: [STDS-802-11-TGM] Proposed resolution of 5 CMMG related CIDs posted
>
> --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
>
> Hi Dorothy, Mike, and all.
>
> Proposed resolution of 5 CMMG related CIDs (belonging to PHY ad-hoc)
> is posted at:
> https://mentor.ieee.org/802.11/dcn/20/11-20-0235-00-000m-resolution-for-cmmg-related-comments.docx
>
> The CIDs include 4222, 4223, 4225, 4235, and 4237.
>
> Regards,
> Edward
>
> _______________________________________________________________________________
>
> 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: https://protect2.fireeye.com/url?k=ca5c1d36-97caa441-ca5d9679-
> 0cc47a312ab0-4759d56739efed29&u=http://www.ieee802.org/11/Email_Subscribe.html
> _______________________________________________________________________________

--- End Message ---
--- Begin Message ---

Ah, and could you ask for CMMG SMEs to look at the following, please?

All the CMMG people I can find are from Huawei.

 

4217

No behaviour is associated with the Antenna Pattern Reciprocity field in the CMMG Capabilities Info field

In Figure 9-754--CMMG Capabilities Info field format change "Antenna Pattern Reciprocity" to "Reserved" and delete the "Antenna Pattern Reciprocity" row in Table 9-313--Subfields of the CMMG Capabilities Info field format

4218

No behaviour is associated with the Antenna Pattern Reciprocity field in the CMMG Capabilities Info field

Add behaviour modelled on that given for DMG in 10.42.6.4.4 Antenna configuration setting during a beam refinement transaction

4250

"The actual
duration of the time the STA stays in the listening mode is limited by the aCMMGPPMinListeningTime
parameter." -- no such parameter

Delete the cited sentence

 

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

 

 

> -----Original Message-----

> From: Mark Rison

> Sent: 26 January 2020 18:08

> To: Dorothy Stanley <dstanley1389@xxxxxxxxx> (dstanley1389@xxxxxxxxx) <dstanley1389@xxxxxxxxx>

> Subject: RE: [STDS-802-11-TGM] Proposed resolution of 5 CMMG related CIDs posted

>

> Hello Dorothy,

>

> Should I be unable to speak up during the presentation of this on Friday,

> would you be kind enough to put the following across?

>

> I don't understand "it may support MCS 4 – 8 for SC MIMO transmission"

> in the discussion.  As far as I can tell from e.g.

> Table 25-39—CMMG SC MCSs for optional 540 MHz, Nss=2 (Optional)

> it can support it for MCS 1-3 too.

>

> Similarly I don't understand the proposed change to (note typos in first two nouns too)

> "Transmittion and receptopn of CMMG SC mode PPDUs with MIMO in MCSs 4 to 8 may be supported"

> It may be supported for other MCSes too.  I think the proposed change should

> just be ACCEPTED, so the sentence ends up being

> "Transmission and reception of CMMG SC mode PPDUs with MIMO may be supported.".

>

> 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

>

> > -----Original Message-----

> > From: ***** 802.11 REVm - Revision Maintainance List ***** <STDS-802-11-TGM@xxxxxxxx> On Behalf Of

> > Edward Au

> > Sent: 24 January 2020 09:02

> > To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx

> > Subject: [STDS-802-11-TGM] Proposed resolution of 5 CMMG related CIDs posted

> >

> > --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

> >

> > Hi Dorothy, Mike, and all.

> >

> > Proposed resolution of 5 CMMG related CIDs (belonging to PHY ad-hoc)

> > is posted at:

> > https://mentor.ieee.org/802.11/dcn/20/11-20-0235-00-000m-resolution-for-cmmg-related-comments.docx

> >

> > The CIDs include 4222, 4223, 4225, 4235, and 4237.

> >

> > Regards,

> > Edward

> >

> > _______________________________________________________________________________

> >

> > 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: https://protect2.fireeye.com/url?k=ca5c1d36-97caa441-ca5d9679-

> > 0cc47a312ab0-4759d56739efed29&u=http://www.ieee802.org/11/Email_Subscribe.html

> > _______________________________________________________________________________


--- End Message ---
--- Begin Message ---

Hello Dorothy,

 

Could you also schedule some time to run through the following to see

whether there are any objections to just ACCEPTing the following, please?

Perhaps Mike/other Mark could step through them, and then in the last

20 minutes I could provide input for those where there was some opposition

to just ACCEPTING (those are the minutes I am most likely to be able to

do tx).

 

Think these are "PHY" comments for Mike:

 

CID

Comment

Proposed Change

4286

It is not clear what the difference between 802.1X authentication and EAP authentication is.  Jouni said "In the context of IEEE 802.11 standard, 802.1X authentication is really referring to EAP authentication, so these would also be interchangeable here"

Change "EAP authentication" to "802.1X authentication" throughout, except in the definition of IEEE 802.1X authentication and Extensible Authentication Protocol (EAP) reauthentication protocol (EAP-RP) and in the arrow label in Figure 4-31--IEEE 802.1X EAP authentication and Figure 4-37--Example using IEEE 802.1X authentication.  Delete "EAP" in the caption of Figure 4-31--IEEE 802.1X EAP authentication and in Table 9-198--Transition and Transition Query reasons and in last para of 12.6.10.3 Cached PMKSAs and RSNA key management.  Change "Successful completion of EAP authentication over IEEE Std 802.1X" to "Successful completion of IEEE Std 802.1X authentication" and "full EAP authentication via IEEE 802.1X authentication." to "full IEEE 802.1X authentication."

4301

"When MAX-ACCESS is read-only, the MIB attribute value may be updated by the PLME and read from the
MIB attribute by management entities. When MAX-ACCESS is read-write, the MIB attribute may be read
and written by management entities but shall not be updated by the PLME." has some odd numerology; specifically it only appears for PHYs in odd-numbered clauses above 20

Add the cited text to the end of the PHY MIB subclause of the other PHYs

4314

"gives the current message number" (4x) -- the "message number" is not defined

Change "message number" to "TSC or PN" in each case

4341

There are still a lot of "MCS"es.  These need to be qualified with the PHY, to avoid confusion, except in generic contexts (e.g. 10.6.6.5.2 Selection of a rate or MCS)

Throughout, change "S1G MCS" to "S1G-MCS", "CMMG MCS" to "CMMG-MCS"

4394

There are ~11 instances of "current ESS", but this is not defined

As it says in the comment

4395

There are ~11 instances of "current ESS", but this is not defined

Change each to "ESS of which the STA is a member" (if you accept STAs can be members of an ESS, not just of a BSS)

4423

How does a "duration time" or "time duration" differ from a "duration"

Change "duration time" and "time duration" to "duration" throughout

4513

40 MHz non-HT duplicate and HT-MCS 32 will both achieve 3 dB power gain; typically, non-HT will have better PER performance because the L-LTF density [xxft]

Deprecate HT-MCS 32

4721

The whole "field" v. "subfield" thing is just a big inconsistent mess (e.g. in 9.4.2.171 Reduced Neighbor Report element some things in the Neighbor AP Information field are fields and some are subfields, and the TBTT Information Set [sub!]field contains one or more TBTT Information fields).  There is no value in trying to make the distinction, because (a) the distinction is not made reliably and (b) it's not possible to make the distinction, because some things are subfields of X but are also the field that contains subfield Y

Change "subfield" to "field" throughout

4740

Some of the ResultCodes in the SAP have underscores (e.g. JOIN_FAILURE_TIMEOUT, NOT_SUPPORTED) some not (e.g. AUTH FAILURE TIMEOUT, ANTI-CLOGGING
TOKEN REQUIRED).  There is no justification for this inconsistency.  Underscores make it easier to find result codes, so are preferable

Change "AUTH FAILURE TIMEOUT" to "AUTH FAILURE_TIMEOUT" throughout the document

 

Think these are MAC comments for other Mark (other Mark has thoughts on most of these, but

I'll let him put them forward during the meeting):

 

CID

Comment

Proposed Change

4194

Subfields should be reserved, not set to 0, to allow for future extension

In 9.4.2.226 Enhanced Beam Tracking element change " Otherwise, the Peer Tx_Sector ID field is set to 0. " to " Otherwise, the Peer Tx_Sector ID field is reserved. " and " Otherwise,  the  Peer  Tx  DMG  Antenna  ID  field  is  set  to
0." to " Otherwise,  the  Peer  Tx  DMG  Antenna  ID  field  is reserved."

4212

"The  Group  Data  Cipher  Suite  field  contains  the  cipher  suite  selector  used  by  the  BSS  to  protect  group
addressed frames." -- only Data frames

Change the cited text to "The  Group  Data  Cipher  Suite  field  contains  the  cipher  suite  selector  used  in the  BSS  to  protect  group
addressed Data frames." (note in not by)

4229

"A STA is not required to include all mandatory rates in its operational rate set, and a STA starting a BSS is
not required to include all mandatory rates in the basic rate set." -- there should be equivalent statements for MCSes

Change the cited text to "A STA is not required to include all mandatory rates/MCSes in its operational rate/MCS set, and a STA starting a BSS is
not required to include all mandatory rates/MCSs in the basic rate/MCS set."

4259

"QoS Data frame" is ambiguous.  It could mean Type = Data, Subtype has b7 set, or it could mean Type = Data, Subtype = QoS Data

After "QoS CF-Poll frame refers specifically to the QoS CF-Poll frame, subtype 1110." add "Similarly, QoS Data frame refers specifically to the QoS Data frame, subtype 1000.".  Also delete the comma in " whereas," in 3.2 and "Whereas " in 9.2.2

4267

"The  TXOP  Duration  Requested  subfield  is  present  in  QoS  Data  frames  sent  by  STAs  associated  in
a nonmesh BSS with bit 4 of the QoS Control field equal to 0." -- only non-AP STAs.  Even if this is fixed, it just duplicates Table 9-10--QoS Control field

Delete the cited sentence

4269

"before  the  ProbeTimer  reaches
MinChannelTime" -- there is no ProbeTimer

Change the cited text to "before the ProbeDelay time reaches MinChannelTime"

4287

"The set has a maximum range of 2^n for at least one n, where 1 <= n <= 46." -- the "at least one n" is not clear

Delete the " for at least one n"

4292

Referring to fields in binary is not clear as to the ordering of bits.

Delete "The GCR Mode subfield is 10 when the BlockAck
frame is sent in response to a GCR BlockAckReq frame, 01 when the BlockAck frame is sent in response to
a GLK-GCR BlockAckReq, and 00 otherwise." (this just duplicates the table above anyway)

4361

There should not be reason codes for situations that should never arise with compliant devices, since (a) the spec is about compliant devices and (b) then there would be no end of possible reason codes

In Table 9-51--Reason codes make row 35 say "35", "Reserved" and nothing

4362

There should not be reason codes for situations that should never arise with compliant devices, since (a) the spec is about compliant devices and (b) then there would be no end of possible reason codes

In Table 9-51--Reason codes make row 35 say "35", "NONCOMPLIANT" and "Disassociated because STA is not compliant with IEEE Std 802-11"

4381

"The  responding  STA  should  transmit  Fine  Timing  Measurement  frames  with  the  format  and  bandwidth  it
indicated.
For the Fine Timing Measurement frames transmitted during the FTM session:
-- The responding STA shall not use a bandwidth wider than that indicated by the STA in the initial
Fine Timing Measurement frame.
-- The responding STA shall not use a VHT format if the STA indicated HT-mixed or non-HT format
in the initial Fine Timing Measurement frame.
-- The responding STA shall not use an HT format if the STA indicated non-HT format in the initial
Fine Timing Measurement frame." is not clear: which is "the STA".  And in first sentence should say where it indicated it (the iFTM frame)

Change to "The  responding  STA  should  transmit  Fine  Timing  Measurement  frames  with  the  format  and  bandwidth  it
indicated in the initial Fine Timing Measurement frame.
For the Fine Timing Measurement frames transmitted during the FTM session:
-- The responding STA shall not use a bandwidth wider than that it indicated in the initial
Fine Timing Measurement frame.
-- The responding STA shall not use a VHT format if it indicated HT-mixed or non-HT format
in the initial Fine Timing Measurement frame.
-- The responding STA shall not use an HT format if it indicated non-HT format in the initial
Fine Timing Measurement frame."

4393

It doesn't make sense to sometimes plonk "(no data)" after the frame name

Delete "(no data)" throughout except in Table 9-1--Valid type and subtype combinations

4400

Constructs of the form "may do X by doing Y" are ambiguous because the might mean "if you do X, then Y might happen" or "if you do X, then Y will happen"

In the referenced subclause change "A non-AP STA with dot11SolicitedPADActivated set to true (#2679)may invoke MAC privacy procedures by
setting  dot11MACPrivacyActivated  to  true" to "A non-AP STA with dot11SolicitedPADActivated set to true (#2679)may set  dot11MACPrivacyActivated  to  true"

4433

Table 10-22--Applicable HT protection mechanisms only goes up to 40 MHz non-HT dup.  However, it also applies to VHT through 10.27.5 Protection rules for VHT STAs ("A VHT STA is subject to all of the rules for HT STAs that apply to its operating band, except that a PPDU
with the TXECTOR FORMAT parameter set to VHT may be substituted for a PPDU with the TXVECTOR
FORMAT parameter set to HT_MF.").  Therefore it should also cover the use of 80/80+80/160 non-HT dup for RTS

In Table 10-22 change "40 MHz transmissions use non-HT duplicate frames defined in Clause 19 (High-throughput (HT) PHY
specification)" to "40 MHz, 80 MHz, 160 MHz and 80+80 MHz transmissions use non-HT duplicate frames defined in Clause 19 (High-throughput (HT) PHY
specification) and Clause 21"

4451

"When an AP supports DL-MU-MIMO, frames from a higher or lower priority AC may be included
in a VHT or S1G MU PPDU with the TXVECTOR parameter(#2639) NUM_USERS > 1 when
these frames do not increase the duration of the VHT or S1G MU PPDU beyond that required for the
transmissions  of  the  frames  of  the  primary  AC(#2426)." -- why the not increase duration constraint, given that the previous bullet does allow extension?  Maybe special-case for TXOP Limit 0, i.e. only in that case do not extend (since otherwise TXOP Limit is the limit, irrespective of content)?

Change to "When an AP supports DL-MU-MIMO, frames from a higher or lower priority AC may be included
in a VHT or S1G MU PPDU with the TXVECTOR parameter(#2639) NUM_USERS > 1 when
the TXOP limit for the primary AC is nonzero."

4471

"Indicates short GI support
for the reception of
PPDUs(#1362) transmitted
with the TXVECTOR
parameter(#2639)
CH_BANDWIDTH equal
to HT_CBW20"-- also VHT20, per "Support for short GI for the reception of PPDUs(#1362) with TXVECTOR parameter CH_BANDWIDTH
equal to CBW20 or CBW40 is indicated in the HT Capabilities Info field of the HT Capabilities element." in 9.4.2.157.2 VHT Capabilities Information field

Change the cited text at the referenced location to "Indicates short GI support
for the reception of
PPDUs(#1362) transmitted
with the TXVECTOR
parameter(#2639)
CH_BANDWIDTH equal
to HT_CBW20 or (for a VHT STA) CBW20".  Change cell below to "Indicates short GI support
for the reception of
PPDUs(#1362) transmitted
with the TXVECTOR
parameter(#2639)
CH_BANDWIDTH equal
to HT_CBW40 or (for a VHT STA) CBW40"

4480

"A STA that receives a Probe Request frame shall not respond if [...] c) The STA is a non-AP STA in an infrastructure BSS".  Such a STA does not respond due to the rules in a) above, which mean that only an AP, IBSS STA, mesh STA, DMG STA or PCP responds.  Hm, or maybe the "DMG STA" case allows this?  This needs to be clearer, then

Change "The STA is a non-AP STA in an infrastructure BSS" to "The STA is a non-AP STA in a DMG infrastructure BSS"

4505

We now have two Operating Mode Notification frames (9.6.22.4 and 9.6.29.3).  So which is intended when the spec talks of "the Operating Mode Notification frame"?

In 9.6.29.3 prepend "CMMG " to "Operating Mode Notification".  At the top of 11.41 add "In this subclause, references to an Operating Mode Notification frame or element should be understood as referring to a CMMG Operating Mode Notification frame or element, when transmitted or received by a CMMG STA."

4508

how used_time is adjusted (if at all) in the case of RD grant by the AP is not clear

After "Frame exchange sequences for Management frames are excluded from the used_time update." add "Any RD transmission granted by the AP is excluded from the used_time update."

4512

"This field is an integer in the range 0 to 3." -- well, duh, it's a 2-bit field, so it can't really be anything else, can it?

Delete the cited text, and also in Table 9-300--Subfields of the S1G Capabilities Information field and in C.3, and "This field is an integer in the range 0 to 7." in Table 9-271--Subfields of the VHT Capabilities Information field and in Table 9-314--Subfields of the A-MPDU Parameters field

4519

"An HT STA may retransmit unacknowledged MPDUs within the same TXOP or in a
subsequent  TXOP." -- this is true of non-HT QoS STAs (e.g. DMG, S1G) and duplication of the TXNAV recovery rules below

Delete the cited sentence

4542

"The Label field is a variable length(#183) field containing a text description of the URL." should be "The Label field is a variable length(#183) field containing a text description of the URL suitable for display on a user interface."

As it says in the comment

4552

" The  fields  following  the  QoS  Info  field  in the  EDCA  Parameter  Set  element  shall  be
included in all Beacon frames occurring within two (optionally more) delivery traffic indication map (DTIM)
periods following a change in AC parameters, which provides all STAs an opportunity to receive the updated
EDCA parameters." has two issues.  1) The fields following the QoS Info field in the EDCA Parameter Set element are not optional, so they are always included if the element is.  2) "(optionally more)" is unclear but appears to be saying it might only be after a million DTIM periods (i.e. it's as good as those "up to 50% off!" advertisements)

Change to " The  EDCA  Parameter  Set  element  shall  be
included in all Beacon frames occurring within two delivery traffic indication map (DTIM)
periods following a change in AC parameters, which provides all STAs an opportunity to receive the updated
EDCA parameters."

4556

"Note that, as for an EDCA TXOP, a multiple frame transmission is granted to an EDCAF, not to a STA, so that
the multiple frame transmission is permitted only for the transmission of a frame of the same AC as the frame
that was granted the EDCA TXOP, unless the EDCA TXOP obtained is used by an AP for a PSMP sequence
or a VHT (11ah)or S1G MU PPDU with the TXVECTOR parameter(#2639) NUM_USERS > 1. " -- there are now other cases where transmission of frames from multiple ACs is permitted

"Note that, as for an EDCA TXOP, a multiple frame transmission is granted to an EDCAF, not to a STA, so that
the multiple frame transmission is permitted only for the transmission of a frame of the same AC as the frame
that was granted the EDCA TXOP, except as specified in 10.23.2.7."

4560

"The Address 3 field of the Management frame is set and determined as follows:".  3) covers OCB and 4) covers infra, IBSS and MBSS, but what about e.g. PBSS and TDLS?

In 4) change "AP" to "AP or PCP" and in 3) after "true" add "or the STA is transmitting the Management frame to a peer TDLS STA"

4564

"Frame exchange sequences for Management frames [...] are excluded from the used_time update." -- this allows a STA to circumvent admission control by putting an Action No Ack in an A-MPDU together with a bunch of Data frames.

Change to "Frame exchange sequences that do not include any Data frames [...]"

4648

The need to qualify BU as DL BL only arises for 11ah; other STAs can only have BUs for DL anyway

In 11.2.3.5.1 change "downlink BUs to" to "BUs to a"

4687

Should not duplicate requirements already given elsewhere.  For ack policy, it's all in Table 9-13--Ack policy

Delete "A recipient STA shall not send any
frame as an immediate response to an F-MPDU with Block Ack ack policy. An originator STA may solicit
an immediate response following an F-MPDU by setting the ack policy of the eliciting F-MPDU to Implicit
BAR.(#1415)".  Delete "A STA shall not transmit an Ack or BlockAck frame in response to a QoS Data frame whose ack policy
is No Ack." in 10.3.2.11

4701

Are you sure it's called null in ASCII?  I thought it was called NUL

In 9.4.5.4 and 9.4.5.21 change "null" to "NUL"

4707

CID 2308 follow-up.  There are lots of rules for things like Acks, CTSes, PS-Polls, etc.  The limited extensions to Clauses 10 and 11 to cover the NDP CMAC PPDU flavours of these MPDUs cannot cover all the cases where they are used and the rules that apply in each case.  They have to inherit from the non-NDP-CMAC behaviours

At the end of 9.9.1 add "NDP CMAC frames are not MPDUs but NDPs, but they obey the rules for equivalent MPDUs, as shown in Table 9-539."  In Table 9-539 add a column "Equivalent MPDU"  and then for values 0 to 7 respectively say "CTS or CF-End", PS-Poll, Ack, "Ack to PS-Poll", BlockAck, Beamforming Report Poll, Action, Probe Request

 

 

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: Dorothy Stanley <dstanley1389@xxxxxxxxx>
Sent: 24 January 2020 15:44
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] 2020 January - March TGmd CRC teleconference and ad-hoc agenda document posted

 

--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

 

 

which contains the draft agenda document for the upcoming TGmd CRC teleconferences and February ad-hoc meeting.

Teleconferences: January 31, February 7, 14 and March 13th at 10am Eastern (2 hours)

Adhoc meeting Sunrise Florida February 18-19-20

 

The proposed comment resolution topics for the first 2 teleconferences are copied below.

These are subject to change; please let me know of any additional agenda topics.

 

Thanks,

 

Dorothy

=============

See the dial-in instructions: Webex meeting: Join Meeting number: 796 002 752 Meeting password: wireless Join by phone: +1-510-338-9438 USA Toll +44-20-3198-8144 UK Toll Access code: 796 002 752

more details»  copy to my calendar

  1. 2020-01-31
    1. Edward Au - https://mentor.ieee.org/802.11/dcn/20/11-20-0235-00-000m-resolution-for-cmmg-related-comments.docx 25 mins
    2. Graham SMITH - https://mentor.ieee.org/802.11/dcn/20/11-20-0233-00-000m-cids-for-graham-from-mike.docx 25 mins
    3. Menzo Wentink - https://mentor.ieee.org/802.11/dcn/20/11-20-0150-05-000m-assorted-crs-revmd-draft-3-0.docx  60 mins
  1. 2020-02-07
    1. GEN CIDs – Jon ROSDAHL – 60 mins
    2. Menzo Wentink - https://mentor.ieee.org/802.11/dcn/20/11-20-0150-05-000m-assorted-crs-revmd-draft-3-0.docx  60 mins

Teleconferences are subject to applicable policies and procedures, see below.

 

•       IEEE Code of Ethics

–       https://www.ieee.org/about/corporate/governance/p7-8.html  

•       IEEE Standards Association (IEEE-SA) Affiliation FAQ

–       https://standards.ieee.org/faqs/affiliation.html

•       Antitrust and Competition Policy

–       https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/antitrust.pdf

•       IEEE-SA Patent Policy

–       http://standards.ieee.org/develop/policies/bylaws/sect6-7.html  

–       https://standards.ieee.org/about/sasb/patcom/

 •       IEEE 802 Working Group Policies &Procedures (29 Jul 2016)

–       http://www.ieee802.org/PNP/approved/IEEE_802_WG_PandP_v19.pdf

•       IEEE 802 LMSC Chair's Guidelines (Approved 13 Jul 2018)

–       https://mentor.ieee.org/802-ec/dcn/17/ec-17-0120-27-0PNP-ieee-802-lmsc-chairs-guidelines.pdf

•       Participation in IEEE 802 Meetings

–       https://mentor.ieee.org/802-ec/dcn/16/ec-16-0180-05-00EC-ieee-802-participation-slide.pptx

•       IEEE 802.11 WG OM: (Approved 10 Nov 2017)

–       https://mentor.ieee.org/802.11/dcn/14/11-14-0629-22-0000-802-11-operations-manual.docx

----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, dstanley@xxxxxxxx
Hewlett Packard Enterprise
dorothy.stanley@xxxxxxx
dstanley1389@xxxxxxxxx
+1 630-363-1389

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1


--- End Message ---
--- Begin Message ---

Hello Dorothy,

 

This reminds me that some group direction is needed before I embark

on the following:

 

CID

Comment

Proposed Change

Locations

Emily’s response.

4483

The way Action fields are described is inconsistent regarding elements they contain.  Sometimes the table says Blah element, sometimes it says Blah.  Either is probably fine, but in the first case the cell needs to give a xref to where the element is defined, and in the second case there needs to be a line saying "The Blah field contains a Blah element (see 9.x.y.z)."

As it says in the comment

Cannot provide a list.  First decide the preferred format.  I think Payam was going to fix all this?

I don’t think Payam will fix this item. Assigned to Mark R.

4537

If first character of caption is a letter, it should be uppercase

Change "10.37 null data PPDU" to "10.37 Null data PPDU"

Cannot provide a list beyond the referenced subclause; need to eyeball all the captions (or if you can provide them to me in a text file I can grep)

Assigned to Mark R

4565

Why do some frame format figures in 9.3.1.x xxx frame format show the extent of the MAC header with arrows, and some not?

As it says in the comment

Cannot provide a list.  First decide the preferred format or define the rule for the presence/absence of the arrow

Assigned to Mark R.

4575

Is it BSSID of the AP or BSSID of the AP's BSS?

As it says in the comment

Need to first decide on the answer to the question

Assigned to Mark R.

4576

Just "BSSID" is often used for infraBSS, but for IBSS it's generally qualified as "BSSID of the IBSS" -- why?

As it says in the comment

Need to first decide on the answer to the question

Assigned to Mark R.

4588

Sometimes capability bits are "Supported" (e.g. "A-MPDU Supported"), sometimes "Support" (e.g. "BAT Support")

As it says in the comment

Cannot provide a list beyond the examples; if provided with list of capability field names I can do a grep

Assigned to Mark R.

4616

CID 2450 follow-up.  Shouldn't there be "Std" inside "IEEE 802", at least where not followed by ".11"?

As it says in the comment

Need to first decide on the answer to the question

Assigned to Mark R.

4618

"receive address" should be "received address" throughout, and "transmit address" should be "transmitter address".  Also "transmitting  STA  address  (TA),  and
receiving STA address (RA)" should be "transmiter address  (TA),  and
receiver address (RA)"

As it says in the comment

Trivial to search for the terms. Note typo in comment: should be "receiver" not "received"

Need group inputs on the direction.

4620

Sometimes it's "Anti-clogging Token", sometimes "Anti-Clogging Token".  Need to pick one (make decision about whether each component of a hyphenated construct is uppercased or not)

As it says in the comment

Need to first decide on the answer to the question

Assigned to Mark R

4662

I think "when" is disfavoured w.r.t. "if"

Change "when used with" to "it used with"

Trivial to search for the term

Assigned to Mark R.

4758

"Receive Sequence Count" v. "replay counter" v. "TSC/PN/IPN counter" -- should use the same term throughout

As it says in the comment

First need to decide on the term to use

Assigned to Mark R.

 

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: Qi, Emily H <emily.h.qi@xxxxxxxxx>
Sent: 20 January 2020 22:05
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx> (dstanley1389@xxxxxxxxx) <dstanley1389@xxxxxxxxx>; edward.ks.au@xxxxxxxxx
Subject: RE: TGmd comments- need page and line numbers.

 

Hello Mark,

Attached please find a sample of text file I generated.

Is it what I asked for? If not, sorry, I don’t know how to generate the file that you requested.   

 

Regards,

Emily

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, January 20, 2020 1:48 PM
To: Qi, Emily H <emily.h.qi@xxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx> (dstanley1389@xxxxxxxxx) <dstanley1389@xxxxxxxxx>
Subject: RE: TGmd comments- need page and line numbers.

 

Hello Emily,

 

> Thank you for the additional information.

> I have provided comment resolutions for 5 comments below and included them in the “Motion-Editor-Q”.  See: https://mentor.ieee.org/802.11/dcn/20/11-20-0010-02-000m-revmd-sa1-comments-for-editor-ad-hoc.xls

> I will assign some of comments that require more information to you for providing resolutions. I will take care others to do further investigation. Please see Emily’s response column in the table below.

 

Thanks for the update.  My further observations/questions/requests are

in yellow.

 

If you can supply me with a text version of the document with some

programmatically-accessible way of identifying page numbers then

I might be able to rustle up some kind of grep/python script to find

page numbers (obviously it can't have line numbers because to search

in plain text there can't be line numbers or they will mess up

the grepping).

 

CID

Comment

Proposed Change

Locations

Emily’s response.

4402

Spurious comma before modal verb (i.e. when not the end of a subclause or list).  One example is at 1842.10 and another at 2187.23

Remove spurious commas in ", shall"s

160 hits for ", shall"; would need to just step through them

Emily Will look at them again.

4406

"sets to" should be "is set to"

Change "set to" to "is set to" in 9.6.7.39 DCS Request frame format (2x).  Change "set to" to "is set to the" in 11.43.7.3 NCC responding STA (2x)

Trivial to search for the 4 instances in the referenced subclauses

Trivial. Revised.  Note that: “set to” should be “sets to”.

4414

Magic numbers for Status/Reason Codes are not helpful to the reader

As it says in the comment

Cannot provide a list; maybe search for "code <n>" or "status <n>" where <n> is a digit

Submission Required. Assigned to Mark R.

4424

"IP Address" should be "IP address" (unless name of field etc.)

As it says in the comment

694.50/55/63, 695.27/56/62, 696.6/39, 1374.47, 2393.29 (also lowercase "Target")

Accepted/Revised. Thanks!

4469

definitions with spaces shouldn't be in 3.4 (the components need definition only).  So no 802.x  LAN, HWMP SN, PP A-MSDU, PTP TSPEC or SA Query
SPP A-MSDU

As it says in the comment

Trivial to search for the terms in the referenced subclause

Emily will look at these. If we remove these definition, where we should define them.

4483

The way Action fields are described is inconsistent regarding elements they contain.  Sometimes the table says Blah element, sometimes it says Blah.  Either is probably fine, but in the first case the cell needs to give a xref to where the element is defined, and in the second case there needs to be a line saying "The Blah field contains a Blah element (see 9.x.y.z)."

As it says in the comment

Cannot provide a list.  First decide the preferred format.  I think Payam was going to fix all this?

I don’t think Payam will fix this item. Assigned to Mark R.

4487

"high rate TIM frame" and "low rate TIM frame" should have " data" added after "rate" (p. 1242 and 3844)

As it says in the comment

Trivial to search for the instances on the referenced pages

Revised.  At 1242.39 and 3844.18, change "the high rate TIM frame" to "the high data rate TIM frame".  At 1242.44 and 3844.34, change  "the low rate TIM frame" to "the low data rate TIM frame".

4499

If the term "slave" is no longer acceptable (CID 2020), is the term "master" still acceptable (other than "master key" contexts)?  There are only a few such instances

As it says in the comment

206.30, 1506.3, 1506.46 (2x), 1506.47, 1507.5 (2x), 2146.34,  3773.33

Emily will look at them.

4501

"ACM flag" and "ACM bit" should be "ACM subfield", as should "ACM field", for consistency

As it says in the comment

Trivial to search for the terms (2x ACM flag, 18x ACM bit, 8x ACM field (note not QACM))

Emily will look at them.

4526

No need to say "as defined in" in the Description column when already given in the Valid range column

Delete "as defined in the
Neighbor Report element format" in the table in 6.3.31.2.2; " as
defined in the Neighbor Report element format" in the table in 6.3.31.3.2; ", each as
defined in the QLoad Report
element" in the table in  6.3.85.3.2 and in 6.3.85.5.2

Trivial to search for the terms in the referenced subclauses

Accepted

4537

If first character of caption is a letter, it should be uppercase

Change "10.37 null data PPDU" to "10.37 Null data PPDU"

Cannot provide a list beyond the referenced subclause; need to eyeball all the captions (or if you can provide them to me in a text file I can grep)

Assigned to Mark R

4545

DA/RA/TA/SA followed by "address" (except when followed by e.g. "filtering") is a pleonasm

As it says in the comment

309.55, 1830.56/60/63, 1848.34, 1874.24, 2045.19, 2396.14

Accepted.

4551

"This contains", "Contains" etc. in Clause 6 is superfluous and should be deleted

As it says in the comment

583.15, 586.22, 336.22, 340.36, 361.55, 362.3, 371.3/8, 380.55, 381.3, 391.16/23, 431.10, 433.37, 440.5, 452.49, 453.46, 485.30, 486.46, 522.15, 523.11, 535.11, 535.50, 536.47, 537.3/8/12, 538.9/25/31/35, 539.40, 540.42, 583.15, 586.22, 649.38

Emily will bring these items for discussion.

4554

It's sometimes "asymmetric BA" and sometimes "asymmetric block ack".  By analogy with "fragment BA", which is always like that, it should always be "asymmetric BA"

Change "symmetric block ack" (case-insensitively) to "symmetric BA" (this is to cover both Asymmetric and asymmetric), and dot11AsymmetricBlockAckActivated to dot11AsymmetricBAActivated

Trivial to search for the _expression_ given (26 instances)

Emily will look at these items.

4565

Why do some frame format figures in 9.3.1.x xxx frame format show the extent of the MAC header with arrows, and some not?

As it says in the comment

Cannot provide a list.  First decide the preferred format or define the rule for the presence/absence of the arrow

Assigned to Mark R.

4575

Is it BSSID of the AP or BSSID of the AP's BSS?

As it says in the comment

Need to first decide on the answer to the question

Assigned to Mark R.

4576

Just "BSSID" is often used for infraBSS, but for IBSS it's generally qualified as "BSSID of the IBSS" -- why?

As it says in the comment

Need to first decide on the answer to the question

Assigned to Mark R.

4577

The PSDU size and PPDU duration limits shown in Table 9-25--Maximum data unit sizes (in octets) and durations (in microseconds) are duplicates of info in the PHY clauses

Just give a reference to the appropriate row of the appropriate PHY table in each case

816.13/28

Emily will look at these.

4581

ToA should be TOA and ToD should be TOD, for consistency

As it says in the comment

2370.28/29/31/32/39, 4592.25 (also Arrival->arrival), 4592.26 (2x), 4592.49, 4593.8/10/13/14/19/20/30/31/35/37

Emily will look at them.

4586

"Neighbor report request/response" is confusing.  Just call it "Neigbor request/report"

As it says in the comment

Trivial to search for the terms

Emily will look at it.

4587

Per the rules on foo report/request, "neighbor report" should be "Neighbor report"

As it says in the comment

Trivial to search for the term

Emily will look at it.

4588

Sometimes capability bits are "Supported" (e.g. "A-MPDU Supported"), sometimes "Support" (e.g. "BAT Support")

As it says in the comment

Cannot provide a list beyond the examples; if provided with list of capability field names I can do a grep

Assigned to Mark R.

4592

CID 2096 asked for "that had received" to be changed to "that receives", and was accepted, but there are still some left

Change in 9.2.2 and 10.3.2.9 (not the other 3)

Trivial to search for the terms in the referenced subclauses

Emily will look at it.

4593

"forty MHz" should be "40 MHz"

As it says in the comment

Trivial to search for the term

Emily will look at it. 17 instances.

4606

There is inconsistency between "differentiate" and "differentiates" etc. (define/defines, indicate/indicates, determine/determines) in TXVECTOR tables

As it says in the comment

Cannot provide a list

Assigned to Mark R.

4616

CID 2450 follow-up.  Shouldn't there be "Std" inside "IEEE 802", at least where not followed by ".11"?

As it says in the comment

Need to first decide on the answer to the question

Assigned to Mark R.

4618

"receive address" should be "received address" throughout, and "transmit address" should be "transmitter address".  Also "transmitting  STA  address  (TA),  and
receiving STA address (RA)" should be "transmiter address  (TA),  and
receiver address (RA)"

As it says in the comment

Trivial to search for the terms. Note typo in comment: should be "receiver" not "received"

Need group inputs on the direction.

4620

Sometimes it's "Anti-clogging Token", sometimes "Anti-Clogging Token".  Need to pick one (make decision about whether each component of a hyphenated construct is uppercased or not)

As it says in the comment

Need to first decide on the answer to the question

Assigned to Mark R

4623

Inconsistency on ellipsis for numeric contents, i.e. whether x,...,y or x,..,y (two dots or three, and space or not).  Also commas not always present

As it says in the comment

Cannot provide a list

Assigned to Mark R.

4662

I think "when" is disfavoured w.r.t. "if"

Change "when used with" to "it used with"

Trivial to search for the term

Assigned to Mark R.

4676

"The structure of this/the blah field/element" is a bit odd

Change to use the canonical "The format of" wording

Trivial to search for "The structure of th"

Assigned to Mark R.

4688

"multicast MSDU"/"Multicast MSDU" should be "group addressed MSDU"/"group addressed MSDU"; similarly unicast -> individually addressed

As it says in the comment

Trivial to search for the terms

Emily will look at these.

4690

"Beacon Report" should be "Beacon report" when referring to the report (i.e. not part of a field/element name), ditto Request.  E.g in: fragmented over multiple Beacon Reports, identifies the Beacon Report instance, a response to a Beacon Request, a Beacon Report identified by

As it says in the comment

Cannot provide a list beyond the examples

Assigned to Mark R.

4758

"Receive Sequence Count" v. "replay counter" v. "TSC/PN/IPN counter" -- should use the same term throughout

As it says in the comment

First need to decide on the term to use

Assigned to Mark R.

 

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: Qi, Emily H <emily.h.qi@xxxxxxxxx>
Sent: 8 January 2020 21:43
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: Qi, Emily H <emily.h.qi@xxxxxxxxx>
Subject: TGmd comments- need page and line numbers.

 

Hello Mark,

 

I have some difficulties to address some of your editorial comments because I couldn’t find page and line number in these comments.

Could you please provide page numbers and line numbers for comments below?

4620,  4586,  4587,  4588,  4592,  4593,  4606,  4758,  4618,  4576,  4623, 4662,  4676,  4688,  4690,  4616,  4526,  4406,  4414,  4424,  4469,  4483,  4487,  4581,  4501,  4577,  4537,  4545,  4551,  4554,  4565,  4575,  4402,  4499

 

Thank you,

Emily Qi

 

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjAwMTA5MTQ1NzEwZXVjYXMxcDJiZWQ4NjBmYjNhYzBkNmM1NTUxMGU4ZmVhOWE0MmUzMiZyZWNpcGllbnRBZGRyZXNzPWVtaWx5LmgucWlAaW50ZWwuY29t

 

 

  


--- End Message ---
--- Begin Message ---

Hello Graham,

 

Thanks for the update.

 

Re 4235, your resolution now has both ACCEPTED and REVISED.

 

Re 4559, I think that we need an expert (Assaf maybe, or we need to

find a CMMG person) to confirm whether 5*N is indeed correct

(and that this isn't some subtle difference between "subfields of

TRN-R/T field" and "TRN Unit".  Also, I think I might be minded to

prefer the explicit multiplication glyph (although it is true that

4N and 5N appear in half a dozen places).

 

Re 4693, the comment is referring to Figures 24-2 and 24-5.  These

have 128s as highlighted here:

 

 

 

(I also see 128s in the STF in Figure 24-3, in fact:

 

)

 

For reference, CID 2036 was:

 

Figures 25-4, 25-5, and 25-6 show sequences of length 256 used in the preamble while the sequences are actually of length 32

 

I'm not saying that the change from 14.6 to 146 is wrong; it's just

that it's not what I had in my in my comment and I haven't checked.

 

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: Smith, Graham <gsmith@xxxxxxxxx>
Sent: 29 January 2020 19:18
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: M Montemurro (montemurro.michael@xxxxxxxxx) <montemurro.michael@xxxxxxxxx>; Dorothy Stanley <dstanley1389@xxxxxxxxx>; Assaf Kasher (akasher@xxxxxxxxxxxxxxxx) <akasher@xxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11] 2020 January - March TGmd CRC teleconference and ad-hoc agenda document posted

 

Hi Mark,

Thanks for the comments.  There was confusion but I think I have sorted them out now and have posted 0233r1.

Thanks

Graham

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, January 29, 2020 10:39 AM
To: Smith, Graham <gsmith@xxxxxxxxx>
Cc: M Montemurro (montemurro.michael@xxxxxxxxx) <montemurro.michael@xxxxxxxxx>; Dorothy Stanley <dstanley1389@xxxxxxxxx>; Assaf Kasher (akasher@xxxxxxxxxxxxxxxx) <akasher@xxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11] 2020 January - March TGmd CRC teleconference and ad-hoc agenda document posted

 

Hello Graham,

 

Graham SMITH - https://mentor.ieee.org/802.11/dcn/20/11-20-0233-00-000m-cids-for-graham-from-mike.docx 25 mins

 

Thanks for these resolutions.  I attach some comments.

 

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: Dorothy Stanley <dstanley1389@xxxxxxxxx>
Sent: 24 January 2020 15:44
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] 2020 January - March TGmd CRC teleconference and ad-hoc agenda document posted

 

--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

 

 

which contains the draft agenda document for the upcoming TGmd CRC teleconferences and February ad-hoc meeting.

Teleconferences: January 31, February 7, 14 and March 13th at 10am Eastern (2 hours)

Adhoc meeting Sunrise Florida February 18-19-20

 

The proposed comment resolution topics for the first 2 teleconferences are copied below.

These are subject to change; please let me know of any additional agenda topics.

 

Thanks,

 

Dorothy

=============

See the dial-in instructions: Webex meeting: Join Meeting number: 796 002 752 Meeting password: wireless Join by phone: +1-510-338-9438 USA Toll +44-20-3198-8144 UK Toll Access code: 796 002 752

more details»  copy to my calendar

  1. 2020-01-31
    1. Edward Au - https://mentor.ieee.org/802.11/dcn/20/11-20-0235-00-000m-resolution-for-cmmg-related-comments.docx 25 mins
    2. Graham SMITH - https://mentor.ieee.org/802.11/dcn/20/11-20-0233-00-000m-cids-for-graham-from-mike.docx 25 mins
    3. Menzo Wentink - https://mentor.ieee.org/802.11/dcn/20/11-20-0150-05-000m-assorted-crs-revmd-draft-3-0.docx  60 mins
  1. 2020-02-07
    1. GEN CIDs – Jon ROSDAHL – 60 mins
    2. Menzo Wentink - https://mentor.ieee.org/802.11/dcn/20/11-20-0150-05-000m-assorted-crs-revmd-draft-3-0.docx  60 mins

Teleconferences are subject to applicable policies and procedures, see below.

 

•       IEEE Code of Ethics

–       https://www.ieee.org/about/corporate/governance/p7-8.html  

•       IEEE Standards Association (IEEE-SA) Affiliation FAQ

–       https://standards.ieee.org/faqs/affiliation.html

•       Antitrust and Competition Policy

–       https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/antitrust.pdf

•       IEEE-SA Patent Policy

–       http://standards.ieee.org/develop/policies/bylaws/sect6-7.html  

–       https://standards.ieee.org/about/sasb/patcom/

 •       IEEE 802 Working Group Policies &Procedures (29 Jul 2016)

–       http://www.ieee802.org/PNP/approved/IEEE_802_WG_PandP_v19.pdf

•       IEEE 802 LMSC Chair's Guidelines (Approved 13 Jul 2018)

–       https://mentor.ieee.org/802-ec/dcn/17/ec-17-0120-27-0PNP-ieee-802-lmsc-chairs-guidelines.pdf

•       Participation in IEEE 802 Meetings

–       https://mentor.ieee.org/802-ec/dcn/16/ec-16-0180-05-00EC-ieee-802-participation-slide.pptx

•       IEEE 802.11 WG OM: (Approved 10 Nov 2017)

–       https://mentor.ieee.org/802.11/dcn/14/11-14-0629-22-0000-802-11-operations-manual.docx

----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, dstanley@xxxxxxxx
Hewlett Packard Enterprise
dorothy.stanley@xxxxxxx
dstanley1389@xxxxxxxxx
+1 630-363-1389

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1

 

 

  

Note: This message is directed to and is for the use of the above-noted addressee only, and its contents may be legally privileged or confidential. If the reader of this message is not the intended recipient, you are hereby notified that any distribution, dissemination, or copy of this message is strictly prohibited. If you have received this message in error, please delete it immediately and notify the sender. This message is not intended to be an electronic signature nor to constitute an agreement of any kind under applicable law unless otherwise expressly indicated hereon.


--- End Message ---