- From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
- Date: Wed, 5 Feb 2020 13:42:43 +0100
- To: Adnan.Bekan@bmwgroup.com
- Cc: public-automotive <public-automotive@w3.org>
- Message-ID: <CAHfMbK-vfTYP27nDyoYi5mM-YfNmgb-x1YiWYQ4O58NXzda9Zw@mail.gmail.com>
>> How would you keep 3 different scenarios in parallel, T1, T2, T3 with C1 C2 and C3? Only one of the scenarios A, B, or C is possible at a given time. >> In proposal we have option to specify only 1 Tag, for actuator, sensor or branch. I did not understand how to handle several Tags per actuator for varipus clients. A tag is inherited by underlying nodes, unless a different tag exists in a node. In the scenario I described, a tag was added to the vehicle.cabin.door branch node, thus all leaf nodes below it inherited the tag property. It is only possible to assign one tag per node. >> Proposal would work if we would have only 1 client. Please explain why it would not work as described in the scenarios. >> As well how to handle complexity users x tags x paths? With flexibility comes some level of complexity, that is unavoidable. If flexibility is not a desired feature, then the VIWI model could be applied, and all nodes are statically assigned read-write access restriction, i. e. every client request must contain a valid token. Then this tag design can be scrapped. BR Ulf On Wed, Feb 5, 2020 at 12:02 PM <Adnan.Bekan@bmwgroup.com> wrote: > >> how flow would look like for 4 diff clients, with tag read, write only, > read/write and "no tag", and they would access to exactly same branch > vehicle.cabin.door. Story with tokens I understand and all good, but with > tags I did not see any additional benefit. > > Excluding the write-only case, the following I believe shows the benefits > it can provide. > > The vehicle.cabin.door branch node has three different tagging options: > > T1: No tag > > T2: Validate: write-only > > T3: Validate: read-write > > The three clients have respectively: client 1:no token,client 2: > read-only token, client 3: read-write token (tokens have a scope containing > this subtree, and are non-expired). > > A: For the T1 scenario all clients are able to both read and write the > leaf nodes of the subtree. > > B: For the T2 scenario clients 1 and 2 can read leaf nodes, client 3 can > both read and write leaf nodes. > > C: For the T3 scenario client 1 can neither read nor write any leaf nodes, > client 2 can read leaf nodes, and client 3 can both read and write leaf > nodes. > > ----------- > > How would you keep 3 different scenarios in parallel, T1, T2, T3 with C1 > C2 and C3? In proposal we have option to specify only 1 Tag, for actuator, > sensor or branch. I did not understand how to handle several Tags per > actuator for varipus clients. Proposal would work if we would have only 1 > client. As well how to handle complexity users x tags x paths? > > > > Thank you > > > > -- > > *BMW Group* > > Adnan Bekan > > Research, New Technologies, Innovations > > E/E Architecture, Technologies (LT-3) > > IoT and Software Technologies > > > > Parkring 19, 85748 Garching > > > > Telefon: +49-89-382-56368 > > Mobile: +49-151-601-56368 > > Mail: adnan.bekan@bmwgroup.com > > Web: http://www.bmwgroup.com > > -------------------------------------------------------------------- > Bayerische Motoren Werke Aktiengesellschaft > Vorstand/Board of Management: Oliver Zipse (Vorsitzender/Chairman), > > Klaus Fröhlich, Ilka Horstmeier, Milan Nedeljković, > > Pieter Nota, Nicolas Peter, Andreas Wendt. > > Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Norbert > Reithofer > > Sitz und Registergericht/Domicile and Court of Registry: München HRB 42243 > -------------------------------------------------------------------- > > > > *From: *Ulf Bjorkengren <ulfbjorkengren@geotab.com> > *Date: *Wednesday, 5. February 2020 at 11:42 > *To: *public-automotive <public-automotive@w3.org> > *Subject: *Answers to chat comments > *Resent-From: *<public-automotive@w3.org> > *Resent-Date: *Wednesday, 5. February 2020 at 11:38 > > > > >> how flow would look like for 4 diff clients, with tag read, write only, > read/write and "no tag", and they would access to exactly same branch > vehicle.cabin.door. Story with tokens I understand and all good, but with > tags I did not see any additional benefit. > > Excluding the write-only case, the following I believe shows the benefits > it can provide. > > The vehicle.cabin.door branch node has three different tagging options: > > T1: No tag > > T2: Validate: write-only > > T3: Validate: read-write > > The three clients have respectively: client 1:no token,client 2: > read-only token, client 3: read-write token (tokens have a scope containing > this subtree, and are non-expired). > > A: For the T1 scenario all clients are able to both read and write the > leaf nodes of the subtree. > > B: For the T2 scenario clients 1 and 2 can read leaf nodes, client 3 can > both read and write leaf nodes. > > C: For the T3 scenario client 1 can neither read nor write any leaf nodes, > client 2 can read leaf nodes, and client 3 can both read and write leaf > nodes. > -- Ulf Bjorkengren *Geotab* Senior Connectivity Strategist | Ph. D. Mobile +45 53562142 Visit www.geotab.com
Received on Wednesday, 5 February 2020 12:42:54 UTC