<kaz_> scribenick: kaz_
Lagally: (goes through the
mintues
... any concerns/issues?
(no objections)
Lagally: let's approve the minutes then
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
Lagally: McCool has created a PR for MMI use cases
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_> https://rawgit.com/w3c/wot-security/master/index.html#wot-threat-model-assets
Elena: "system user data"
Lagally: those terminologies to be defined
<elena_> 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]
<McCool> scribenick: mccool
<mlagally> Minutes of last week's call are approved: https://www.w3.org/2020/01/16-wot-arch-minutes.html
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
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
Lagally: just use cases, will defer discussion to use case discussion
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
<mlagally> 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
<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]