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

Sorry, there is a cut and paste error

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

should read:

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

[And of course that whole section should be in blue]

Cheers,

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 25 October 2017 at 15:41, Gavigan, Kevin <kgavigan@jaguarlandrover.com>
wrote:

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