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

Re: [STDS-802-11-TGAI] documents 15/447r1



Mano-san and Marc,

I just uploaded contribution 0466r0 with the same changes suggested in the e-mail that I sent out 4 hours ago. https://mentor.ieee.org/802.11/dcn/15/11-15-0466-00-00ai-reconsider-lb209-comment-resolution-to-cid-7083.doc

 

Thanks,

Yunsong Yang

Huawei Device USA Inc.

10180 Telesis Court, STE 165

San Diego, CA 92121

Phone: +1-858-754-3638

 

From: Abraham, Santosh [mailto:sabraham@xxxxxxxxxxxxxxxx]
Sent: Thursday, March 12, 2015 7:20 AM
To: Yangyunsong; STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
Cc: Cherian, George
Subject: RE: [STDS-802-11-TGAI] documents 15/447r1

 

I am fine with this being the resolution.

 

Santosh

 

From: Yangyunsong [mailto:yangyunsong@xxxxxxxxxx]
Sent: Thursday, March 12, 2015 4:08 AM
To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx; Abraham, Santosh
Cc: Cherian, George
Subject: RE: [STDS-802-11-TGAI] documents 15/447r1

 

Hi Santosh,

I have a slightly different opinion regarding the proposed Resolution to CID 7083 in doc 15/447r1 that you have uploaded.

 

I agree on the issue that the commenter raised. But I think the remedy is not right for the following reasons:

1.       Short SSID Indictor, just like many other presence indicators in the FILS Discovery frame, is used for parsing the frame properly. If we don’t pass the other presence indicators through MLME-SAP, we shouldn’t pass along this one either.

2.       The parameters that are truly interested by the upper layer is the SSID and Short SSID, not the indicator.

 

So, the remedy that I would like to suggest is to replace the current SSID/Short SSID row in the table of BSSDescriptionFromFD with the following two rows that are under the title row:

 

 

Name

Type

Valid range

Description

IBSS adoption [CID 2643]

SSID

Octet string.

As defined in the

SSID element.

The SSID of the found BSS. This parameter is present if the Short SSID Indicator in the received FILS Discovery frame is equal to 0.

Do not adopt

Short SSID

Integer

As defined

in

the Reduced Neighbor Report element.

The Short SSID of the found BSS. This parameter is present if the Short SSID Indicator in the received FILS Discovery frame is equal to 1.

Do not adopt

 

 

I think clause 6 should specify what information conceptually need be passed through MLME-SAP. It doesn’t force the implementation to do exactly the same. I believe an implementation can still pass on the Short SSID Indicator instead if that is the wish. But the standards should do what is conceptually right.

 

So, I wonder if you would like to consider my suggested remedy.

 

Thanks,

Yunsong Yang

Huawei Device USA Inc.

10180 Telesis Court, STE 165

San Diego, CA 92121

Phone: +1-858-754-3638

 

_______________________________________________________________________________

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-TGAI 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 _______________________________________________________________________________

Attachment: doc5kM0hjmAh9.doc
Description: 11-15-0466-00-00ai-reconsider-lb209-comment-resolution-to-CID-7083.doc