Re: Answers to chat comments

>> 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