Automotive Working Group recharter

[tguild]

New charter proposal, reviewers please take note. Existing charter expires soon: 31 December 2020

Charter Review

[Charter:] https://w3c.github.io/automotive/planning/charter-2020.html

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• Existing

• Existing WG recharter
• If this is a charter extension or revision, link a diff from previous charter, and any issue discussion:

Horizontal Reviews ...

Communities suggested for outreach:

Known or potential areas of concern?:

Where would charter proponents like to see issues raised? (github preferred, email, ...)

w3c/automotive#349

Anything else we should think about as we review?
Spatial Data on the Web Working Group recharter

[michael-n-cooper]

APA WG asks that the boilerplate from the charter template be included:

Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.

This may apply primarily to the proposed primer or best practices document, but could apply to normative specs as well.

APA review complete, over to @brewerj to complete accessibility horizontal review.

[tguild]

thanks @michael-n-cooper I have added that text

[himorin]

no comment/suggestion from i18n.

note/background: i18n-aware data format/presentation would be taken into account in relying data format, and there might be little space for cultural dependent consideration. / There is a standard text for horizontal review in coordination section.

[samuelweiler]

Cleaned up template; removed HR checkboxes consistent with Start team discussion.

[samuelweiler]

Charter diff

[samuelweiler]

I opened 10 issues in the WG's repo. 7 are editorial. One is about clarity of scope, and two are general questions about sensitive data protection and RPC authorization. I wonder if the latter two would be better tackled with a comprehensive architectural document(s) rather than in individual specs. And I suspect the WG should do that broader architectural work before digging into the data specs. I think we need to resolve these questions before rechartering the WG.

Further, I'm concerned about how relatively quiet the WG's repo appears to be, especially noting that we're dropping to one chair. Maybe I'm missing other repos, but is there enough energy to get the work done?

[michael-n-cooper]

Thanks @tguild APA is now happy with this charter, over to @brewerj to complete accessibility horizontal review.

[tguild]

@samuelweiler per Strategy call where you took objection to my naming organizations instead of individuals as prospective additional chairs, in discussion to get additional. Are we being impersonal now in quantity over quality? Regarding additional repos, yes another dedicated to the long drawn out member submission https://github.com/w3c/vsso and three GENIVI ones which are directly related to W3C Auto WG. https://github.com/GENIVI/vehicle_signal_specification/ https://github.com/GENIVI/vehicle_service_catalog https://github.com/GENIVI/vss-tools

Unsure how to address in a charter authorization mechanisms for an as yet drafted spec.

The privacy considerations raised also strike me as specification specific more than a charter topic. w3c/automotive#358

[samuelweiler]

@samuelweiler per Strategy call where you took objection to my naming organizations instead of individuals as prospective additional chairs, in discussion to get additional. Are we being impersonal now in quantity over quality?

No. I was trying to read tea leaves about energy in/for the group. I'm happy to be told that there is energy (and implicitly that the tea leaves are misleading - or just outright unreliable).

Unsure how to address in a charter authorization mechanisms for an as yet drafted spec.

I think we addressed this in w3c/automotive#359

The privacy considerations raised also strike me as specification specific more than a charter topic. w3c/automotive#358

Retrofitting privacy onto a system is even harder than retrofitting security - privacy-by-design will be moe successful. Given that, in w3c/automotive#358 I propose that the WG start with a high-level architecture doc. That might be spec-specific, but I imagine a comprehensive approach will be better.

[samuelweiler]

..., in w3c/automotive#358 I propose that the WG start with a high-level architecture doc. That might be spec-specific, but I imagine a comprehensive approach will be better.

@tguild asked for some examples of architecture documents.

RFC4101 offers some excellent advice on Writing Protocol Models, starting with advice to simplify. It has several in-line examples. I suggest starting there.

Here are some imperfect (and probably far too long) examples from the IoT space:

• Section 5 of the SUIT architecture seems like it's at the right level. I take issue with some details in that doc, but that section, in particular, is a good example.
• The TEEP architecture document is much too long, but it also looks like the right level, especially the Architecture section.

I may supplement this list as I find examples that are more on-point and focused on the collection of data.

[tguild]

I shared a CCS diagram with Sam on a call which demonstrates one of several possible information flows of which the work at W3C is only one part of. Also in the diagram are ISO ExtVeh/Neutral Server, GENIVI, AutoSAR and things like vanilla GraphQL.

https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=44859735&preview=/40402952/47711462/communication-architecture-draft-CCS.pdf

There are scenarios where no raw data leaves vehicles, either remains on vehicle or an assessment based on the data might. An architecture document of the W3C protocol by itself would not show any data necessarily leaving the vehicle, that depends on where the protocol is running, whether it is connected to from outside the vehicle or if purely vehicle side whether the client application is allowed to send anything off.

As the issue raised is centered on handling of sensitive information, I gather big picture is preferred @samweiler ?

Re section 5 of SUIT, I am reminded of a line from a former W3C colleague.

"This calls for ascii art" - Alan Kotok

[samuelweiler]

As the issue raised is centered on handling of sensitive information, I gather big picture is preferred @samweiler ?

Assuming you were addressing me, and not @samweiler...

Yes. As in RFC4101, "Less is more" and "Abstraction is good".

Re section 5 of SUIT, I am reminded of a line from a former W3C colleague.

"This calls for ascii art" - Alan Kotok

Very much so. Again from RFC4101:

Our experience indicates that it is easiest to grasp protocol models
when they are presented in visual form.  We recommend a presentation
format centered around a few key diagrams, with explanatory text for
each.  These diagrams should be simple and typically consist of
"boxes and arrows" -- boxes representing the major components, arrows
representing their relationships, and labels indicating important
features.

Alan's version is more concise.

[wseltzer]

@tguild Could you please include reference to a non-normative architecture description or diagram to facilitate understanding of the privacy considerations? The goal is to make sure reviewers have enough information to make reasoned consideration, not to pick a privacy requirement or mitigation at the chartering stage.

[tguild]

@wseltzer there isn't one but group agreed to produce an architecture of information flows at @samuelweiler request, documenting several of the likely flows that our spec could be used in.

[samuelweiler]

@wseltzer there isn't one but group agreed to produce an architecture of information flows at @samuelweiler request, documenting several of the likely flows that our spec could be used in.

As I ask over in w3c/automotive#358 (comment), will that architecture make it clear at what layer(s) in the technology stack privacy controls can be usefully applied, possibly (hopefully!) including giving the owner and/or operator will have control(s) over the collection of data? (This question is a modified version of what I proposed earlier.)

[samuelweiler]

RPC auth issue is resolved. Two clarity issues remain: w3c/automotive#357 and w3c/automotive#352

[dontcallmedom]

rechartered