- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 07 Feb 2020 13:55:25 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/01/23-wot-arch-minutes.html
also as text below.
Thanks a lot for taking the minutes, Michael McCool!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-Architecture
23 Jan 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Call 1: Kaz_Ashimura, Elena_Reshetova, Michael_Lagally,
Ryuichi_Matsukura
Call 2: Kaz_Ashimura, Kunihiko_Toumura, Michael_Koster,
Michael_Lagally, Zoltan_Kis, Ryuichi_Matsukura
Regrets
Chair
Lagally
Scribe
Kaz, McCool
Contents
* [3]Topics
1. [4]Call 1
1. [5]Prev minutes
2. [6]Issues/PRs
3. [7]Lifecycle
2. [8]Call 2
1. [9]Previous minutes
2. [10]Notes from first hour's meeting
3. [11]Review issues
4. [12]PRs
5. [13]Proposed REC publication
6. [14]Lifecycle
7. [15]MMI use cases
* [16]Summary of Action Items
* [17]Summary of Resolutions
__________________________________________________________
Call 1
<kaz_> scribenick: kaz_
Prev minutes
[18]Jan-16 minutes
[18] https://www.w3.org/2020/01/16-wot-arch-minutes.html
Lagally: (goes through the mintues
... any concerns/issues?
(no objections)
Lagally: let's approve the minutes then
Issues/PRs
[19]Issues
[19] https://github.com/w3c/wot-architecture/issues
[20]Issue 426
[20] https://github.com/w3c/wot-architecture/issues/426
Lagally: ened to have discussion on use cases for digital twins
... also some home work items from the main call about future
use cases to be presented during the ME joint call on Feb. 4
... we still have one more call before that
... some initial set of use cases would make sense
... some more use cases here
... let's talk about them during the use case session
[21]PR 424
[21] https://github.com/w3c/wot-architecture/pull/424
Lagally: McCool has created a PR for MMI use cases
Lifecycle
Lagally: have installed Elena's lifecycle diagram on GitHub
repo
Elena: you should also have permission for edit
Lagally: we had discussion on a possible intermediate state
between manufactured and bootstrapped
Elena: you can have some identity provisioning
... bootstrapped is related to establishing user's identity,
and optional
Lagally: would not make changes directly here
... could be a null operation
... could have a bootstrapped state even if it's possibly empty
... (better to keep the current transition diagram than
connecting operational directly from manufactured)
... we probably need some terminology for clarification
... about user configuration
Elena: do you have any idea?
Lagally: not yet
Elena: (shows the security mitigation table)
<elena_>
[22]https://rawgit.com/w3c/wot-security/master/index.html#wot-t
hreat-model-assets
[22] https://rawgit.com/w3c/wot-security/master/index.html#wot-threat-model-assets
Elena: "system user data"
Lagally: those terminologies to be defined
<elena_>
[23]https://www.draw.io/#G1NRDu9I0A5yhBBh3PRWncJXOVNZrDfbt5
[23] https://www.draw.io/#G1NRDu9I0A5yhBBh3PRWncJXOVNZrDfbt5
Elena: need to leave
... diagram URL above
Lagally: let me see if I can edit it
Kaz: our Google accounts should be authorized by Elena
Elena: yes, please send me an email
Lagally: ok, let's do that offline
... regarding the terminology
... "system data", "system user data", etc.
... maybe more privacy sensitive data is possible
... like user credentials
... maybe we don't need to introduce new definition (but could
reuse the existing definition)
... based on the definition from the Security&Privacy
Guidelines document
Elena: there are different types of data
Lagally: we just need to include the definition from the
Security&Privacy document
(Elena leaves)
Lagally: let's look at the diagram quickly again
... manufacture state with optional data
... and then bootstrapped state with required data
... probably optional at the bootstrapped state as well
... (adds notes)
... who are the actors? (for the connection between
manufactured and bootstrapped)
... need names for all the state transitions, perhavs only an
abbreviation and a full legend somewhere else (in general)
Kaz: agree we should clarify the "actor"
... and for that purpose, (as I mentioned last week) probably
it would be useful to identify the location/timing, etc., as
well
... meaning where and when the actors do what
... at least at this initial stage of discussion
Lagally: (shows his slides on "Actors and Roles")
... yeah, we should clarify actors and roles
... (copies the list of actors and roles from the slides to the
lifecycle diagram)
... will fix the font setting for the text later
(Zoltan joins)
Zoltan: I also made some comments
... 2 possible states there
... including configuration
... and destroyed
... those 2 are currently merged as "decommissioned"
... decommissioned means the data is wiped out, not destroyed
Lagally: do you think we need to have an additional state?
Zoltan: we should have "factory default" data for the
"Manufactured" state
... also "Decommissioned" should be "Decommissioned/Destroyed"
... from WoT viewpoint, the Actors are not necessary to
described here
... we can mention the examples, though
Kaz: note that when we discuss the lifecycle state transition,
it would be useful to discuss that based on concrete use cases
... and those use cases should have concrete definition of
actors, locations, actions, etc.
... the final diagram doesn't have to include those details,
though
Lagally: (adds another note)
... consider creating a matrix table including actors and state
transition
... this would illustrate who is permitted doing a state
transition
Zoltan: btw, there is a typo at the title
... to be fixed as "WoT lifecycle diagram.drawio"
Lagally: fixed
... possible additional state for "Onborded"?
... "Onboarded/Registered with a Thing Directory"
Zoltan: don't think that needs to be a separate state
Kaz: agree
... onboading is part of (or similar to) the "Bootstrapped"
state
... and Thing Directory is one possible method/mechanism for
that
... so might make more sense to call the state "Onboarded"
Zoltan: we can keep both the names at the moment
Lagally: (changes the name to "Bootstrapped/Onboarded")
... do we have a Consumer at this state
(Bootstrapped/Onboarded)
Kaz: it depends
... so I think we should think about the location as well
... if it's done at a a consumer's home, the consumer is
included
... but if not, the consumer may not be included
Zoltan: why don't we add data on "device/consumer relationship
has been established?" ?
Lagally: ok
... (also updates the transition from "Bootstrapped/Onboarded"
to "Operational")
... provision WoT operational configuration, WoT security
configuration, register deive wit hconsumers and/or
directories, provision a device with a service
... btw, we're out of time
... let's continue the discussion during the next call
... Zoltan, can you talk about OCF and oneM2M?
Zoltan: can present OCF
Lagally: ok
Zoltan: can do that next week
... but maybe Michael Koster can also do that during Call 2
Lagally: ok
... AOB?
(none)
Lagally: the updated diagram has been save
... if you have any additional comments, please use another
color (than yellow)
[Call 1 adjourned]
Call 2
<McCool> scribenick: mccool
Previous minutes
<mlagally> Minutes of last week's call are approved:
[24]https://www.w3.org/2020/01/16-wot-arch-minutes.html
[24] https://www.w3.org/2020/01/16-wot-arch-minutes.html
Notes from first hour's meeting
Lagally: talking about lifecycle diagram
... added a number of things to the lifecycle diagram
... did not go further into use cases
... would like to ask Koster to talk about lifecycle in OCF
Koster: ok, we can do that
Lagally: did go through issues and marked use cases
... and added a few new issues for use cases
... did create a PR for a Digital Twin use case
... one issue is that the current lifecycle is just for the
device
... for instance, onboarding/offboarding are not clear
... are these the same or separate from bootstrapping?
... fan of sequence diagrams, I think that would make things
clearer
... identify these additional system states
Review issues
Lagally: several new issues and tags for use cases
... for PRs, we need some more use cases to be submitted
... need volunteers to actually put together some use cases
PRs
Lagally: just use cases, will defer discussion to use case
discussion
Proposed REC publication
Lagally: diff shows some changes, we should review
... mostly typo fixes, and HTML reference fix for eventsource
McCool: note dates in references are picking up older dates for
some reason
... for the WoT-Scripting-API and WoT-Thing-Description
<scribe> ACTION: kaz to look into fixing references
<mlagally> proposal: accept the latest draft of the
architecture spec after incorporating the fixes to the outdated
spec references for proposed REC publication
RESOLUTION: accept the latest draft of the architecture spec
after incorporating the fixes to the outdated spec references
for proposed REC
Lifecycle
<mlagally>
[25]https://www.draw.io/#G1NRDu9I0A5yhBBh3PRWncJXOVNZrDfbt5
[25] https://www.draw.io/#G1NRDu9I0A5yhBBh3PRWncJXOVNZrDfbt5
Lagally: updated description of decomissioned
... need to have better flow around onboarding
... also have another document with terminology
McCool: I think we should focus on states in diagram, not how
get there
... for example, covering discovery for onboarding, etc. will
make things very complicated
... what really matters is we get into a state where the device
has keys provisioned for access rights, etc.
Lagally: missing is what happens if device is de-registered
from a service
McCool: I think since this can happen without the state on the
device changes
... so it's a question about whether it belongs in this diagram
... if we put everything in one diagram, it will be impossible
to read
Lagally: yes, should keep things simple, and focused on a
specific purpose
... one purpose is to define specific terminology
... we should also get alignment with ping; both process and
our work so far
McCool: I think we need to do some more work before reaching
out to ping, eg. use cases
... also I realized recently we need to do more work to really
preserve privacy during discovery...
... regarding the diagram, I think the arc labels need some
work
... eg "factory reset" label seems like it applies to the arcs
to the decommissioning state, which is not correct
... I like the idea of a table; can make it normative, and put
details in it
... then the diagram can just be an informative illustration
... and we can omit details to make it easier to understand
Zoltan: have prepared some material for LwM2M and OCf
... it is quite big... maybe can just give references and
people can look at them
... have references to docs, sections, tables, etc.
Lagally: it would good to have slides with the references, and
then a high-level summary
Zoltan: best outcome is that we improve our diagram based on
review of other standards
Lagally: ok, let's defer this discussion until next week
MMI use cases
<inserted> scribenick: kaz
<inserted> McCool: use case 1-1:
Kaz: a speakerphone like Amazon Echo at the living room could
behave as an extended speech interface device for the
smartphone at my bedroom when I'm at the living room
<inserted> McCool: use case 1-2:
McCool: next Intelligent Home Apparatus
Lagally: would be better to change the title ?
... like "Unified smart home control"
<inserted> McCool: use case 3-1:
McCool: next "Interactive Public Spaces"
... privacy-sensitive like add insertion
... filled in some gaps
... expected devices, data, etc.
Lagally: we're 5 mins over
... how to proceed?
Kaz: would suggest McCool create PRs to put the use cases to
the w3c/wot-architcture repo
... and we continue the review next week
McCool: sounds good
Lagally: aob today?
<inserted> scribenick: McCool
McCool: summarized mmi
Lagally: let's merge and then discuss via issues
... also the digital twins?
McCool: we did not have time to discuss, but it is in its own
file, so sure
<kaz> [Call 2 adjourned]
Summary of Action Items
[NEW] ACTION: kaz to look into fixing references
Summary of Resolutions
1. [26]accept the latest draft of the architecture spec after
incorporating the fixes to the outdated spec references for
proposed REC
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [27]scribe.perl version 1.154 ([28]CVS log)
$Date: 2020/01/27 12:50:06 $
[27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[28] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 7 February 2020 04:55:34 UTC