16 Jan 2020


Call 1: Kaz_Ashimura, Elena_Reshetova, Michael_Lagally, Zoltan_Kis
Call 2: Kaz_Ashimura, Michael_Lagally, Kunihiko_Toumura, Michael_Koster, Michael_McCool, Ryuichi_Matsukura



<scribe> scribenick: kaz

Call 1

Previous minutes

Jan-9 minutes

Lagally: (goes through the minutes)
... no negative comments so far
... any objections?

Kaz: didn't hear any objections either

Lagally: we approve the minutes then



Lagally: got a comment from a Japanese reviewer
... very precise review

Issue 420

Lagally: editorial comments, and would accept the comments


Lagally: can accept it?

Kaz: it's just fixing typos, so no problem

Lagally: (merges PR421)


Lagally: next PR 418

Elena: this definition came from the Security/Privacy note

Lagally: make sense to have this terminology (e.g., "System Integrator") itself
... we could do another iteration to improve it
... so let's merge this PR itself

(for architecture-1.1 branch)


Lagally: change for adding a use case to the "USE-CASES" area
... (merges PR422)

Thing Lifecycle

Elena: (shows her generated lifecycle diagram)
... first state is "Manufactured" (on the left side)
... some data might be optional
... device-specific identity, certificates, key pair, etc.
... next, "Bootstrapped"
... there can be some OEM-specific bootstrap method
... remote server, flash, etc.
... identity is established, device owner is defined, trust chains set
... then "Operational"
... based on the communication with the WoT Service Provider's Configuration Server
... everything is ready for operation
... data from bootstrapped state + WoT operation configuration, WoT security configuration (ACLs, all required keys and certs, etc.), WoT user data (collected during this "Operational" state)
... it's possible to go back from "Operational" to "Bootstrapped"
... might even go back to "Manufactured"

Kaz: minor comment, it would be better to make it clearer the upper arrows mean the flow from the left to the right, and the lower arrows mean the flow from right to left (by splitting the starting points and end points of the arrows)

Elena: can do that later
... who is allowed to do the transition is the question
... service provider might initiate it

Lagally: there are 2 different aspects
... are all the transitions always permitted?
... there are some systems permitted
... and some not permitted

Elena: "Decommissioned" is the end of the states
... we can't claim any data at this state
... (devices have been fully decommissioned. data might have been wiped or not)

Lagally: would make sense to have an additional state for data security purposes?
... also wondering about service provider

Kaz: given the "Decommissioned" is kind of "Thrown away" state, I'm wondering about the difference between "Operational" and "Maintenance"
... maybe "Maintenance" could be part of the "Operational" state?

Elena: agree that's possible

Kaz: maybe we should think about the state transition itself and the related stakeholders separately at least at the initial stage
... and then think about the related stakeholders for each state later

Lagally: tend to agree
... would make the diagram simpler and possibly would add some more arrows

Kaz: another suggestion, it might make sense to think about "Which state happens at what kind of location", e.g., factory, home, dumpsite

(some more discussions)

Elena: wondering about the tool to draw the diagram
... can try to improve the connection of arrows

Kaz: btw, Toumura-san uses some text-based diagram generator

Elena: name of the tool?

Kaz: will check

Lagally: can we share the current diagram with the group for the 2nd call?

Elena: yes
... will send it to you, Lagally
... also can clean it up a bit by the 2nd call

Lagally: tx!

Zoltan: btw, we don't have to mention "WoT" within the diagram because this is rather a generic lifecycle diagram for IoT purposes

Wrapping up

<mlagally> https://www.w3.org/TR/2012/NOTE-mmi-discovery-20120705/#uc-set-1

Lagally: we talked about Elena's generic lifecycle diagram
... but have not talked about the MMI diagram
... regarding Use Cases
... created a new use case about big data

<mlagally> draw.io

Zoltan: (mentions "draw.io" as a possible drawing tool)

Lagally: it's end of the 1st call

[call 1 adjourned]

Call 2


Lagally: approved the previous minutes (Jan-9)
... had discussion on lifecycle
... would start the calls 5-min past

McCool: agree
... should do for all the WoT calls

Prev minutes - revisited

Jan-9 minutes

Lagally: any objections to accept them?

McCool: not really reviewed them...

Lagally: no critical issues there
... so let's approve them


Lagally: Thing lifecycle: Elena's diagram, W3C MMI...
... can quickly skim the call 1 minutes

