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

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.

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)

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.

More below.

> 
> lör 21 okt. 2017 kl. 04:26 skrev Gavigan, Kevin <kgavigan@jaguarlandrover.
> 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.

> > 
> > [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.jaguarlandr
> > 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.
> > > 
> > > 
> > 
> >

Received on Monday, 23 October 2017 10:19:19 UTC