[wot-architecture] minutes - 23 January 2020

available at:

also as text below.

Thanks a lot for taking the minutes, Michael McCool!



      [1] http://www.w3.org/

                               - DRAFT -


23 Jan 2020


      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda


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



          Kaz, McCool


     * [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



     [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


   Lagally: have installed Elena's lifecycle diagram on GitHub

   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)


     [22] https://rawgit.com/w3c/wot-security/master/index.html#wot-threat-model-assets

   Elena: "system user data"

   Lagally: those terminologies to be defined


     [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
   ... 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,

   Lagally: (adds another note)
   ... consider creating a matrix table including actors and state
   ... this would illustrate who is permitted doing a state

   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"
   ... and Thing Directory is one possible method/mechanism for
   ... 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

   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
   ... 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?


   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

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
   ... 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
   ... 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


   Lagally: just use cases, will defer discussion to use case

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



     [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
   ... 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