Recap from call 1

draft Jan-16 minutes

Kaz: you can look at the above draft HTML minutes

Issue 420

Lagally: fully typos

PR 421

Lagally: PR merged

McCool: ok with merging

PR 418

Lagally: terminology, e.g., system integrator
... didn't remove the current definition but merged the PR

McCool: one thing is not removing the content from the security note
... and clean up the Architecture doc first
... and after that improve the document

Lagally: sounds good

PR 422

Lagally: another PR for an additional use case description

McCool: user-oriented vs technology-oriented
... given use cases may include multiple technologies
... template should have who is the user
... important is listing user orientation

Lagally: agree use cases are not technology-oriented

McCool: can describe here is this technology, etc.

Kaz: +1
... we can categorize use cases, e.g., based on technologies, later

McCool: initial brainstorming to be done based on user-oriented viewpoint
... we could categorize the use cases based on technologies later
... could add a section on "technology category"
... smart home, etc.

Lagally: let's get back to them later
... and go through the call 1 discussion first

McCool: ok

Lagally: we discussed Elena's proposed lifecycle diagram

McCool: what tool was used?

Lagally: draw.io

McCool: would like to have SVG as the format

Lagally: can generate SVG as well
... (shows Elena's diagram)

McCool: arrows go to "Decommissioned" are one-directional
... would like to have description for each state
... can't call into the 1st Architecture call, so would like to check with Elena during the Security call
... discovery should have its own state
... the other possible separate state is ID management
... should think about which information is deleted

Lagally: on the directory service?

McCool: on the device
... we should discuss that kind of points
... directory would periodically ping the device
... implies transitioning the other state transition diagram

Kaz: +1
... as I already mentioned the other day, we should pick up some specific use cases for lifecycle discussion
... the lifecycle diagram may have several nested transitions
... so should start with an abstract layer transition and think about nested/detailed layer transition next

Lagally: don't want to think about too many diagrams, though

McCool: need to figure out what this diagram means

Lagally: how can we convey our thoughts back to Elena?

McCool: let's minute our ideas, and then can talk with her during the security call
... another question is definition of "privacy"
... the current definition is a bit weak
... would ask PING for help

Kaz: btw, can we save an SVG or a PING version of the diagram for reference purposes from these minutes?

McCool: SVG would be better

Elena's draft lifecycle diagram

Lagally: that was lifecycle conversation

MMI use cases

<mlagally> https://www.w3.org/TR/2012/NOTE-mmi-discovery-20120705/#uc-set-1

Kaz: (introduces what W3C MMI WG and its work was like)

Lagally: let's visit their generated use case descriptions
... [3.1 Smart Homes]
... description, motivation and requirements

Kaz: MMI Architecture defined a set of events between server and client for data transfer

McCool: extending accessibility could be a use case for WoT

Kaz: +1
... there was a W3C track session during the Web Conf in Montreal in 2016 as well

McCool: nice way to ask the accessibility group to get engaged
... this is also a multi-vendor system integration
... e.g., building management system integrating devices from multiple manufactures
... exactly a problem for WoT
... concrete example is HVAC control

Kaz: please note that there was a mechanism to handle state transition as well
... that was SCXML generated yet another WG

McCool: ok
... btw, we could borrow the essence of the ideas but should not copy the descriptions directly

Kaz: +1

McCool: we should have generic use cases
... integration of data from multiple vendors, etc.
... btw, "life companion" use case could be part of the "Accessibility" use cases

Kaz: that's fine

McCool: this is automation
... another viewpoint is optimizing energy consumption

Kaz: btw, maybe "accessibility" should be a feature of all the possible use cases rather than a category of use cases?

McCool: possibly
... let's make both "life companion" and "accessibility" at the same level at the moment

all: ok

Lagally: what about "Fleet management"?

McCool: that's fine

Lagally: assets are moving across locations and networks
... and then we can visit "audio/video" now

Issue 8

McCool: should discuss this during the joint call with MEIG on Feb. 4

Kaz: +1

Lagally: ok
... we looked into use cases
... and still need some volunteers
... to fill in the actual use case templates

McCool: can do the accessibility one
... by going through the MMI documents

Kaz: can help you :)

Lagally: (creates an issue about "Map Multimodal use cases to WoT" and assign it to McCool)

Issue 423

Lagally: AOB for today?



Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/01/27 12:28:24 $