Meeting minutes
agenda bashing
<kaz> Agenda
Lagally: copy/paste from last meeting
… any other agenda items?
Sebastian: discussion on the new device profile issue#71
minutes
<kaz> Mar-4
Lagally: minutes approved
reference design
<kaz> Issue 68 - Reference Device Definition for the smallest possible platform for HTTP / TCP / JSON
Lagally: reviewing the discussion on the issue
Lagally: assuming http, tls, and JSON
… assuming consume-only, what are the constraints?
Daniel: there is also some work from Zoltan
Lagally: there are a lot of details in the record
… 16K is a common size
Sebastian: what is a realistic size based on devices and consumer expectations
… using ESP module as an example device
… devices will have a specific purpose and know what kind of model it consumes
… the client will follow a specific information model
… what kind of constrained consumers are there in the plugfest?
Lagally: maybe there weren't any
Sebastian: not aware of any embedded TD consumers
Lagally: so we could assume embedded devices use a built-in information model
Lagally: reviewing use cases from issue #71
… Ben Francis comments from the last few days
<kaz> Ben's comments
Sebastian: there is also a goal to find out how small devices can run HTTP, TLS, JSON
Lagally: hesitate to get into the protocols, but we do make the assumptions about HTTP TLS, JSON
Lagally: a lot of the platforms are embedded PC/linux class
Sebastian: characteristics of producers and consumers of TDs are independent of scale, could have only one or two features
Sebastian: the example platforms are all general purpose and can consume any TD
… constrained device consumers will only be looking for a limited set of features
… based on the device purpose
… then at the other end of the scale, embedded linux/PC there will be potentially very large TDs
Lagally: I understand the point
Kaz: maybe we should consider the use cases without intermediaries and concentrate on Things and Consumers as the starting point, but would suggest we think about intermediary as well for the 2nd step for the use case scenarios
Daniel: what is the consequence of not having the hard limits?
Lagally: there could be TDs that can't be processed on some devices
Daniel: imposing the limit doesn't change the situation with the small device
Sebastian: this seems to be a generic problem with the device being too small for the expected application
Philipp: TDs need to be validated and we don't know how to stream and validate TDs
Sebastian: do we need to validate TDs on small devices?
(thx kaz)
Lagally: assuming yes, you need to parse and validate
Lagally: it may take separate passes but it needs to fit in the buffer
Lagally: if the TD doesn't fit in the buffer, can you consume such a complex TD?
Philipp: also prefer to not restrict the size, what about using a directory as a helper
Lagally: we want to avoid needing any intermediaries
Lagally: we need to restrict the TD size if we want to consume TDs on small devices
Sebastian: +1 the idea of an external helper that can work with client queries
… the client doesn't know what to do with most of the unrelated TD content
Lagally: will the client ask the directory to limit the size of the TD?
Sebastian: more like it will only return the functions requested
Koster: sometimes the client only needs the form that satisfies the interaction requested in a query
Lagally: ideally all devices communicate with each other
Sebastian: practically there will be some service point for queries and serving TDs, there is no peer to peer IoT today
Lagally: so there may always be a gateway in our assumption
Lagally: 2 classes of devices, small devices are not consumers
<kaz> (that's why I suggested we include intermediary for the next step :)
Sebastian: there is always an assumption that there are bigger devices in the system
Daniel: how does it help small devices to consume large TDs?
Koster: maybe the directory could just return the form
Sebastian: you don't need to provide the full TD to the small device that knows what it wants to do
<kaz> (yeah, that's why I brought partial TD topic to the Discovery call on March 8 :)
<citrullin> +1 on partial TDs in directories
Lagally: why couldn't the TD producer also do this filtering?
Sebastian: it could if we define it
Lagally: to address dape, we can define graceful failure modes
Kaz: need to think about all entities, device, intermediary, consumer, directory, as a system
Koster: need to drop now
Lagally: right
… Ben also suggested we think about gateway
… if some of the entity handles TD, that guy need to be qualified to handle the TD
… some kind of guidelines or restrictions to be provided
(Koster and Daniel leave)
Sebastian: if the TD with some specific size or bigger size which exceed the processable size of the entity, need some guideline
… good to see feedback from the scripting/discovery guys
Lagally: (adds a comment)
… a consumer on a constrained device can check if it can process the TD
… or get a partial TD when otherwise
… the size would be too large
Kaz: I already asked the scripting/discovery guys for opinions on Monday
… and they also wanted to know about concrete use case scenarios
<sebastian> (Sebastian leaves)
Kaz: so this discussion today is going for the right direction :)
vF2F agenda
Architecture day - Monday, March 22
Lagally: (goes through the draft agenda)
… introductions
… terminology
… partial TD
… based on the input from the Discovery/Scripting TFs
… TD validation
… based on the input from the TD TF
… framing
… need inputs/proposals from the Discovery TF
… then ITU-T liaison
… that is not really an Architecture topic but a Use Case topic
… (put "ITU-T liaison" at the beginning of March 22 agenda)
Lagally: (puts the ITU-T use case summary MD to the agenda)
Lagally: (and then put "30 mins" for the use cases session)
… (also "2h 20mins" to the architecture session)
… there are many architecture issues on GitHub
… 40 issues including the ones labeled with "terminology", "lifecycle", "discovery", etc.
… let's talk about discovery issues and accessibility issues
… (adds links for those issues to the agenda)
Lagally: (categorizes the agenda topics into "Discovery", Accessibility" and "Optional")
… (puts "10mins" to each sub sections of "Terminology", "Discovery" and "Accessibility")
Kaz: wondering if "10mins" for each topic would be really enough...
Kaz: yeah, possibly
Mizushima: btw, maybe we should check the diff between the FPWD and the current draft?
Kaz: maybe that could be summarized during the introduction session at the beginning
Lagally: yeah, would include that point into the introduction
… regarding the time assignment, would give 20mins for Discovery collaboration
(12 terminology issues there)
and PR 582 - WIP: Terminology update
Lagally: (adds edits for the Profile session)
… device categolies and use cases
… canonicalization
decision: one or multiple profiles?
… proposed constraints
… (and assign some initial time to each topic)
[adjourned]