Re: Answers to chat comments

Hi,
Error prone was perhaps not the write word. I think that imposing a read only restriction on a node above can be confusing at times if it is then allowed to write further down. The solution being of course to allow read/write and then restrict further down…but still. The perception of a tree of this sort being that some nodes are not created equal, and that read/write is the benefits of the more privileged. However, I think I am confusing my roles as user of the API (the developer) and implementor of the spec.

I think I am leaning towards of more simplistic solution as in VIWI , the good thing being that your flexible approach also allows for the implementation to be flexible ?

/pw



From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
Date: Wednesday, February 5, 2020 at 9:21 AM
To: "Winzell, Peter" <peter.winzell@volvocars.com>
Cc: "Adnan.Bekan@bmwgroup.com" <Adnan.Bekan@bmwgroup.com>, public-automotive <public-automotive@w3.org>
Subject: Re: Answers to chat comments

See inline answers.
BR
Ulf
On Wed, Feb 5, 2020, 17:57 Winzell, Peter <peter.winzell@volvocars.com<mailto:peter.winzell@volvocars.com>> wrote:
Hi,

One question: If you have read only above a node in the tree which you would then supersede with a value below with a write also, would that be allowed ? I guess the question has to be yes …
Yes.
but could that not lead to the solution being error prone from a developers perspective ?
Could you elaborate?

Another general question is where the modification of VSS actually fits in the specification ? If someone wants a different model should these requirements be mandatory – I think not.
I think. If not, would that not lead to interop problems?
I believe that the VIWI static read-write solution is valid , although I would prefer a more flexible proposal of tags (if practical).

/pw



From: Ulf Bjorkengren <ulfbjorkengren@geotab.com<mailto:ulfbjorkengren@geotab.com>>
Date: Wednesday, February 5, 2020 at 4:43 AM
To: "Adnan.Bekan@bmwgroup.com<mailto:Adnan.Bekan@bmwgroup.com>" <Adnan.Bekan@bmwgroup.com<mailto:Adnan.Bekan@bmwgroup.com>>
Cc: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: Re: Answers to chat comments
Resent-From: <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Resent-Date: Wednesday, February 5, 2020 at 4:42 AM

>> 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<mailto: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<mailto:adnan.bekan@bmwgroup.com>
Web: http://www.bmwgroup.com<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bmwgroup.com%2F&data=02%7C01%7Cpeter.winzell%40volvocars.com%7Ca676ccde3987497597e508d7aa5fddab%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637165201030152132&sdata=0u9snz5Juwe%2F%2B8P7APzuFFhIBNilejqYWB7dEgh1WqM%3D&reserved=0>
--------------------------------------------------------------------
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<mailto:ulfbjorkengren@geotab.com>>
Date: Wednesday, 5. February 2020 at 11:42
To: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: Answers to chat comments
Resent-From: <public-automotive@w3.org<mailto: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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.geotab.com%2F&data=02%7C01%7Cpeter.winzell%40volvocars.com%7Ca676ccde3987497597e508d7aa5fddab%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637165201030162127&sdata=n1TfsCtGTkOGV2PFH9ltJJrnf2nsgz6%2B03A31whUgnY%3D&reserved=0>
 Hi