<kaz> scribenick: ryuichi
Lagally: architecture 1.1
... profile
<kaz> Sep-3
Lagally: any objection?
... approved
<kaz> scribenick: sebastian
Matsukura: focus on gateway
implementation
... there are 2 documents
... Y.4409/Y-2070 (REC) and Y.sub57 (informative)
<inserted> https://www.itu.int/rec/T-REC-Y.2070-201501-I/en
<inserted> 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> wot-architecture - 5. System Topoplogies (Horizontals)
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> https://github.com/w3c/wot-usecases/pull/51
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
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
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)
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> Statically rendered version for the lifecycle sequence diagram
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?
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)
Lagally: can we merge this MR?
McCool: ok with this
Kaz: +1
Lagally: (merges it)
Lagally: merge this?
McCool: yeah
Kaz: we can add the file and can update it later if needed
Lagally: (merges it)
McCool: Matsukura-san's slides?
... let's capture the link for PR for wot-usecases
McCool: linked this PR with Issue 47
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
McCool: would like to see the common part
Lagally: yes, for the possible harmonization
[adjourned]
