Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 - 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 […]" - Traffic filter sets are MLD-wide, not per-link, right? - 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" - I think "setup links" should be just "links", since if the link is not set up it does not exist - "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 - "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 - "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 " - "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) 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> 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, From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
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>
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>
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, From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
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>
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>
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>님이
작성:
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 |