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

Re: [STDS-802-11-TGM] FW: TGmd - CID2634



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Copying the TGm reflector since there may be other parties that are interested in this resolution.

Note that this needs to be posted in a document in order to be considered as a comment resolution.

Cheers,

Mike

On Fri, Sep 13, 2019 at 10:50 AM Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx> wrote:

 

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Date: Friday, September 13, 2019 at 9:04 AM
To: "Cordeiro, Carlos" <carlos.cordeiro@xxxxxxxxx>, Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>, "Qi, Emily H" <emily.h.qi@xxxxxxxxx>, "mark.hamilton2152@xxxxxxxxx" <mark.hamilton2152@xxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>, Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634

 

Hello,

 

Here is the version with the issues fixed, and the addition of the

stuff that was TBD:

 

Discussion:

 

The Multi-band element is huge.  We should not be using this to carry just three octets of information.

 

Proposed changes:

 

In D2.4:

 

Add the following subclause:

 

9.4.2.xx OCT Source element

 

The OCT Source element is used to specify the MLME that is the source of an OCT MMPDU.  The format of the OCT Source element is shown in Figure 9-xxx.

 

 

Element ID

Length

Element ID Extension

Band ID

Channel Number

BSSID

Octets:

1

1

1

1

1

6

Figure 9-xxx—OCT Source element format

 

The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).

 

The Band ID field identifies the band on which the source MLME operates, as defined in Table 9-69 (Band ID field).

 

The Channel Number field contains the channel number on which the source MLME operates.

 

The BSSID field contains the BSSID of the BSS in which the source MLME operates.

 

Add the following row to Table 9-94—Element IDs at the correct position for the Element ID Extension (probably just before the last row):

               

OCT Source (see 9.4.2.xx (OCT Source element))

255

<ANA>

Yes

No

 

and modify the last row (Reserved) to not include <ANA> in the third column (Element ID Extension).

 

Change as follows:

 

6.3.89.2.2 Semantics of the [MLME-OCTunnel.request] service primitive

 

The primitive parameters are as follows:

