Hi Mark,
Thank you for your additional feedback.
I have attached a revised version that addresses your additional comments.
Also please find my responses in-line below in green:
Regards,
Abhi
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, January 29, 2021 1:16 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
CAUTION: This email
originated from outside of the organization.
Hello Abhi,
- Are the new MLO *GTK subelements not also needed in 9.4.2.47 Fast BSS
Transition element (FTE) too? This has the (non-MLO) GTK subelements
that 9.6.13.20 WNM Sleep Mode Response frame format has
AP: I prefer that this be addressed in a separate contribution focused on security. I suspect there may be other such instances that would need a similar fix.
Well, in md/D5.0 the only instances of "GTK subelement" are in
9.4.2.47 and 9.6.13.20. I'm fine with having this addressed in
a separate contribution, but it should not be forgotten.
I have submitted a comment against D0.3 so that we don’t forget this.
I am open to suggestions and would like to hear opinion from other members on this topic.
- Does a STA MLD associate with an AP MLD, or do only their affiliated
STAs do so? I ask in the context of sentences like "This enables […] a non-AP MLD to reduce power consumption and
remain associated […]"
AP: Po-Kai can provide my inputs. My understanding is that once a non-AP MLD has performed association (multi-link setup) with an AP MLD, all the STA of the non-AP MLD are in associated state
with the corresponding AP of the AP MLD operating their respective link
Yes, that's fine on a per-link/STA basis. The question is whether the
non-AP MLD itself is associated with the AP MLD.
We have the following text in D0.3 on pg 131:
- Traffic filter sets are MLD-wide, not per-link, right?
AP: yes that is my understanding
Does this need stating somewhere?
I’m not sure – probably not!
- I'm not sure "applied at the MLD level" is clear enough. I think the
statements should either be deleted or expanded to e.g. "applies to all
the STAs affiliated with an MLD"
AP: I have updated the sentence as follows:
“The WNM sleep state is maintained at the MLD level and the WNM sleep mode procedures defined in 11.2.3 (Power management in a non-DMG infrastructure network) and 11.2.3.16 (WNM sleep mode)
are performed at the MLD level and apply to all the STAs affiliated with the MLD.”
OK. There are several instances of "applied at MLD level".
Fixed in the attached version
- I think "setup links" should be just "links", since if the link is not
set up it does not exist
AP: I have kept the term ‘setup’. The idea is to say that the link that are setup as part of the multi-link setup
Well, that's necessarily true. Do we have "non-setup links"?
Fixed in the attached version
- "A non-AP MLD shall identify the link to which the GTK/IGTK/BIGTK belongs based on the
Link ID subfield carried in the corresponding subelement of the Key Data field."
should probably be " A non-AP MLD identifies…"
since it has no other choice
AP: Since it is clause 11, the text is normative.
Yes, but it's meaningless to make something that isn't a choice mandatory.
It's a statement of fact, not a requirement. Picking the first instance
of "element" in md/D5.0 Clause 10 we have:
For a non-AP STA communicating within a (#4703)non-mesh QoS BSS, the EDCA parameters used
are from
the EDCA Parameter Set element or (#4703)((#4694)for a non-AP STA prior to associating with an
AP of an infrastructure BSS, a mesh STA, or a STA that operates OCB) from the default values for the
parameters. The parameters used by the EDCAF to control its operation
are defined by dot11QAPEDCATable
at the AP and by dot11EDCATable at the non-AP STA.
Note no "shall"s.
Fixed in the attached version
General question for the group: is it "STAs of an MLD" or "STAs affiliated
with an MLD"?
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: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Thursday, 28 January 2021 22:44
To: Mark Rison <m.rison@xxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
Hi Mark,
Thank you for the additional feedback.
Please find my responses in-line below:
I will post an R2 with the changes as discussed below.
Regards,
Abhi
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, January 28, 2021 1:11 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
CAUTION: This email
originated from outside of the organization.
Thanks for this Abhi. Here are my residual questions/observations:
- Are the new MLO *GTK subelements not also needed in 9.4.2.47 Fast BSS
Transition element (FTE) too? This has the (non-MLO) GTK subelements
that 9.6.13.20 WNM Sleep Mode Response frame format has
AP: I prefer that this be addressed in a separate contribution focused on security. I suspect there may be other such instances that would need a similar fix.
I am open to suggestions and would like to hear opinion from other members on this topic.
- Does a STA MLD associate with an AP MLD, or do only their affiliated
STAs do so? I ask in the context of sentences like "This enables […] a non-AP MLD to reduce power consumption and remain associated […]"
AP: Po-Kai can provide my inputs. My understanding is that once a non-AP MLD has performed association (multi-link setup) with an AP MLD, all the STA of the non-AP MLD are in associated state with the corresponding AP
of the AP MLD operating their respective link
- Traffic filter sets are MLD-wide, not per-link, right?
AP: yes that is my understanding
- I'm not sure "applied at the MLD level" is clear enough. I think the
statements should either be deleted or expanded to e.g. "applies to all
the STAs affiliated with an MLD"
AP: I have updated the sentence as follows:
“The WNM sleep state is maintained at the MLD level and the WNM sleep mode procedures defined in 11.2.3 (Power management in a non-DMG infrastructure network) and 11.2.3.16 (WNM sleep mode)
are performed at the MLD level and apply to all the STAs affiliated with the MLD.”
- I think "setup links" should be just "links", since if the link is not
set up it does not exist
AP: I have kept the term ‘setup’. The idea is to say that the link that are setup as part of the multi-link setup
- "the pending GTK, IGTK, and BIGTK for the affected link(s)
" should probably be
"the pending GTK, IGTK, and BIGTK for each of the affected links
" or
"the pending GTK(s), IGTK(s), and BIGTK(s) for the affected link(s)
" and similarly for
the two other bullets
AP: Fixed
- "A non-AP MLD shall identify the link to which the GTK/IGTK/BIGTK belongs based on the Link ID subfield carried
in the corresponding subelement of the Key Data field."
should probably be " A non-AP MLD identifies…"
since it has no other choice
AP: Since it is clause 11, the text is normative.
- "The Key Info, the Key Length and the RSC fields"
should probably be "The Key Info, Key Length and RSC fields".
Similarly for "The Key ID and the PN fields
" and "The Key ID and the BIPN fields
"
AP: fixed
- "is as shown
" should be "is shown
"
- "as as defined" should be "are
as defined"
- "the link for which the key(s) apply to"
should probably be "the link to which the key(s) apply"
- "the WNM sleep mode" (lowercase) should be "WNM sleep mode" (2x)
AP: fixed the above four items
General question for the group: is it "STAs of an MLD" or "STAs affiliated
with an MLD"?
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: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Wednesday, 27 January 2021 20:00
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
Hi All,
I have updated the PDT based on additional feedback from Mark R. and Rojan.
Could you please review the attached doc and let me know if you have further feedback?
Regards,
Abhi
From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Sent: Wednesday, January 27, 2021 6:17 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
CAUTION: This email originated from outside of
the organization.
Hi Rojan, Abhi,
Just to clarify, my comment was: if we use ML element, then we should use basic variant.
But I’m fine using a new subelement.
Best,
Laurent
From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Wednesday, January 27, 2021 3:52 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
Hi Abhi,
When I read Laurent’s comment, my interpretation is that he prefers using Basic variant ML element instead of defining a new ML variant, so I am not sure how you reached the conclusion that extending existing fields in WNM Response frame
is favored. Perhaps you could do a simple SP to check group’s preference, but up to you.
Regarding this revision, I see that the non-AP MLD’s behavior regarding reception of the MLO GTK etc. are mentioned, but there are no mention of the AP MLD’s behavior. Shouldn’t there be corresponding text specifying in which condition
the AP MLD includes the MLO GTK etc. in the WNM Sleep mode Response frame (particularly for the unsolicited case)?
Regards,
Rojan
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Wednesday, January 27, 2021 1:43 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
Hi All,
Based on the feedback from the previous call and discussions on the reflector, the group seems to be favoring extending existing field in the WNM Response frame.
I have revised the PDT to define new subelements within the Key Data field to carry MLO group keys.
The attached doc also incorporates feedback received from Mark R.
Could you please take a look at the attached doc and let me know if you have further feedback?
Regards,
Abhi
From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Sent: Tuesday, January 26, 2021 5:38 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
CAUTION: This email originated from outside of
the organization.
Hi all,
I think we should really limit as much as possible the use of the different Types, as this will highly complicate the parsing.
We have designed the common part so that we can indicate if fields are present or not, we should use that.
Similarly, the per-STA part is made of subelements so that we can include what we need, while having the same structure. If we want to have some indications that are fields and not elements, we can easily include a control field that will
indicate the presence of the fields (same as the common part).
Best,
Laurent
From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Tuesday, January 26, 2021 7:01 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
Hi Yongho,
Yes, I am aware that we have defined GTK, IGTK, BIGTK KDEs in D0.3, however these are not subelements. If we go the subelement route, anyway we also need to define new subelements for each procedure (WNM, Fast BSS Transition, FILS etc.)
in order to signal the Link Ids of the APs, so it is not really straightforward reusing of existing subelements as well.
While I agree with you that we should have a single consistent method, I think that using ML element is the better option. Instead of limiting to WNM case, we could expand the usage of Abhi’s new variant of ML element so that it can cater
for all Key distributions scenarios, may be rename it “Key Distribution variant ML element“? Perhaps we can even revisit whether the new KDEs in D0.3 can be changed to use this ML element so that we have one unified way to distribute the keys. This approach
is also similar to the inclusion of the Multi-band element in the 4-way handshake messages. Implementation wise this will also make the parsing simpler since a single ML element variant need to be parsed instead of different subelements. What do you think?
Regards,
Rojan
From: Yongho Seok <yongho.seok@xxxxxxxxx>
Sent: Tuesday, January 26, 2021 1:08 PM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval
Hi Rojan,
KDE format also needs to carry GTK, IGTK, and BIGTK of other APs.
On that purpose, in D0.3, we already defined the MLO GTK, MLO IGTK, and MLO BIGTK subelements, instead of creating a new variant of the ML element. This way is the same approach done in the Multi-band GTK KDE.
In addition to the WNM Sleep Mode Response, Fast BSS Transition IE needs to carry GTK, IGTK, and BIGTK of other APs. My preference is that all three just use a single consistent way. In that sense, it is straightforward to follow the same
way done in KDE. Otherwise, too many variants of the ML element are needed for this simple usage scenarios. You know, FILS has not been discussed yet, if it is supported in MLO, Key Delivery element is also need to be updated...
Regards,
Yongho
2021년 1월 25일
(월)
오후 6:16, Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>님이
작성:
Hi Abhi,
I am supportive of your use of the ML element, I think it is more organized and provides a unified method of signaling ML parameters.
Regarding the below, I see that the baseline covers two cases: current GTK and pending GTK, I believe we should also capture the two cases for the other APs. Now for pending GTKs, not all APs’ GTKs may need to be updated at the same time, so we cannot assume that the ML element carries GTKs of all APs, as such the inclusion should be a “may”.
11.2.3.16.3 WNM sleep mode AP operation
…
An AP of an AP MLD may include the WNM Sleep Response variant of Multi-Link element in the WNM Sleep Mode Response frame to provide the GTK/IGTK/BIGTK information for link(s), that are part of the multi-link setup, other than the one where the frame was transmitted.
Best regards,
Rojan Chitrakar
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
|
|
|
|
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1