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> Feb-18
Lagally: reviewing the discussion of memory size and use cases
… any objections to approve?
(no objections)
vf2f
<mlagally> https://
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?
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> PR 70 - device categories - initial draft
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> Proposed Section 5. Device Categories
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> https://
<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: 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"
https://
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