Re: Answers to chat comments

 >>   the good thing being that your flexible approach also allows for the
implementation to be (flexible) restrictive?
Yes. VIWI level is achieved by one line of YAML code.
BR
Ulf

On Wed, Feb 5, 2020, 18:40 Winzell, Peter <peter.winzell@volvocars.com>
wrote:

> 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 ok ?
>
>
>
> /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>
> 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>
> *Date: *Wednesday, February 5, 2020 at 4:43 AM
> *To: *"Adnan.Bekan@bmwgroup.com" <Adnan.Bekan@bmwgroup.com>
> *Cc: *public-automotive <public-automotive@w3.org>
> *Subject: *Re: Answers to chat comments
> *Resent-From: *<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> 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
> <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>
> *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
> <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
>
>