- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Sun, 12 Apr 2020 13:50:04 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/04/02-wot-arch-minutes.html
also as text below.
Thanks a lot for taking the minutes, Zoltan!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Architecture
02 Apr 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Call 1: Kaz_Ashimura, Kunihiko_Toumura, Michael_Lagally,
Taki_Kamiya, Tomoaki_Mizushima, Zoltan_Kis
Call 2: Kaz_Ashimura, Elena_Reshetova, Michael_Lagally,
Michael_McCool, Zoltan_Kis, Kunihiko_Toumura,
Ryuichi_Matsukura, David_Ezell, Taki_Kamiya
Regrets
Chair
Lagally
Scribe
kaz, zkis
Contents
* [3]Topics
1. [4]Call 1
1. [5]Review minutes
2. [6]Use cases
3. [7]Pullrequests
4. [8]Terminology
5. [9]Transportation use case
2. [10]Call 2
1. [11]Past minutes
2. [12]lifecycle discussion
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
Call 1
scribenick: kaz
Review minutes
<mlagally> If you have a few mins and want to have fun:
[15]https://youtu.be/DYu_bGbZiiQ
[15] https://youtu.be/DYu_bGbZiiQ
[16]Mar-26
[16] https://www.w3.org/2020/03/26-wot-arch-minutes.html
Lagally: (goes through the minutes)
... discussion with Chris as well
... any objections to approve the minutes?
(none)
Lagally: approved
Use cases
Lagally: split into 2 pieces
... call 1: agriculture and transportation
... call 2: lifecicle (including Zoltan and Elena) and health
monitoring
Pullrequests
[17]475
[17] https://github.com/w3c/wot-architecture/pull/475
Lagally: (goes through the changes)
[18]gitio draft
[18] https://w3c.github.io/wot-architecture/
Lagally: 8.2 WoT RUntime
... (go back to the changes within pullrequest 475)
... references to docs
... lifecycle diagram
... comparison
... bootstrapping
... would like to merge this
[19]Elena's diagram
[19] https://github.com/w3c/wot-architecture/blob/master/proposals/WoT lifecycle diagram-WoT new lifecycle.svg
[20]Lagally's diagram on unified device
[20] https://github.com/w3c/wot-architecture/blob/master/proposals/unified device lifecycle.svg
Lagally: sequence diagrams are useful here
... bootstrap, onboard, activate, offboard, decommission,
destroy
... 2nd diagram: bootstrap, register, discover, onboard,
activate, use, deactivate, offboard, deregister, decommission,
destroy
... don't want to go into the detail
... but just wanted to show the reource for call 2
Terminology
[21]Pullrequest 454
[21] https://github.com/w3c/wot-architecture/issues/454
Lagally: proposed term definition from the architecture call
last week:
Proposal:
A Thing Description Template (TDT) is a description for a class
of Things that have the same capabilities.
It describes the properties, actions, events and common
metadata that are shared for an entire group of Things. A TDT
does not contain enough information to identify or interact
with a Thing instance.
(potentially add the following: Note: A TD is an instance of
one or more TDTs.)
]]
Zoltan: scripting-specific
Lagally: we have a couple of proposed teminology definitions
Zoltan: subest of TD?
Lagally: yes
... should have discussion during the TD call as well
Zoltan: TD fragments should be also valid TDs
Lagally: right that's not arbitrary string
... going to write another proposal
... (proposal based on the discussion today, April 2)
... Partial TD = subset of TD that is valid JSON-LD. It uses
Taki: what would be the whole set given a "subset"?
... not sure about the concept of "set" here
Zoltan: a document is a set
... should have discussion during the TD call
... we should keep the use case descriptions here, though
[22]SSML 1.1
[22] https://www.w3.org/TR/speech-synthesis11/#S2.2.1
Kaz: we might want to look at the definition of "fragment" from
XML-based specs like SSML above
... that implies we might want to have some clear schema
definition for "TD fragment" as well
Zoltan: there is no concrete definition within the spec text,
though
Lagally: how about "subse of a TD data model" which doesn't
require all mandatory keywords
Kaz: do you mean "all the mandatory keywords of the TD"?
Lagally: right
... (adds clarification for that)
... and "a partil TD is used as a search pattern for discovery"
Zoltan: maybe we should discuss this during the TD call
... but OK with this for now
Lagally: ok
... (and save the defitnion as a comment
Transportation use case
[23]Pullrequest 470
[23] https://github.com/w3c/wot-architecture/pull/470
<mlagally> Zoltan, we cannot hear you
Zoltan: this is just a first draft
... not sure how to split this up
... a lot of concrete use cases are included here
... public transport by bus, flight cargo, etc.
Lagally: this use case does include good points
... what would be the expected data model?
Zoltan: this is just a use case
... needs reviewers to improve it
... help from you all would be helpful
Kaz: we can consider this use case as a meta business-oriented
use case which inspire us to generate several concrete use
cases deribed from this
Lagally: right
... this is a use case on some vertical
Kaz: "vertical" could be a possible term for this purpose :)
Lagally: (adds comments on the discussion so far to the
pullrequest)
Zoltan: would like to get a second round for this
Lagally: cargo is ship, airroad, rail and last mile
... stakeholders are very different companies, however, hared
identifiers for packages, source and target location are
desirable
... shipping options like dangerous goods, priority
Zoltan: would somebody to review this use case once
... to get better understanding for this
... can mention that within the pullrequest itself
Lagally: ok
... just wanted to capture our points during this call
... assign a reviewer?
... Benjamin for vehicle use case?
Zoltan: sounds good
Lagally: and people on this call?
... Singapore govtech guys are also expected
... (assigns people from the WoT WG to the pullrequest as
reviewers)
Kaz: note that we're already at the end of the hour
Lagally: ok
... let's talk about the agriculture use case next week
Taki: would like to make contribution to another use case on
healthcare
Lagally: great
... aob?
(none)
Lagally: let's continue the discusion during call 2
[24]call 2 time
[24] https://lists.w3.org/Archives/Member/member-wot-wg/2020Feb/0030.html
[call 1 adjourned]
__________________________________________________________
Call 2
scribenick: zkis
Past minutes
Lagally: past minutes presented in call 1, no objections
[past minutes approved]
<kaz> [25]Mar-26 minutes
[25] https://www.w3.org/2020/03/26-wot-arch-minutes.html
Lagally: presenting issues discussed during call 1
Lagally: presenting PRs
... added links to
[26]https://github.com/w3c/wot-architecture/pull/475
[26] https://github.com/w3c/wot-architecture/pull/475
lifecycle discussion
Elena: have done some fixes to the diagram
... there was a discussion of it in the Security call as well
... got input from Oliver, form OPC-UA provisioning angle
... tried to merge OPC-UA lifecycle into the diagram
... Anima focuses on the link between Manufacturing and
Operational state
... Anima also defines the Destroyed state
... maintenance state is not really defined well
Lagally: so it is bootstrapping and achieving operational state
... any other stakeholder?
Elena: Anima defines bootstrapping via joint proxy, registrar,
and MASA
... Manufactured state has the manufacturer key set
... botstrapping will set Site keys
... also, there are Application keys
Lagally: so it solves the question how to provision the keys
during bootstrapping
Elena: it is zero-touch mechanism
... but you have to have some keys on the device
McCool: not all devices have manufacturer keys
Elena: will get there
... for OPC-UA, the picture is similar
... there is no zero-touch provisioning, the device needs
connected to a network, credentials provisioned
... different requirements for pre-state
Lagally: is there an OPC-UA device without any keys?
Elena: Manufactured state can lack the keys
... should ask Oliver
Lagally: should we have a security bootstrap state?
Elena: going back to the WoT device lifecycle picture, we have
a separate state for Bootstrapped/Onboarded
... which is optional
... it is possible some devices are already in bootstrapped
state when leaving manufacturing
McCool: when is the SW installed (behavior)? when application
keys are installed?
Elena: will go through the diagram
... some devices might have manufacturer keys, but no service
provider key or application keys
... then we transition to Bootstrapped state
... configures the device with identity, keys and certs needed
for that
... service provider key is set
... but no application keys at this point
... next, transition to Operational is when app keys are
provisioned and configured
... Maintenance state can update the app keys, but not change
identity etc
McCool: Anima assumes the device is operational when it has the
site keys
... first transition is for service provider bootstrapping,
second transition for app bootstrapping
Lagally: so they have a certain model for key management
... what is an app key
Elena: from WoT pov, there is a set of credentials provisioned
into the WoT runtime
... this is the application key
Lagally: why ACL?
Elena: the purpose is identification and authentication
... then ACLs can be set up
McCool: we should separate device provisioning from service
provisioning
<kaz> regrets2: Koster
Zoltan: setting up ACLs is needed in OCF for instance,
otherwise won't be operational
McCool: we could make a note about device vs service
provisioning
Lagally: is there a new state when a device is registered with
a service?
... tried to do some sequence diagrams and had questions like
this
McCool: registering to services is not a state of the device
Zoltan: there are 2 levels of services: protocol native and WoT
Kaz: we need to figure out which state is linked to which
device
... most states can be linked to specific devices
McCool: it might be confusing to include all possible states
... we can deal with other systems in operational state
... we need to explain what configuration data we are including
Lagally: that goes to the text, keep it abstract
Kaz: we should think about service layer and device layer
separately
Zoltan: operational means the underlying protocol is fully
operational, and in addition WoT also works
Lagally: would present own work, then return to the diagram
... presenting sequence diagrams, 2 flows
... one for the security provider, the other for the consumer
[link to diagram]
[27]https://github.com/w3c/wot-architecture/blob/master/proposa
ls/unified%20device%20lifecycle.svg
[27] https://github.com/w3c/wot-architecture/blob/master/proposals/unified device lifecycle.svg
McCool: simple and clean diagrams, some details to be discussed
... single words should describe states, verbs describe
transitions
... some details like discovery need to be checked
Zoltan: there is discovery for bootstrapping and during
operational mode
McCool: words like introduction and exploration could tell them
apart
Lagally: this diagram is deliberately not detailed
McCool: we can add details as text
Zoltan: what is the diff between Bootstrapped and Onboarded?
Elena: if we forget about security, define the sequence from
operational pov, then we can complete security details
Zoltan: isn't the purpose of the lifecycle diagram to provide
input to Security?
Elena: it has its meaning even without security
Lagally: I agree. Even if we have a secure environment, this
diagram should work
McCool: I like that each state represents a new relationship
... we could start there and look it from the actors point of
view
... we should define things from the perspective of
relationships
Lagally: we could make a table with state and description and
relationship
McCool: depends on what relationships we aim for
Kaz: identify the actors explicitly and a group of states would
be useful.
... we could use the colors to idetify them. also possibly
assign soe of the states as a meta state linked to oprational
state.
... anyway, thinking about the relationship (or mapping)
between Michael Lagally's simpler diagram and Elena's detailed
diagram would make sense
Lagally: about next steps: will create a table, will update the
diagram, Elena can take it from there
Elena: would not like to take it from an empty table; for
security need to have the states and relationships,
capabilities etc defined
... everything that is not security related
Lagally: OK, let's work on the table first
McCool: in github, preferably, e.g. in an issue
Lagally: created
[28]https://github.com/w3c/wot-architecture/issues/476
[28] https://github.com/w3c/wot-architecture/issues/476
any other topic?
<mlagally> Just a little bit of fun:
[29]https://youtu.be/DYu_bGbZiiQ
[29] https://youtu.be/DYu_bGbZiiQ
AOB?
[call 2 adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [30]scribe.perl version 1.154 ([31]CVS log)
$Date: 2020/04/10 09:32:31 $
[30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[31] http://dev.w3.org/cvsweb/2002/scribe/
Received on Sunday, 12 April 2020 04:50:01 UTC