MLME-OCTunnel.request(

PeerSTAAddress,

OCT MMPDU,

Multi-band peer,

Multi-bandOCT source(M70)(#2631))

Multi-bandOCT

source(M70)(#263

1)

Multi-bandOCT Source

element

As defined in the Multi-bandOCT Source

element format (see 9.4.2.138

(Multi-band element)xx (OCT Source element))

The Multi-bandOCT Source element identifies the

MLME entity that generated (i.e., is the

source) of the OCT MMPDU.

 

6.3.89.3.2 Semantics of the [MLME-OCTunnel.indication] service primitive

 

The primitive parameters are as follows:

MLME-OCTunnel.indication(

PeerSTAAddress,

OCT MMPDU,

Multi-band local,

Multi-bandOCT source,(M70)(#2631)

Tunneled RXVECTOR(M70)

)

 

Multi-bandOCT

source(M70)(#263

1)

Multi-bandOCT Source

element

As defined in the Multi-bandOCT Source

element format (see 9.4.2.138

(Multi-band element)xx (OCT Source element))

The Multi-bandOCT Source element identifies the

MLME entity that generated (i.e., is the

source) of the OCT MMPDU.

 

9.6.20.7 On-channel Tunnel Request frame format

 

Table 9-484—On-channel Tunnel Request frame Action field format

5(M70)

Multi bandOCT Source

 

(M70)The Multi-bandOCT Source field contains the Multi-bandan OCT Source element that identifies the MLME that is the source of an OCT MMPDU. The values of the Band ID, Channel Number and BSSID fields contained in this element are used to identify the MLME within the STA.

 

11.32.5 On-channel Tunneling (OCT) operation

 

(M70)To perform the OCT procedure, the values of the Band ID, Channel Number and BSSID fields in a Multi-band element or OCT Source element are used to identify an MLME. All other fields in the Multi-band element shall be reserved.

 

(M70)Except for the following cases, the values of the Band ID, Channel Number and BSSID fields in a Multi-band element or OCT Source element are used by an NT-MLME to deliver messages to a TR-MLME through the OCTunnel.request primitive, and are used by a TR-MLME to deliver messages to an NT-MLME through the OCTunnel.indication primitive:

 

(#2200)An NT-MLME receiving an OCT MLME request primitive shall

 

— As defined in this standard, process the request and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.

 

— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU, the Multi-band peer parameter set to the peer Multi-band element and the Multi-bandOCT source parameter set(#2631) to the Multi-bandOCT Source element identifying the NT-MLME.(M70)

 

A TR-MLME receiving an On-channel Tunnel Request frame shall generate an MLME-OCTunnel.indication primitive with the Multi-band local parameter set to the Multi-band element identifying the TR-MLME, the Multi-bandOCT source parameter(#2631) set to the value of the Multi-bandOCT Source field contained in the On-channel Tunnel Request frame and the Tunneled RXVECTOR parameter set to the RXVECTOR of the On-channel Tunnel Request frame(M70). The MLME-OCTunnel.indication primitive shall be generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame.

 

(#2200)An NT-MLME receiving an MLME-OCTunnel.indication primitive shall

 

— As defined in this standard, process the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air, with the exception that an (#2591)acknowledgment, if any, shall not be sent as a response to the reception of the MMPDU.(M70)

 

— Generate an OCT MLME indication primitive, if one is defined, corresponding to the frame type of tunneled MMPDU. This primitive is generated to the SME of the STA, which processes the MMPDU as defined in this standard. The Multi-band local parameter of the OCT MLME indication primitive shall be set to the value of the Multi-band local parameter of the MLME-OCTunnel.indication primitive and the Multi-band peer parameter shall be set to the value of the Multi-bandOCT source parameter(#2631) of the MLME-OCTunnel.indication primitive.(M70)

 

(#2200)An NT-MLME receiving an OCT MLME response primitive, (M70)if one is defined, or generating a response by itself, if no OCT MLME response primitive is defined (e.g., MLME-SCAN.response is not defined), shall

 

— As defined in this standard, process the response and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.

 

— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU, the Multi-band peer parameter set to the the peer Multi-band element and the Multi-bandOCT source parameter(#2631) set to the Multi-band element identifying the NT-MLME. If no OCT MLME response primitive is defined, the Multi-band peer parameter shall be set to the value of the Multi-bandOCT source parameter(#2631) received in the corresponding MLME-OCTunnel.indication primitive. The MLME-OCTunnel.request primitive shall be generated to the TR-MLME identified by the local Multi-band element specified in the OCT MLME response primitive, if one is defined, or to the TR-MLME identified by the Multi-band local parameter of the MLME-OCTunnel.indication primitive that triggered this response, if no OCT MLME response primitive is defined.(M70)

 

A TR-MLME receiving an On-channel Tunnel Request frame generates an MLME-OCTunnel.indication primitive with the Multi-band local parameter set to the Multi-band element identifying the TR-MLME, the Multi-bandOCT source parameter(#2631) set to the value of the Multi-bandOCT Source field contained in the On-channel Tunnel Request frame and the Tunneled RXVECTOR parameter set to the RXVECTOR of the On-channel Tunnel Request frame.(M70) The MLME-OCTunnel.indication primitive is generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame.

 

(#2200)An NT-MLME receiving an MLME-OCTunnel.indication primitive

 

— Processes the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air.

 

— Generates an OCT MLME confirm primitive, if one is defined, corresponding to the frame type of the tunneled MMPDU. This primitive is directed at the SME and has the Multi-band local parameter set to the value of the Multi-band local parameter of the MLME-OCTunnel.indication primitive and the Multi-band peer parameter set to the value of the Multi-bandOCT source(#2631) parameter of the MLME-OCTunnel.indication primitive. If the OCT MLME confirm primitive is the MLME-SCAN.confirm primitive and the NT-MLME did not scan all the channels specified in the corresponding MLME-SCAN.request primitive, the ResultCode parameter in the MLME-SCAN.confirm primitive shall be set to PARTIAL_SCAN and the ScannedChannelList parameter shall list all channels that have been scanned.(M70)

 

Proposed resolution:

 

REVISED

 

Make the changes shown under “Proposed changes” for CID 2634 in <this document>, which introduce an OCT Source element to ensure unnecessary octets are not transmitted.

 

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: Mark Rison
Sent: 13 September 2019 07:54
To: 'Cordeiro, Carlos' <carlos.cordeiro@xxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634

 

Hello Carlos,

 

Thanks for the review.

 

  1. I see occurrences of “OCT element” which is something that does not exist.

 

I find one occurrence -- where are the others?

 

That occurrence should of course be "OCT Source element".

 

  1. There is a paragraph in (11.32.5 On-channel Tunneling (OCT) operation) that reads: “(M70)To perform the OCT procedure, the values of the Band ID, Channel Number and BSSID fields in a Multi-band element are used to identify an MLME. All other fields in the Multi-band element shall be reserved.” However, now you have a new element. How are those fields set? How would this paragraph be changed to reflect the new element?

 

Ah, yes, thanks.  That can just become;

 

To perform the OCT procedure, the values of the Band ID, Channel Number and BSSID fields in the OCT Source element are used to identify an MLME.

 

This resolution has problems as it is. A more thorough scrubbing is needed.

 

OK, well please perform this scrubbing ASAP, since I think Dorothy

is extremely keen that all TGm comments be resolved by the end

of next week!

 

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: Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>
Sent: 13 September 2019 01:27
To: Mark Rison <m.rison@xxxxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634

 

I need to review this further. However, after a quick review:

  1. I see occurrences of “OCT element” which is something that does not exist.
  2. There is a paragraph in (11.32.5 On-channel Tunneling (OCT) operation) that reads: “(M70)To perform the OCT procedure, the values of the Band ID, Channel Number and BSSID fields in a Multi-band element are used to identify an MLME. All other fields in the Multi-band element shall be reserved.” However, now you have a new element. How are those fields set? How would this paragraph be changed to reflect the new element?

 

This resolution has problems as it is. A more thorough scrubbing is needed.

 

Thanks,

 

Carlos.

 

From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Thursday, September 12, 2019 12:27 PM
To: Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634

 

Hello,

 

I haven't received any feedback on this, so I'm going to presume people

are happy with this direction and I just need to do the stuff in yellow

below.

 

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: Mark Rison
Sent: 29 August 2019 19:00
To: 'Cordeiro, Carlos' <carlos.cordeiro@xxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634

 

OK, here's what I've thrown together quickly:

 

Discussion:

 

The Multi-band element is huge.  We should not be using this to carry just three octets of information.

 

Proposed changes:

 

In D2.4:

 

Add the following subclause:

 

9.4.2.xx OCT Source element

 

The OCT Source element is used to specify the MLME that is the source of an OCT MMPDU.  The format of the OCT Source element is shown in Figure 9-xxx.

 

 

Element ID

Length

Element ID Extension

Band ID

Channel Number

BSSID

Octets:

1

1

1

1

1

6

Figure 9-xxx—OCT Source element format

 

The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).

 

The Band ID field identifies the band on which the source MLME operates, as defined in Table 9-69 (Band ID field).

 

The Channel Number field contains the channel number on which the source MLME operates.

 

The BSSID field contains the BSSID of the BSS in which the source MLME operates.

 

TBD: Add the element to the element table, as extensible but not fragmentable

 

Change as follows:

 

9.6.20.7 On-channel Tunnel Request frame format

 

Table 9-484—On-channel Tunnel Request frame Action field format

5(M70)

Multi bandOCT Source

 

(M70)The Multi-bandOCT Source field contains the Multi-bandan OCT Source element that identifies the MLME that is the source of an OCT MMPDU. The values of the Band ID, Channel Number and BSSID fields contained in this element are used to identify the MLME within the STA.

 

11.32.5 On-channel Tunneling (OCT) operation

 

(#2200)An NT-MLME receiving an OCT MLME request primitive shall

 

— As defined in this standard, process the request and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.

 

— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU, the Multi-band peer parameter set to the peer Multi-band element and the Multi-bandOCT source parameter set(#2631) to the Multi-bandOCT element identifying the NT-MLME.(M70)

 

A TR-MLME receiving an On-channel Tunnel Request frame shall generate an MLME-OCTunnel.indication primitive with the Multi-band local parameter set to the Multi-band element identifying the TR-MLME, the Multi-bandOCT source parameter(#2631) set to the value of the Multi-bandOCT Source field contained in the On-channel Tunnel Request frame and the Tunneled RXVECTOR parameter set to the RXVECTOR of the On-channel Tunnel Request frame(M70). The MLME-OCTunnel.indication primitive shall be generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame.

 

(#2200)An NT-MLME receiving an MLME-OCTunnel.indication primitive shall

 

— As defined in this standard, process the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air, with the exception that an (#2591)acknowledgment, if any, shall not be sent as a response to the reception of the MMPDU.(M70)

 

— Generate an OCT MLME indication primitive, if one is defined, corresponding to the frame type of tunneled MMPDU. This primitive is generated to the SME of the STA, which processes the MMPDU as defined in this standard. The Multi-band local parameter of the OCT MLME indication primitive shall be set to the value of the Multi-band local parameter of the MLME-OCTunnel.indication primitive and the Multi-band peer parameter shall be set to the value of the Multi-bandOCT source parameter(#2631) of the MLME-OCTunnel.indication primitive.(M70)

 

(#2200)An NT-MLME receiving an OCT MLME response primitive, (M70)if one is defined, or generating a response by itself, if no OCT MLME response primitive is defined (e.g., MLME-SCAN.response is not defined), shall

 

— As defined in this standard, process the response and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.

 

— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU, the Multi-band peer parameter set to the the peer Multi-band element and the Multi-bandOCT source parameter(#2631) set to the Multi-band element identifying the NT-MLME. If no OCT MLME response primitive is defined, the Multi-band peer parameter shall be set to the value of the Multi-bandOCT source parameter(#2631) received in the corresponding MLME-OCTunnel.indication primitive. The MLME-OCTunnel.request primitive shall be generated to the TR-MLME identified by the local Multi-band element specified in the OCT MLME response primitive, if one is defined, or to the TR-MLME identified by the Multi-band local parameter of the MLME-OCTunnel.indication primitive that triggered this response, if no OCT MLME response primitive is defined.(M70)

 

A TR-MLME receiving an On-channel Tunnel Request frame generates an MLME-OCTunnel.indication primitive with the Multi-band local parameter set to the Multi-band element identifying the TR-MLME, the Multi-bandOCT source parameter(#2631) set to the value of the Multi-bandOCT Source field contained in the On-channel Tunnel Request frame and the Tunneled RXVECTOR parameter set to the RXVECTOR of the On-channel Tunnel Request frame.(M70) The MLME-OCTunnel.indication primitive is generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame.

 

(#2200)An NT-MLME receiving an MLME-OCTunnel.indication primitive

 

— Processes the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air.

 

— Generates an OCT MLME confirm primitive, if one is defined, corresponding to the frame type of the tunneled MMPDU. This primitive is directed at the SME and has the Multi-band local parameter set to the value of the Multi-band local parameter of the MLME-OCTunnel.indication primitive and the Multi-band peer parameter set to the value of the Multi-bandOCT source(#2631) parameter of the MLME-OCTunnel.indication primitive. If the OCT MLME confirm primitive is the MLME-SCAN.confirm primitive and the NT-MLME did not scan all the channels specified in the corresponding MLME-SCAN.request primitive, the ResultCode parameter in the MLME-SCAN.confirm primitive shall be set to PARTIAL_SCAN and the ScannedChannelList parameter shall list all channels that have been scanned.(M70)

 

TBD: In Clause 6 change “Multi-band source” to “OCT source” (or other way round for the .ind).

 

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: Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>
Sent: 29 August 2019 18:21
To: Mark Rison <m.rison@xxxxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634

 

The spec uses the terms Multi-band peer parameter, Multi-band local parameter and Multi-band Source parameter in 11.32.5 and also in the primitives. As such,

 

> I'll just create a new extensible element containing the three things that are said to identify a source MLME (Band ID, Channel Number, BSSID -- note Mike that the operating class is not among these) and plumb it into 9.6.20.7 On-channel Tunnel Request frame format

 

… it is not evident to me how restricting the change to the above will bring consistency with the other parts in the spec. With that said, personally, I am open minded and look forward to seeing the proposed changes.

 

Thanks,

 

Carlos.

 

From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Thursday, August 29, 2019 7:07 AM
To: Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634

 

Hello,

 

Well, I don't propose to make all the

primitives in clause 6.3, text in 11.32.5 and figures (e.g., figures 11-53 and 11-54), etc....

changes only to be told the group doesn't want to make a change.

 

I'll just create a new extensible element containing the three things

that are said to identify a source MLME (Band ID, Channel Number, BSSID

-- note Mike that the operating class is not among these) and plumb it

into 9.6.20.7 On-channel Tunnel Request frame format.  Then people can

look at that.  The other changes will just follow trivially.

 

Thanks,

 

Mark

 

P.S.: Figures 11-53 and 11-54 appear not to be searchable, unlike other

figures.  Can the Editors please ensure that it is searchable in future

drafts, please?

 

--

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: Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>
Sent: 28 August 2019 18:36
To: Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Mark Rison <m.rison@xxxxxxxxxxx>; Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: Re: TGmd - CID2634

 

Thanks Emily,

 

So we would need Mark R to create and post a submission and Mark H to post a link to the document to the 802.11 reflector to obtain WG member feedback.

 

Cheers,

 

Mike

 

From: "Qi, Emily H" <emily.h.qi@xxxxxxxxx>
Date: Tuesday, August 27, 2019 at 8:41 PM
To: "mark.hamilton2152@xxxxxxxxx" <mark.hamilton2152@xxxxxxxxx>, Mark Rison <m.rison@xxxxxxxxxxx>, "Cordeiro, Carlos" <carlos.cordeiro@xxxxxxxxx>
Cc: Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>, Dorothy Stanley <dstanley1389@xxxxxxxxx>, Jon Rosdahl <jrosdahl@xxxxxxxx>, "Qi, Emily H" <emily.h.qi@xxxxxxxxx>
Subject: TGmd - CID2634

 

Hello Mark and Mark,

 

I have talked to Carlos on CID 2634. Carlos isn’t aware of any implementation in the field. Including Carlos here...

 

If we decide to go with the direction that Mark R proposed in the proposed resolution, someone (perhaps, Mark H ? ) should an email to the reflector and see whether there is any objection.

 

Also, a submission is required because we need to make changes to many places. For example, primitives in clause 6.3, text in 11.32.5 and figures (e.g., figures 11-53 and 11-54), etc....

 

Regards,

Emily

 

 

Image removed by sender.

 

Image removed by sender.




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

GIF image