Re: Attempting to achieve consensus re. wwwivi issue (#223)

Hi Ted,

Please see below for my comments in blue

*>> What I think would help would be to have a better understanding on
why we might have multiple VISS and whether an application is expected
to communicate with more than one.*

Imagine the team creating the new 'Hi Line' Deluxe infotainment system
decide to include a VIS Server in the infotainment system. This system will
be released in 19 Model Year (MY) on *_some_ *vehicles only

Imagine also that  a few months later, the team that is responsible for
developing the Instrument Cluster decides to design a new cluster
'back-end' ECU to be used by *_all_* cluster designs (regardless of the
particular UI for a particular cluster) from 21 Model Year onwards, and
that they think that the W3C Spec and VIS Server idea is brilliant and so
decide to use a VIS Server running on the cluster ECU to obtain processed
signals

The Cluster team cannot use the Infotainment system VIS server because the
cluster will be in *all* vehicles but the Deluxe infotainment system will
only be in *some* vehicles.
The Infotainment team cannot use the VIS Server in the Instrument Cluster
because they want to launch in 19 MY and the Cluster won't be available
until 21 MY

In general, it's probably unlikely that a single App would try to connect
to both. More typically, would be an app installed on IVI ECU connects to
VIS Server on IVI and similarly an app on the cluster ECU connects to VIS
Server on the cluster - but it is possible that an App on some other ECU
might want to access one or other of them (via the vehicle's in-vehicle
ethernet network)

>> I'm not sure who proposed wwwivi initially but agree ivi in the name is limiting.
This service can be used by the dashboard, IVI, may be useful for things
like ADAS and RVI, data sampling for V2X or insurance. and
have apps connect from smartphones, tablets and other devices in the
vehicle.

If think wwwivi came out of a group discussion at one of the F2F meetings
(possibly the one in Portland)

*If as a group, we decide we want to specify a suggested default (and we
wanted the default to include w3.org <http://w3.org> or w3.org.local), we
could follow e.g. the following scheme:*

We could have a default naming scheme of either *<location>.<spec>.w3.org
<http://w3.org>* or *<location>.<spec>.w3.org.local * If we assume that
'w3.org.local' or 'w3.org' part is denoted by <suffix>, we could then have
suggested defaults like the following:

ivi.viss.<suffix>          to specify default value for VIS Server on IVI
ECU
cluster.viss.<suffix>   to specify default value for VIS Server on cluster
ECU
adas.ivi.<suffix>        to specify default value for VIS Server on adas ECU

<y>.ivi.<suffix>         to specify default value for VIS Server on <y> ECU
...

The same conceptual issue will affect 'finding' local RVI services - once
RVI is available, this could then have as defaults:

ivi.rvi.<suffix>          to specify default value for VIS Server on IVI ECU
cluster.rvi.<suffix>   to specify default value for VIS Server on cluster
ECU
adas.rvi.<suffix>        to specify default value for VIS Server on adas ECU

<y>.rvi.<suffix>         to specify default value for VIS Server on <y> ECU
...

Personally, I don't have a strong view on whether we include a suggested
default or not, but I would suggest that if we can't agree, we de-scope
this whole debate and simply state that "the implementer of a VIS Server
will document how to connect to the VIS Server". [Which could of course be
via a Discovery mechanism or by configuration]

[Unfortunately Adam and I will not be able to attend next months F2F, but
if it can't be resolved in github/email, it would be great if at the F2F
this could be made a priority - as it is the only issue preventing the spec
from moving forward...]

Regards,

Kev


*Kevin Gavigan BSc, MSc, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 24 October 2017 at 19:52, Ted Guild <ted@w3.org> wrote:

> Thank you Gunnar, some responses in-line.
>
> What I think would help would be to have a better understanding on why
> we might have multiple VISS and whether an application is expected to
> communicate with more than one.
>
> We should also try to envision the OEM app marketplace. Instead of
> trying to discover services for a given vehicle platform, the
> marketplace could provide configuration for that year, make and model
> on which service[s] a specific app is expected to interact with. This
> is what I meant earlier by provisioning.
>
> On Mon, 2017-10-23 at 12:18 +0200, Gunnar Andersson wrote:
> > On Sat, 2017-10-21 at 12:24 +0000, Peter Winzell wrote:
> > > I have consensus :). I completely agree with Kevin. Oems will
> > > follow and
> > > make their own choices and I think that there is high probability
> > > that if
> > > we specify a server name - whatever it might be - it will never be
> > > used.
> >
> > I wouldn't go that far.
> >
> > First, it would be a recommendation, in my opinion.
> >
> > Second I think standards do help, because in communication an OEM can
> > then
> > say "just follow the standard as written in chapter 5.6".  And some
> > will do
> > that.  It's not bad to have a default, and then if OEMs want to do
> > something
> > different, they specify that separately.
> >
> > I may have missed if it was given in discussions - if so could
> > someone
> > repeat for me the rationale for including "ivi" in the name?  The
> > specification isn't written to be IVI specific, is it?   I think if
> > the key
> > point is that it is a "local" server on the same computing unit as
> > the
> > application making the request, just indicate that.
>
> I'm not sure who proposed wwwivi initially but agree ivi in the name is
> limiting. This service can be used by the dashboard, IVI, may be useful
> for things like ADAS and RVI, data sampling for V2X or insurance. and
> have apps connect from smartphones, tablets and other devices in the
> vehicle.
>
> > Why not simply "viss"?   If it's a W3 subdomain, how about viss.w3 or
> > visslocal.w3... assuming it is the _recommended_ name for a locally
> > hosted
> > server?  (A simple poll would probably resolve the naming question)
>
> I like viss better but since VISS is to be followed shortly by RSI
> maybe something appropriate for either.
>
> Today's schedule got jumbled with others' meetings and my attempt to
> get time on decision from W3C regarding a hostname is pending.
>
> > Finally, I agree with where the discussion was going last time:
> >
> > First, these are separate things:
> >
> > 1) Chapter describing a recommended fixed name for a local VISS
> > server, (and
> > that the underlying system will likely translate it with a static IP
> > mapping).
> >
> > 2) Chapter describing the recommended local service name and the
> > usage of
> > mDNS discovery.  Including an impmlementation note to take great care
> > of
> > security issues, spoofing in particular.
> >
> > Second, the specification could include either one, two, or none of
> > these
> > chapters.  They could also be added at a later time.
> >
> > My vote would be to include chapter 1 now and a single sentence about
> > mDNS
> > discovery.  A separate instruction could be created to describe how
> > to
> > implement mDNS in this context.
>
> Until we understand the ramifications that would make sense.
>
> > More below.
> >
> > >
> > > lör 21 okt. 2017 kl. 04:26 skrev Gavigan, Kevin <kgavigan@jaguarlan
> > > drover.
> > > com>:
> > > > Hi Ted and Rudi,
> > > >
> > > > Thanks very much for your feedback - I guess we don't quite yet
> > > > have
> > > > consensus :-)
> > > >
> > > > [From Rudi:]
> > > > If I recall correctly we discussed a w3.org subdomain before. I
> > > > am not
> > > > sure why it got discarded at the time. However, I am strongly in
> > > > favor
> > > > of it. Let's move ahead with an Editors Draft with
> > > > a w3.org subdomain/hostname.
> >
> > When everyone feels they have made their arguments, create a poll on
> > the
> > name.  Also, getting some informal approval of the final proposal in
> > the
> > wider W3C community is an important part in my opinion.  I see little
> > that
> > must be unique to Automotive in the fundamental parts of this.
>
> Makes sense. I have no strong preference personally.
>
> > > > [From Ted]
> > > > Since there are cases that may have multiple VISS implementations
> > > > in the
> > > > same network, or have client devices introduced, discovery is
> > > > needed.
> >
> > That's one driver, but not the only one.  For me it would be more
> > that it's
> > the existing generic solution to discover a service if it's unknown
> > where it
> > is.   I wonder how realistically useful it is especially for multiple
> > servers.  In a particular car it seems kind of unlikely to me that
> > the
> > applications will (or even should) know what to do, if a lookup
> > yields
> > multiple VISS servers responding.  It opens up for a whole bunch of
> > rules/policies that need to be there - which server do they choose to
> > communicate with?  Try one, if it fails, try the next?  It just seems
> > to be
> > a whole other level of policy definition that this specification
> > should
> > probably not venture into.  It seems more likely to me that a
> > particular
> > application standard will provide a single (local) source of contact
> > - if a
> > more advanced system is needed, this could be funneled through a
> > server
> > acting as a proxy even.
> >
> > The end result for me is that a particular system will often fall
> > back onto
> > system-specific rules anyway (which means that specification could
> > even
> > include things like the name of the default server).
> >
> > > > I have the impression the TAG will block us if we do not have it
> > > > and
> > > > will accept a reasonable fallback default name that will be
> > > > usable in the simpler cases (one VISS service on a fixed
> > > > network).
> >
> > In my opinion that may still be enough.  Beyond that it's
> > implementation
> > dependent.
> >
> > > > Are their any suggestions how we can/should move forward?
> > > > Ted/Rudi is
> > > > their a statement or phrase or change that we could add that
> > > > achieve the
> > > > objectives you've succinctly outlined?
> > > >
> > > > If we can't find a technical consensus, to move forward, can we
> > > > de-scope
> > > > resolving the hostname and simply state that the implementer will
> > > > specify how to connect to the VISS server including how to
> > > > resolve the
> > > > <host_name>?
> > > >
> > > > [Although not ideal - believe this isn't quite as big a practical
> > > > problem as first appears: OEMs are very concerned about safety,
> > > > cybersecurity and integrity of the platforms they are creating.
> > > > As a
> > > > consequence, I believe that in practice client software that is
> > > > downloaded or included in the build for a particular OEMs
> > > > platform will
> > > > need to be carefully QA'd to ensure it works well on that
> > > > platform, and
> > > > is very likely to require some configuration information relating
> > > > to the
> > > > platform. So adding config info to specify how to connect to a
> > > > particular VIS Server or Discovery Service would typically be in
> > > > addition to other info. ]
> >
> > I partly agree.  I noted before that more than anything this is
> > likely part
> > of some "application standard", which might be widely adopted, or OEM
> > specific depending on what the industry wants.  (I have always wanted
> > to
> > work toward the former, but the OEMs are not clear enough on their
> > desire
> > there).  The scope of VISS specification isn't really an "Automotive
> > Web
> > Application Standard".  That would be some different specification it
> > seems
> > to me.
> >
> > That said, I could still see some value in W3C taking the first step
> > to
> > define one single recommended FQDN for the default VISS server.
> >
> > > >
> > > > Keen to hear the thoughts of the group re. how to move forward...
> >
> > To move forward I propose:
> >
> > - Set a deadline for further arguments to be brought forward.
> > - Then, list all the options for the spec.  See that we all agree on
> > the
> > list.
> > - Conduct a poll.
> >
> > I don't mean that guarantees a decision, but it's a clear step.  If
> > the poll
> > shows good consensus, it's easy to go ahead.  If it doesn't, perhaps
> > simple-
> > majority is not enough for a decision, but then I think a little more
> > discussion among those that disagree will eventually lead to a
> > compromise
> > and consensus.
> >
> > - Gunnar
> >
> >
> > > >
> > > > Thanks and regards,
> > > >
> > > > Kev
> >
> >
> > - Gunnar
> >
> > --
> > Gunnar Andersson <gandersson@genivi.org>
> > Development Lead
> > GENIVI Alliance
> >
> > > >
> > > > Kevin Gavigan BSc, MSc, PhD, MCP, MCTS
> > > > Software Architect
> > > > Connected Infotainment
> > > > Electrical, Electronic and Software Engineering (EESE)
> > > > Jaguar Land Rover
> > > >
> > > > Mobile: 07990 084866
> > > > Email: kgavigan@jaguarlandrover.com
> > > >
> > > > Office address:
> > > > GO03/057 • Building 523, Gaydon • Maildrop: (G03)
> > > > Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR
> > > >
> > > > On 21 October 2017 at 00:35, Streif, Rudolf <rstreif@partner.jagu
> > > > arlandr
> > > > over.com> wrote:
> > > > > Thank you Kevin and Ted. I really would like to put this to
> > > > > rest now
> > > > > and move on.
> > > > >
> > > > > If I recall correctly we discussed a w3.org subdomain before. I
> > > > > am not
> > > > > sure why it got discarded at the time. However, I am strongly
> > > > > in favor
> > > > > of it.
> > > > >
> > > > > Let's move ahead with an Editors Draft with a w3.org
> > > > > subdomain/hostname.
> > > > >
> > > > > Thanks,
> > > > > Rudi
> > > > >
> > > > > On Fri, Oct 20, 2017 at 11:36 AM, Ted Guild <ted@w3.org> wrote:
> > > > > > Part of the pushback on wwwivi even with .local is that it
> > > > > > amounts
> > > > > > to
> > > > > > name squatting. We do not own .local so cannot lay claim to a
> > > > > > name
> > > > > > there.
> > > > > >
> > > > > > Mark Nottingham asked if we considered a w3.org hostname as
> > > > > > the
> > > > > > fallback with discovery still being the preferred method.
> > > > > > Typically
> > > > > > I
> > > > > > have authority on w3.org subdomains but since it is for a
> > > > > > specification, would need to get Director approval.
> > > > > >
> > > > > > https://github.com/w3c/automotive/issues/233
> > > > > >
> > > > > > Since there are cases that may have multiple VISS
> > > > > > implementations in
> > > > > > the same network, or have client devices introduced,
> > > > > > discovery is
> > > > > > needed. I have the impression the TAG will block us if we do
> > > > > > not
> > > > > > have
> > > > > > it and will accept a reasonable fallback default name that
> > > > > > will be
> > > > > > usable in the simpler cases (one VISS service on a fixed
> > > > > > network).
> > > > > >
> > > > > > Discovery makes things complicated for client applications
> > > > > > and may
> > > > > > have
> > > > > > other negative implications such as introducing ways to
> > > > > > attack the
> > > > > > client. These would need to be worked through. We could
> > > > > > publish a
> > > > > > snapshot of the Editors Draft as a Working Draft with a
> > > > > > w3.org
> > > > > > hostname
> > > > > > (pending approval) while we figure out the discovery issues.
> > > > > >
> > > > > > On Fri, 2017-10-20 at 11:15 +0100, Gavigan, Kevin wrote:
> > > > > > > Hi Gents,
> > > > > > >
> > > > > > > As we know, issue #223 is the only open issue for the VIS
> > > > > > > Specification and it would be great if we could resolve it
> > > > > > > so that
> > > > > > > the Chairs could propose the the specification moves
> > > > > > > forward to a
> > > > > > > Candidate Recommendation.
> > > > > > >
> > > > > > > I've added the text copied in blue below to the issue (as
> > > > > > > part of
> > > > > > > trying to achieve consensus) and would be grateful for your
> > > > > >
> > > > > > feedback.
> > > > > > >
> > > > > > > We have been struggling for quite a few months to get
> > > > > > > agreement on
> > > > > > > how to resolve the hostname (wwwivi) issue (#223).
> > > > > > >
> > > > > > > Can I suggest that we resolve the impasse by saying that
> > > > > > > the
> > > > > > > implementer will document how the hostname is obtained, but
> > > > > >
> > > > > > suggest a
> > > > > > > default value for the VIS websocket server that is hosted
> > > > > > > on the
> > > > > >
> > > > > > IVI
> > > > > > > ECU.
> > > > > > >
> > > > > > > Hence, propose that we add statements like:
> > > > > > >
> > > > > > > /* Start of change */
> > > > > > >
> > > > > > > "A vehicle may have more than one VIS Server that can be
> > > > > > > accessed
> > > > > >
> > > > > > by
> > > > > > > a client running on an ECU connected to the in-vehicle
> > > > > > > network.
> > > > > > >
> > > > > > > The implementer of a VIS Server will document how an in-
> > > > > > > vehicle
> > > > > > > client can obtain the hostname that is needed to connect to
> > > > > > > their
> > > > > >
> > > > > > VIS
> > > > > > > Server instance. This could be using a Discovery Service
> > > > > > > (that is
> > > > > > > outside of the scope of this specification) or by
> > > > > > > configuration.
> > > > > > >
> > > > > > > By default, the VIS Server deployed on the In-Vehicle-
> > > > > > > Infotainment
> > > > > > > system will have the hostname 'ivi.w3.org.local' but the
> > > > > >
> > > > > > implementer
> > > > > > > may specify a different value'.
> > > > > > >
> > > > > > > /* End of change */
> > > > > > >
> > > > > > >
> > > > > > > We would then change our example statements to use
> > > > > >
> > > > > > 'ivi.w3.org.local'
> > > > > > > as hostname instead of wwwivi
> > > > > > >
> > > > > > > I'm not entirely sure that adding a '.local' extension to
> > > > > > > 'w3.org'
> > > > > > > doesn't violate other conventions, but logically it takes
> > > > > > > account
> > > > > >
> > > > > > of
> > > > > > > the feedback on the issue (of not cyber-squatting and
> > > > > > > making clear
> > > > > > > that its a local name)
> > > > > > >
> > > > > > > Believe that in practice an onboard client is likely to
> > > > > > > have a
> > > > > >
> > > > > > config
> > > > > > > file (or a Registry or similar) that can be used to define
> > > > > > > the
> > > > > > > runtime configuration, so if the default is not suitable or
> > > > > > > is not
> > > > > > > preferred, a different value can be configured prior to
> > > > > > > deployment
> > > > > >
> > > > > > of
> > > > > > > the client OR the client could make use of a Discovery
> > > > > > > Service if
> > > > > >
> > > > > > the
> > > > > > > implementer has stated in their documentation that this
> > > > > > > will be
> > > > > > > available.
> > > > > > >
> > > > > > > I didn't want to tightly couple the spec. to a particular
> > > > > >
> > > > > > Discovery
> > > > > > > protocol or mechanism (as these could evolve separately
> > > > > > > over time
> > > > > >
> > > > > > and
> > > > > > > couldn't think of a better compromise or route out of this
> > > > > > > issue -
> > > > > > > hope the group agrees to the above, but if it doesn't get
> > > > > >
> > > > > > consensus,
> > > > > > > very happy to consider other alternatives...
> > > > > > >
> > > > > > > [Hopefully, we can settle on this (or something like it)
> > > > > > > for now,
> > > > > >
> > > > > > and
> > > > > > > if there are strong views later about an alternative, we
> > > > > > > re-open
> > > > > >
> > > > > > the
> > > > > > > issue at that point]
> > > > > > >
> > > > > > > Thanks and regards,
> > > > > > >
> > > > > > > Kev
> > > > > > >
> > > > > > > Kevin Gavigan BSc, MSc, PhD, MCP, MCTS
> > > > > > > Software Architect
> > > > > > > Connected Infotainment
> > > > > > > Electrical, Electronic and Software Engineering (EESE)
> > > > > > > Jaguar Land Rover
> > > > > > >
> > > > > > > Mobile: 07990 084866
> > > > > > > Email: kgavigan@jaguarlandrover.com
> > > > > > >
> > > > > > > Office address:
> > > > > > > GO03/057 • Building 523, Gaydon • Maildrop: (G03)
> > > > > > > Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35
> > > > > > > 0RR
> > > > > >
> > > > > > --
> > > > > > Ted Guild <ted@w3.org>
> > > > > > W3C Systems Team
> > > > > > http://www.w3.org
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Rudolf J Streif
> > > > > System Architect - Open Source Initiative
> > > > > Open Source Technology Centre
> > > > >
> > > > > M: +1.619.631.5383
> > > > > Email:  rstreif@partner.jaguarlandrover.com
> > > > >
> > > > >
> > > > >
> > > > > UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon,
> > > > > Warwick, CV35
> > > > > ORR
> > > > > US: 1419 NW 14th Ave, Portland, OR 97209
> > > > > jaguar.com | landrover.com
> > > > > -------------------
> > > > > Business Details:
> > > > > Jaguar Land Rover Limited
> > > > > Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
> > > > > Registered in England No: 1672070
> > > > >
> > > > > This e-mail and any attachments contain confidential
> > > > > information for a
> > > > > specific individual and purpose.  The information is private
> > > > > and
> > > > > privileged and intended solely for the use of the individual to
> > > > > whom
> > > > > it is addressed.  If you are not the intended recipient, please
> > > > > e-mail
> > > > > us immediately.  We apologise for any inconvenience caused but
> > > > > you are
> > > > > hereby notified that any disclosure, copying or distribution or
> > > > > the
> > > > > taking of any action in reliance on the information contained
> > > > > herein
> > > > > is strictly prohibited.
> > > > >
> > > > > This e-mail does not constitute an order for goods or services
> > > > > unless
> > > > > accompanied by an official purchase order.
> > > > >
> > > > >
> > > >
> > > >
> >
> >
> --
> Ted Guild <ted@w3.org>
> W3C Systems Team
> http://www.w3.org
>