- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 23 Sep 2020 17:34:10 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/09/10-wot-arch-minutes.html
also as text below.
Thanks a lot for taking the minutes, Matsukura-san and Sebastian!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
WoT Architecture
10 Sep 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Kaz_Ashimura, Michael_Lagally, Michael_McCool,
Ryuichi_Matsukura, Tomoaki_Mizushima, Sebastian_Kaebisch
Regrets
Chair
Lagally
Scribe
ryuichi, sebastian, kaz
Contents
* [3]Topics
1. [4]Today's agenda
2. [5]Prev minutes
3. [6]Architecture 1.1
4. [7]Discovery components
5. [8]MR 537
6. [9]MR 535
7. [10]MR 528
8. [11]AOB?
9. [12]Issue 536
10. [13]ITU-T SG20
* [14]Summary of Action Items
* [15]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: ryuichi
Today's agenda
Lagally: architecture 1.1
... profile
Prev minutes
<kaz> [16]Sep-3
[16] https://www.w3.org/2020/09/03-wot-arch-minutes.html
Lagally: any objection?
... approved
Architecture 1.1
[17]Matsukura-san's slides
[17] https://github.com/mryuichi/documents/blob/master/ArchTF-Y4409-200910.pdf
[18]ITU-T Y.4409
[18] https://www.itu.int/rec/T-REC-Y.2070-201501-I/en
<kaz> scribenick: sebastian
Matsukura: focus on gateway implementation
... there are 2 documents
... Y.4409/Y-2070 (REC) and Y.sub57 (informative)
<inserted> [19]https://www.itu.int/rec/T-REC-Y.2070-201501-I/en
[19] https://www.itu.int/rec/T-REC-Y.2070-201501-I/en
<inserted> [20]https://www.itu.int/rec/T-REC-Y.Sup57-201912-I
[20] https://www.itu.int/rec/T-REC-Y.Sup57-201912-I
Matsukura: background: many devices connected, many services
launched
... service platform deployment: there are 2 types of
deplyoment of service (aggregate and distribute type)
... 4 layer architecture: gateway can connect various protocol
interface devices and provide a web api
... examples ECHONET Lite and broadbannd forum TR-069/TR-181
... how to connect devices to gateway: there are 4 ways to
connect devices
... gateway connection to basic device: there are TDs in Basic
Device
... gateway converts command and transport
... gateway connection with non-IP device: gatewy convert
command in the same way as IP basic devices
... gateway conection with non-basic dev.: gateway creates the
device object from the device interface
... sample application: 28 types, 820 devices were accessed by
SOAP/XML with ECHONET vocabulary
... smart home scenario was used in PlugFest
... second scenario is about residential building
... third one is about shops
... last one about schools (lightning)
... summery: architecture document or Smart Home, 4 layer
architecture; resolving protocol gap between devices and
services, first implementation based on SOAP
Lagally: thanks for the presentation. Any questions?
McCool: I submited PR about standards and miss this one.
... can you share the links to the standards
... I did a summary about the ITU-T standards.
Kaz: I already provided the link in IRC
Lagally: I have some questions
... I try to understand the impact of the documentation.
... In terms of requirements and functions is there any gaps in
our approache?
Matsukura: Which sections are you pointing too?
Lagally: There is in chapter 7 about requirements like device
and HRW
... do you see any gaps compared to our WoT approache?
Sebastian: You like to know if there are some requirements in
the ITU-T document which we not cover yet, right?
Lagally: yes
<kaz> [21]wot-architecture - 5. System Topoplogies
(Horizontals)
[21] https://w3c.github.io/wot-architecture/#sec-common-deployment-patterns
Kaz: There is description on Gateways within the current WoT
Architecture spec as above. So I also would like to see whata
is missing. We should be careful what is required for the
architecture. E.g., what is needed for discovery, TD, binding
etc
Lagally: Next steps. MM and RM working together to identify the
gaps
<mlagally> [22]https://github.com/w3c/wot-usecases/pull/51
[22] https://github.com/w3c/wot-usecases/pull/51
Discovery components
McCool: I have no PR yet
<kaz> scribenick: ryuichi
McCool: directory collect TDs
<inserted> scribenick: kaz
McCool: need to sketch the discovery section
Lagally: maybe I have to redo the diagram as well
... how do we fit in the discovery capability
McCool: what Consumer need to do
... advertising could be included
Lagally: note we don't have "Directory" at the moment
McCool: right
... maybe separately
... Directory component
... which is optional
[23]8.1.1 Things and Consumers
[23] https://w3c.github.io/wot-architecture/#thing
McCool: it's not directory tied with TD, per se
... here it seems intermediary consumes only one TD
... it's a kind of Thing
... mashup is a special case of Things to be orchestrated
... maybe I'm wrong with the terminology
[24]8.1.4 Intermediaries
[24] https://w3c.github.io/wot-architecture/#intermediary
McCool: the first line of section 8.1.4 says
... "Intermediaries can act as proxies for Things"
... it's a mashup, e.g., including temp sensor
... mashing up with other Things
... services running somewhere
... might be a sub-category of Things
... thinking about edge computing
Lagally: if we identify new components here
McCool: "Intermediaries" is a category already. right?
Lagally: is there any additional functionality?
... (shows the sequence diagram within his PR)
[25]PR 537
[25] https://github.com/w3c/wot-architecture/pull/537
McCool: this is basically correct
... we have pere-to-peer discovery as well
... authentication and then getting TD
Lagally: that's an important one
McCool: the Consumer already has the TD
... and the 2nd case is peer-to-peer
... and the third case is directory
Lagally: can create an issue about that
<mlagally> [26]Statically rendered version for the lifecycle
sequence diagram
[26] https://cdn.statically.io/gh/w3c/wot-architecture/47a9a0fe70d5878871eeb2d83f0b10c6ba1733ff/index.html
McCool: centric mechanism and ad-hoc mechanism
... peer-to-peer type is part of ad-hoc
... the issue of "ad-hoc" is that we need dynamic discovery
... so for the first version, we don't have to have that
... could have that for v2 spec, though
Lagally: this is basically...
McCool: in the smart cities, like the discussion during the
Singapore Geospatial Week
... spatial query for congestion could be included
... need approval by the person owns the edge device
Lagally: registration could be static activity
McCool: maybe "ad-hoc" is not appropriate
... maybe "dynamic" would be better
... organized one vs free one
... multiple agents work with the owner
... OAuth token comes back, etc.
Lagally: what we do here?
McCool: there are 2 fundamental things here
... if you don't have advanced knowledge, need to get TDs
... pere-to-peer and directory-based
... peer-to-peer uses broadcasting
Lagally: maybe we can keep it simple for the moment
... could find something better, couldn't we?
... do you think you can help me improving this?
McCool: think so
Kaz: this discussion so far is good
... but I'd suggest we think about requirements for wot
architecture a bit more
... so not as part of section 8 but as part of section 7
Requirements
... by elaborating the description within section 7
Lagally: (shows the description within section 7.2.5)
... maybe we should elaborate this description a bit more
Kaz: we should elaborate what is required for the two
categories (1. peer-to-peer and 2. direcotory-based) here
within section 7.2.5
Lagally: (shows the REQUIREMENTS/discovery.md file)
McCool: might be too detail but we could put the summary of
this MD description into the Architecture document
Kaz: actually, that's why I'd suggest we define the detailed
requirements as part of the consolidated "Use Cases and
Requirements" document instead of section 7 of the Architecture
spec
McCool: right
... requirements don't have to be normative
Lagally: given the FPWD publication, we should be careful about
the progress
McCool: in that case, we can continue to work with section 7
... but I still believe we need to document all the detail
there
Kaz: +1
... working with this section 7 of the Architecture spec is
fine for FPWD
... but would be better to transfer the details to a separate
"Use Cases and Requirements" doc later
McCool: also we could have "General Requirements" in addition
to each requirement MD at wot-architecture/REQUIREMENTS
... btw, anything else missing from the Charter viewpoint?
Lagally: we should have 10 different use cases if possible
McCool: discovery is one of the requirements which is related
to multiple use cases
... access control should be also
... for smart city security, etc.
Lagally: ok
... why don't we start with what we have here?
[27]wot-architecture/REQUIREMENTS
[27] https://github.com/w3c/wot-architecture/tree/master/REQUIREMENTS
McCool: should have some more brainstorming about what is
needed
Lagally: good things to do
... why don't we put that into the agenda for the next week?
... (and updates the agenda for the next week)
[28]Agenda
[28] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
MR 537
[29]MR 537
[29] https://github.com/w3c/wot-architecture/pull/537
[30]lifecycle-1.svg
[30] https://github.com/w3c/wot-architecture/blob/master/images/message-flows/lifecycle-1.svg
[31]lifecycle-2.svg
[31] https://github.com/w3c/wot-architecture/blob/master/images/message-flows/lifecycle-2.svg
Lagally: can we merge this MR?
McCool: ok with this
Kaz: +1
Lagally: (merges it)
MR 535
[32]MR 535
[32] https://github.com/w3c/wot-architecture/pull/535
Lagally: merge this?
McCool: yeah
Kaz: we can add the file and can update it later if needed
Lagally: (merges it)
MR 528
[33]MR 528
[33] https://github.com/w3c/wot-architecture/pull/528
AOB?
McCool: Matsukura-san's slides?
... let's capture the link for PR for wot-usecases
[34]wot-usecases PR 51
[34] https://github.com/w3c/wot-usecases/pull/51
McCool: linked this PR with Issue 47
[35]wot-usecases Issue 47
[35] https://github.com/w3c/wot-usecases/issues/47
Issue 536
[36]Issue 536 on CHIP
[36] https://github.com/w3c/wot-architecture/issues/536
McCool: should check with Michael Koster
... two more components to be considered here
... translator and discoverer
Kaz: for this issue itself, we can simply explain that we've
been liaising with CHIP via Michael Koster
McCool: yeah
ITU-T SG20
McCool: would like to see the common part
Lagally: yes, for the possible harmonization
[adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [37]scribe.perl version ([38]CVS log)
$Date: 2020/09/23 08:33:52 $
[37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[38] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 23 September 2020 08:34:16 UTC