Meeting minutes
Minutes review 21 December (Profile)
<mlagally> https://
McCool: would like to suggest keeping profile and arch separate, and suggest deferring review of profile minutes until next profile call
Kaz: that's what I've been also suggesting, so agree with that
Lagally: ok, will carry over
Testing
McCool: I think the latest IR was merged
Lagally: also what about DTLS PR?
McCool: please mark as deferred
Lagally: seem IR was merged, let me create a github.io link to render it
<kaz> wot-architecture/testing/README.md
Lagally: (creates link in the README)
<kaz> Implementation Report
McCool: so similar improvements to the table in the report
Lagally: would be helpful to have numbers on the implementation descriptions
McCool: yes, I agree, will look into doing that
Sebastian: regarding arch-security-consideration-communication-platform
… it's quite strange, if consumers/Things can generate a correct TD, then it should automatically satisfy this
… number should be much higher
McCool: also think this assertion is strange, but consider it a sub-case of the requirement that TDs should reflect Things
… so yes, we could probably generate it from other assertions, even in other docs
<kaz> Issue 888 - Evaluating At Risk Assertions
Kaz: agree with sebastian. We had some preliminary analysis about this during the TD call yesterday, and wanted to check with Lagally as well.
… and agree with mccool that we don't want to change assertions at this point, just how to test
… but might be useful to add some clarifications
… e.g. which assertions can be approved based on implementation experience
Lagally: this is a generic and conditional requirement
… esp. "when not covered by binding template"
… TD creator is a human
… anyway, the reason we only have 1 result is that it is conditional
McCool: so in short it only applies to special cases
… for example, philips hue bulbs
Lagally: and I see we don't have results for that
McCool: and in fact lots are missing
Kaz: suggestion during TD call is to look into the data a bit more, at least for features at risk
… and understand why they are not covered yet, e.g. not-impl vs. problems with testing tool vs. lack of understanding
McCool: no testing tool for arch, just manual, so probably more lack of understanding
Kaz: regarding Architecture, that's true and we should concentrate on the manual test description.
McCool: also, that assertion is conditional on being an ecosystem, so research project that are one-offs won't be applicable either
Kaz: we quickly skimmed the assertions and the data yesterday, and Ege created a preliminary analysis. that is issue 888. so would suggest we start with that.
McCool: also note for that particular assertion, we just need one more result, e.g. Philips hue would do it; intel-ocf also
<kaz> Issue 888 - Evaluating At Risk Assertions
<kaz> Implementation Report
McCool: for HAL things, pretty much any implementation should have one... unless it is virtual
… so suggest it is a lack of understanding
… so maybe add some informative text, and maybe invent some way to link that to assertions
… but it may be that the respondents are all virtual things
Kaz: we should remember our basic expectation here. and if people use DTLS to distribute TD, that's already a secure version of the WoT implementation. using TD to express and expose the device capability is already kind of abstraction of device capability based on the WoT framework. we don't require people to implement VMware kind of "virtualization" here.
McCool: these assertions are to mitigate a safety risk, and I disagree with Ege that they belong in scripting
… also, apply to any implementation or application
McCool: for "segmented network" should be easy to satisfy, but probably not well explained
… also, mTLS does require pre-shared keys
McCool: making all of the unimplemented features informative would be too much, though making some of them informative would be OK
McCool: a few categories, implementation, deployment, policy
… but in general, these are best practices, and if they revert to informative statements it's not too critical
Kaz: we should prioritize assertions that are important and figure out how to resolve them. probably we should add informative notes to describe what our actual expectation for those features was.
Lagally: the one with 1 implmentation should be easy to fix, 0s may be misunderstandings
McCool: except for the DTLS one, which is know is a lack of libraries
Lagally: so maybe we should focus on some of the other orgs that have not submitted results
Ege: part of the problem, is about deployments
Sebastian: thinking if we should organize a meeting with developers and go through all of these
… probably some people just don't understand them
… and are not clear if they apply to them
… and once they understand it may be easy for them to provide results
Lagally: community group? IG?
Sebastian: testfest is IG, so...
… but there are other implementers that are not in the IG, but we can look at who has contributed so far
Kaz: technically WG is responsible for testing, so should organize in collab with other groups
… also, Japanese CG is organizing something similar
… explaining what is actual requirement for each feature, checking implementation status for those features
Kaz: and we may find assertion that need some additional explanation, can add informative text to supplement this
McCool: also, about testing, we should be testing particular things in particular deployments, not libraries
… so for example, results for node-wot are just a combination of results from a set of things that use node-wot
McCool: regarding "testing event", it should be relatively short and well-advertised
Ege: agree with a different format for testing
<sebastian> I need to switch meeting. Merry christmas and happy new year. Thanks for the hard work.
McCool: going through them one-by-one does not really make sense when we have 400, but now we are down to a small set of "hard" ones we can go through them one by one
Ege: suggest we just do a small number at once, e.g. 10
Kaz: let's concentrate on the remaining 10 features, specifically some of the important ones from them
Kaz: what are next steps?
McCool: let's pick this up in the first meeting next year
Kaz: Mizushima-san is already working on basic logistics for the JP version event concentrating on the 10 remaining features from Architecture. that's basically describing our expectation and check the actual implementation status. so should coordinate with that.
<kaz> [adjourned]