Hi Graham,
Yes, I already made the comments on “what is the comparable security
and privacy”? during the call yesterday. The proposed text force the
AP vendor must find a solution like Annex Z did. I’m not sure how
other AP vendor think it about.
Further, we don’t have any consensus on the device ID carried in the
unencrypted frame. I think we need a SP on this part before we talk
the resolution.
Hi Mark,
I hope we could focus on the comment itself and move forward, the
commenter says:
“I guess I'm in general a bit confused as to whether "the identifier"
is always an "opaque identifier" as in Annex Z, or whether there are
different identifiers defined in subclause 12.2.11. Adding a sentence
on identifiers would help, perhaps along the lines of "An opaque
identifier can be constructed by the network according to the example
procedure in Annex Z, but an identifier can also be differently
constructed by a mechanism chosen by the network." I guess the non-AP
STA would not technically need to be concerned with how the identifier
is constructed.”
The proposed resolution should be like “An device ID can be
constructed by the network according to the example procedure in Annex
Z, but it can also be differently constructed by a mechanism chosen by
the network, the device ID should be opaque over the air”
But your proposed resolution is beyond what the commenter’s comment.
If someone have other intention on this, we could address it in the
next round on a dedicated CIDs.
Thanks
Best Regards
Jay Yang
*From:* G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
*Sent:* 2023年4月12日 5:05
*To:* STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
*Subject:* Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS:
Agenda uploaded - plans for call)
Hi Mark,
I think you are close.
As we have not had any other proposals for an “opaque” ID scheme, and
I think we may get comments on “what is the comparable security and
privacy?”; maybe we make it a little stronger in Annex Z’s favor?
How about changing last sentence to simply read:
“In such cases, the procedure in Annex Z may be used to protect the
device identification within a Device ID.”
I am sure you will get other ideas, but thought I might kick it off.
Graham
*From:* Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
*Sent:* Tuesday, April 11, 2023 2:13 PM
*To:* STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
*Subject:* [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda
uploaded - plans for call)
All,
At risk of stepping into the fire again, here is another suggested
approach to our language introducing the Annex Z procedure. My intent
is to provide enough context to explain why this is used/useful.
* Insert a new paragraph at the end of 12.2.11.1 (subclause
numbering per 11-23/0129r4): “When it is desirable to use a device
identification which is relatively permanent, for example an
identification that has external meaning (a username, account
number, etc.), and the Device ID carrying the device
identification might be communicated without encryption, it is
necessary that the Device ID keep the device identification
private (“opaque”) from third-parties. In such cases, the
procedure in Annex Z, or any procedure that affords comparable
security and privacy, can optionally be used to protect the device
identification within a Device ID.”
Comments?
Mark
*From:* Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>
*Sent:* Monday, April 10, 2023 11:38 PM
*To:* STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
*Subject:* Re: [STDS-802-11-TGBH] Agenda uploaded - plans for call
Hi Dan,
Thanks for the comments.
I quickly check the gramma, I see “opaque” can be adj., verb or noun.
I think current agreement is that the device ID is encrypted in the
frame, and thus the device ID become opaque in the air.
It’s due to the implementation on how the network generate the device
ID, one example is the annex Z. That’s all.
We don’t need to stress “a different mechanism that provides it
affords comparable security and privacy”, even the network generates a
device ID like 111,222,333,etc. it’s still safe as this part is encrypted.
I don’t understand what’s the meanings of “opaque identifier when it’s
constructed from Annex Z”, do you intend to say “double opaque”(
opaque identifier + encryption) for the 3^rd party?
Thanks
Best Regards
Jay Yang
*From:* Harkins, Dan <daniel.harkins@xxxxxxx>
*Sent:* 2023年4月11日 12:35
*To:* Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>;
STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
*Subject:* Re: [STDS-802-11-TGBH] Agenda uploaded - plans for call
Hi Jay,
"opaque" is not a verb, it's an adjective. I think this sentence is
better:
"An opaque identifier can optionally be constructed by the network
using the procedure in
Annex Z or can employ a different mechanism provided it affords
comparable security and privacy."
and if people are getting hung up on the word opaque we can add a
definition of it for the terms portion of the amendment.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 4/10/23, 6:21 PM, "Zhijie Yang (NSB)" <zhijie.yang@xxxxxxxxxxxxxxx>
wrote:
Hi Mark,
For CID35, I like what the commenters suggested sentence, and thus we
can add one Note to say:
Note1: An device ID shall be constructed by the network, e.g., the
example procedure in Annex Z, in which the device ID is opaqued over
the air to the 3^rd party.
Thanks
Best Regards
Jay Yang
*From:* Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
*Sent:* 2023年4月11日 6:55
*To:* STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
*Subject:* [STDS-802-11-TGBH] Agenda uploaded - plans for call
All,
Just a note that I have uploaded my proposed agenda for the TGbh call
Tuesday morning (U.S. time): 11-23/0621r0
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mentor.ieee.org_802.11_dcn_23_11-2D23-2D0621-2D00-2D00bh-2Dagenda-2Dtgbh-2D2023-2Dapril-2D11.pptx&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOirz2RA_bah_KFKOseb8&m=ljoUTvDs00q41Rd0a7MvJC_zqgc8hF9b22GsKPZysMs&s=DlF7yEtUaM-kOD0978dZVKSufR1c2r2iuOZrY6BteBc&e=>.
My general plan/approach is:
-Review the latest updates to the IRM proposal that we’ve been
discussing, and see if we agree the requested updates are done and we
can reach consensus on this way forward.
-Review the proposal from Okan on PASN (with Device ID). Is there
consensus to add this material? (I believe that between Graham’s IRM
updates for PASN, and/or this proposal for PASN, we now cover CIDs 19
and 20.)
-Review/discuss my suggestions for CID 35. ( @Dan Harkins
<mailto:daniel.harkins@xxxxxxx> and @Amelia Anna Matilda Katarina
Andersdotter <mailto:amelia.ieee@xxxxxxxxxxxxxxx>, if you can be on
the call to help us conclude on these, it would be helpful, thanks!)
-Based on the outcome of the above, give instructions to produce the
updated comment resolutions list that we can motion next week.
I am hopeful that the above discussions can reach consensus on the
call, and our motion next week will be able to close off all the open
comments, and Carol can get going on an updated draft.
If anyone has concerns with the resolutions above, please prepare your
thoughts for a discussion tomorrow that will get us to a conclusion.
Thanks. Mark
------------------------------------------------------------------------
To unsubscribe from the STDS-802-11-TGBH list, click the following
link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOirz2RA_bah_KFKOseb8&m=ljoUTvDs00q41Rd0a7MvJC_zqgc8hF9b22GsKPZysMs&s=HK__8xeBWujj6bQ0D1xBDGK9dGhmyjxHeD1LhAxxLtE&e=>
------------------------------------------------------------------------
To unsubscribe from the STDS-802-11-TGBH list, click the following
link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOirz2RA_bah_KFKOseb8&m=ljoUTvDs00q41Rd0a7MvJC_zqgc8hF9b22GsKPZysMs&s=HK__8xeBWujj6bQ0D1xBDGK9dGhmyjxHeD1LhAxxLtE&e=>
------------------------------------------------------------------------
To unsubscribe from the STDS-802-11-TGBH list, click the following
link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOirz2RA_bah_KFKOseb8&m=ljoUTvDs00q41Rd0a7MvJC_zqgc8hF9b22GsKPZysMs&s=HK__8xeBWujj6bQ0D1xBDGK9dGhmyjxHeD1LhAxxLtE&e=>
------------------------------------------------------------------------
To unsubscribe from the STDS-802-11-TGBH list, click the following
link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
<https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1>
------------------------------------------------------------------------
To unsubscribe from the STDS-802-11-TGBH list, click the following
link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
<https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1>
------------------------------------------------------------------------
To unsubscribe from the STDS-802-11-TGBH list, click the following
link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1