<scribe> scribenick: kaz
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
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)
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
<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]
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
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
Kaz: you can look at the above draft HTML minutes
Lagally: fully typos
Lagally: PR merged
McCool: ok with merging
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
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
<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
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)
Lagally: AOB for today?
(none)
[adjourned]
