Re: [STDS-802-11-TGAQ] ARC/TGaq architecture diagrams

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

On 23 September 2016 at 08:44, Stephen McCann <mccann.stephen@xxxxxxxxx> wrote:

Mark,
       thanks for the comments. I have some suggestions below, but in addition I suggest that we have another TGaq session in November, where we invite ARC along (not necessarily a joint meeting) to go over the diagrams again.

Kind regards

Stephen

On 22 September 2016 at 16:40, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
Hi, Stephen,

A couple comments:
-        We talked about making the outline shapes for the SIR, ANQP Server, Services, etc use dashed lines. I see you only did that for the Application (on the client). Is that intentional, and if so, what is the thinking/meaning?
[SM: No, I simply forgot to change the line type on the shapes !]
-        On the unsolicited procedure, I think it is incorrect that the Services are connected to the AP. I think the Services and SIR labels should be reversed.
[SM: Yes, that's a typo]
-        On the solicited procedure, I think the (solid) arrow between STA and AP should be double-arrow-ended.
[SM: Yes]
-        I’m struggling a bit with not showing the “footprint” of services inside the AP and STA (the “database” of cached information, some active element in the AP (SME) talking to the SIR/ANQP and similarly in the STA (SME) – this last one being the SIC by definition, I think. Mostly, it is the asymmetry of the drawing’s positioning of the SIC and SIR that is bothering me, and might be helped if it was more clear that there are symmetrical elements on the STA and AP, plus the additional stuff further back in the infrastructure backend.
[SM: In Warsaw, we discussed whether a second diagram of the internals of the AP (and STA) may be useful. Perhaps we're going back to that issue again?]
-        A question, is it correct that the AP never talks directly to the SIR in the solicited case? On review of Draft 11aq D6.0, in 4.5.9.1.4 it says, “The [discovering STA’s] SME determines whether to use unsolicited PAD, solicited PAD or ANQP.” which I find a bit confusing, like there are three modes. And 11.25a.3 is (probably intentionally) vague on exactly how the AP responds to ANQP-based requests.
[SM: I think we should leave this as a discussion for November]
-        We didn’t discuss this in Warsaw, but it occurs to me that the “STA” is really a “non-AP STA” (necessarily – right?). Should we label it as such?
[SM: I think this is correct, although ANQP is a symmetrical protocol, so do we want to make it uni-directional for 11aq?]

Mark

From: *** 802.11 TGaq - Preauthentication Discovery *** [mailto:STDS-802-11-TGAQ@ieee.org] On Behalf Of Stephen McCann
Sent: Thursday, September 22, 2016 1:26 AM
To: STDS-802-11-TGAQ@xxxxxxxxxxxxx.ORG
Subject: Re: [STDS-802-11-TGAQ] ARC/TGaq architecture diagrams

Dear all,
           I've uploaded a revision of the diagrams, which have been converted into MSVisio (ask me for the original art-work if you need it):

<https://mentor.ieee.org/802.11/dcn/16/11-16-1006-04-00aq-figure-4-11-update.ppt>
Kind regards
Stephen

On 19 September 2016 at 09:00, Stephen McCann <mccann.stephen@xxxxxxxxx> wrote:
Dear all,
           I've captured the diagrams that came out of the ARC/TGaq meeting last week at the IEEE 802.11 F2F in Warsaw:

<https://mentor.ieee.org/802.11/dcn/16/11-16-1006-03-00aq-figure-4-11-update.ppt>
Please note these figures have not been approved and are only suggestions at this point in time.
Kind regards
Stephen

_______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-tgaq and then press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.