Meeting minutes
prev minutes
Lagally: (goes through the minutes)
Lagally: any problems?
(none; approved)
vF2F
Lagally: (goes through the agenda for March 22)
… terminology, ITU-T liaison, ...
… partial TD discussion?
McCool: terminology discussion? or use case discussion?
… maybe could move this topic earlier during the terminology session
Lagally: (moves "partial TD" topic to the terminology session)
McCool: another issue is validation
Lagally: (adds "TD validation" as well to the terminology session)
… ("framing" too)
McCool: also should discuss here or during the TD day
… relate to both TD and discovery, so during the Architecture call makes sense
… not only terminology but also part of TD discussion
Sebastian: btw, some kind of introductory talk at the beginning would be useful, wouldn't it?
Lagally: good point
McCool: each subsection from each day has assigned owner
… and those owners are to generate some introduction
Lagally: will clean up the remaining issues on GitHub
… and assign them to proper people
McCool: my expectation is closing all the terminology issues during the vF2F
Lagally: ok
Kaz: just wanted to make sure the introduction at the beginning is strictly focused on the topics from that day
all: right
Kaz: also should make sure the introduction should be brief enough :)
… we already have introduction session on the first day, March 15
… so please make sure to use the additional introduction sessions on other days in a productive manner ;)
McCool: let's have some more discussion during the main call
Lagally: (moves ahead)
… what about Profiles?
McCool: need to get resolution about one or multiple profiles
Sebastian: core profile now and additional profiles later?
Lagally: that's my understanding as well
Sebastian: my question is still about the term of "core", though
McCool: if we have constrained devices, do we want to define some profile for them?
Sebastian: WoT as a whole doesn't care about what the devices actually are
Lagally: having the information about the expected classes to avoid confusion on the gateways, etc.
Sebastian: wondering about concrete use cases for this approach
Lagally: we're working on a use case
Sebastian: what is the real use case and scenario then?
Kaz: so we're generating some concrete use case description now
… and will discuss that during the vF2F
Lagally: (shows RFC7228 as the basis of the class definition)
Lagally: this definition is just a proposal at the moment
McCool: btw, class 3 might be for something like gateway
… on the other hand, class 4/5 are more for something like Raspberry Pi
… and Class 6 can be a server
… the classes are defined by IETF by an RFC
… and what to do next is thinking about what capacity is required for what purposes
… target platform based on some given function
Sebastian: even a constrained device can generate some big Thing Description
Kaz: in that case, maybe we need to think about TAT as well as the hardware power
<citrullin> The minutes about some potential issue with constrained devices in security
McCool: also thought about that
… but memory, etc., are easier to start with
Kaz: ok, starting with easier point is fine
McCool: do we keep it as a PR to see the preview?
Lagally: can push the changes so that we can see them
… (push some updates to PR 70)
McCool: would fill in something from the security viewpoint
… minimal requirements for secure systems
Terminology (revisited)
Lagally: (goes through the changes)
McCool: partial TD
… Shadow
… TDD
… TD Element - replacement of "TD Fragment"
Lagally: note we need another entry for "Thing Description Element"
McCool: right
… there is a definition a bit below (after "Thing Model")
… still need further work here
… my hope is leave this PR 582, get more feedback, and finalize the terminology during the vF2F
Lagally: ok
McCool: we should separate the definition itself and the name of terms
Lagally: ok
McCool: please do give comments on the PR 582
Lagally: ok
… will ask the group to do so
… AOB?
Sebastian: still have an impression that my concern is not handled seriously enough...
McCool: let's see what the real issues here
Sebastian: would like to see the actual purpose of the profile
Kaz: would suggest we clarify what we want to have by defining "profiles"
… and see use cases and scenarios based on some concrete device settings
Sebastian: would be nice to create an issue to collect concrete scenarios
McCool: ok
Issue 71 - Collect Use Cases and Scenarios for Profiles
[adjourned]