- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 08 Mar 2021 12:49:21 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/02/25-wot-arch-minutes.html
also as text below.
Thanks a lot for taking the minutes, Michael Koster!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT Architecture
25 February 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Feb._25th.2C_2021
[3] https://www.w3.org/2021/02/25-wot-arch-irc
Attendees
Present
Kaz_Ashimura, Michael_Koster, Michael_Lagally,
Michael_McCool, Philipp_Blum, Sebastian_Kaebisch,
Tomoaki_Mizushima
Regrets
-
Chair
Lagally
Scribe
mjk
Contents
1. [4]agenda bashing
2. [5]review previous minutes
3. [6]vf2f
4. [7]next weeks progress on profiles
5. [8]review the proposed specification text on profiles
Meeting minutes
agenda bashing
Lagally: want to dedicate most time to the profile discussion
Lagally: any other agenda items?
Lagally: looking at the comments from Ben Francis
review previous minutes
<kaz> [9]Feb-18
[9] https://www.w3.org/2021/02/18-wot-arch-minutes.html
Lagally: reviewing the discussion of memory size and use cases
… any objections to approve?
(no objections)
vf2f
<mlagally> [10]https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf
[10] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf
<mlagally> [11]https://www.w3.org/WoT/IG/wiki/
F2F_meeting,_March_2021#Timetable_for_WoT_PlugFest_and_vF2F_in_
March.2C_2021
[11] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_March_2021#Timetable_for_WoT_PlugFest_and_vF2F_in_March.2C_2021
McCool: ASDF hackathon running concurrently with the Plugfest
Lagally: reviewing time slots for VF2F
McCool: for joint meetings prefer to have enough time for good
depth on each topic, focus on report out and do the work
offline
… what is the priority of the different meetings?
Lagally: we could schedule some of these joint meetings to a
use case call
next weeks progress on profiles
McCool: we need to talk about use cases and reconcile the
different interpretations
McCool: we need to discuss optionality or multiple profiles for
different use cases
McCool: is it one profile for everything or is there enough
specialization in use cases?
Lagally: initial focus was interoperability for embedded
McCool: embedded is too broad, factory automation has other
requirements
Sebastian: agree, embedded is too broad
McCool: for industrial applications we may need larger TDs, for
example
Lagally: we should discuss this before the VF2F
Lagally: profiles have priority over architecture
McCool: go through the issue tracker and find topics that are
important to the group
Lagally: what about (APA)?
Lagally: there are many issues on terminology
McCool: people thought hubs are not part of the WoT
architecture, we should clarify
Lagally: terminology needs alignment with ITU-T architecture
McCool: edge gateway could include hub use cases
McCool: the hub is not necessarily a gateway
… but it is often a proxy
Koster: there could be separate control point vs. proxy
McCool: we need to think in terms of function integration per
ITU-T
Sebastian: edge terminology replaces gateway in common use
Philipp: gateway is used for some specific network routing
functions
Koster: agree, gateway is not specific enough
McCool: gateway hub, edge hub?
… use gateway as an adjective
McCool: use gateway when we are talking about network functions
… hub does orchestration
… edge computer does more heavy lifting beyond hub
… hub can be a generic term
Kaz: agree in general with McCool's categories, we also need to
define "intermediary"
McCool: talk about functions vs. hardware
… hubs can run directory services and intermediaries
Lagally: OSGi is a functional gateway architecture
Koster: agree with use of gateway for network oriented
functions and to describe existing use e.g. OSGi
McCool: hub defined as centralization of local services
… intermediaries, shadows
Koster: a shadow reflects state of a device
Lagally: let's finish the hub definition
McCool: enumerates service types for the issue tracker notes
McCool: will create a PR for hub terminology
Koster: shadow is an intermediary between the devices and the
digital twin models
Lagally: life cycle notes
Lagally: other issues?
<mlagally> [12]https://github.com/w3c/wot-architecture/
issues?q=is%3Aissue+is%3Aopen+label%3A%22spec+contribution%22
[12] https://github.com/w3c/wot-architecture/issues?q=is:issue+is:open+label:"spec+contribution"
Lagally: outreach on help wanted items before the F2F?
Koster: will sign up for introductory paragraphs
Lagally: anything from discovery?
McCool: issues #530, #524
Lagally: there is a label for discovery
McCool: security considerations section
Sebastian: TD section should describe partial TDs (TM,
discovery templates, scripting interactions)
Lagally: protocol binding should be included as a topic also
Koster: clarify that the preceding discussion was in the
context of contributions from other groups to the Architecture
document
Lagally: what about profiles: canonical TD, reference devices,
use cases
Lagally: this is the priority material to discuss in the VF2F
review the proposed specification text on profiles
Lagally: there are 3 PRs
… PR #70 on categories
<kaz> [13]PR 70 - device categories - initial draft
[13] https://github.com/w3c/wot-profile/pull/70
McCool: categories can be kept separate from the TD limitation
discussion
Lagally: devices range from small embedded to larger resourced
devices like hubs
… identify features and use cases for the categories
McCool: I think about small nodes and bigger nodes
… edge and cloud overlap
Lagally: do we need another category for different bigger
devices?
Sebastian: not sure if "node" is useful, since edge and cloud
can have nodes also
Sebastian: categories are not clear
Philipp: how about "constrained devices"?
(discussion on Node vs. Endpoint terminology)
<kaz> [14]Proposed Section 5. Device Categories
[14] https://pr-preview.s3.amazonaws.com/w3c/wot-profile/70/594c374...96ae4f0.html#device-categoriesdevices
discussion of roles vs. device categories
Sebastian: where does a controller belong?
Lagally: the term class is probably a good identifier
… the IETF terminology is useful
<citrullin> [15]https://customer.honeywell.com/resources/
techlit/TechLitDocuments/31-00000s/31-00100.pdf
[15] https://customer.honeywell.com/resources/techlit/TechLitDocuments/31-00000s/31-00100.pdf
<citrullin> CPUEach controller uses a 32 bit ATMEL ARM 7
microprocessor.Memory CapacityFlash Memory: 512 kilobytes. The
controller is able to retain Flash memory settings for up to
ten (10) years.RAM: 128 kilobytes
<kaz> [16]there is some definition for device classification
based on the screen size (but I personally think we should
rather use more neutral term like "class")
[16] https://www.w3schools.com/bootstrap/bootstrap_grid_small.asp
Kaz: memory size is what determines the class, but I also would
go for neutral class name like "class 1, 2 or 3" instead of
"small, medium or large"
[17]https://tools.ietf.org/html/rfc7228
[17] https://tools.ietf.org/html/rfc7228
Lagally: don't want to spend time drafting new documentation
McCool: start with classes then extrapolate as needed for
profiles
Sebastian: what are the scenarios that go with the classes and
use cases?
… the scenarios can inform the TD
Sebastian: there is only the switch and lamp scenario, which is
not realistic enough
Lagally: they are in the minutes
Sebastian: Can we summarize somewhere?
Lagally: we summarized 2 or 3 weeks ago
Lagally: there will be an arch call next week if people are
available
Lagally: AOB?
… none; adjourn
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 8 March 2021 03:49:28 UTC