Meeting minutes
Minutes
approved
Wiki clean-up
Lagally: (goes through the Architecture wiki)
… archival of last year's content
McCool: like the main wiki, we can archive old contents
… would suggest we use the same name convention as the main wiki
… just added a leading slash before the year like "/2021"
Lagally: let's go for it
… let's create a GitHub issue for that
Issue 889 - Cleanup Wiki pages
McCool: can handle it since I need to do it for the main call too
Publication schedule
McCool: when to publish the CR drafts?
Kaz: planning to publish TD and Architecture tomorrow
… regarding Discovery, need to talk with PLH, but if he's OK, we can publish it as well tomorrow
McCool: what about the Profile WD?
Kaz: also tomorrow
Lagally: (updates the schedule based on the feedback)
(discussion on PR and REC transitions)
Lagally: (add some more updates to the schedule based on the feedback)
wot PR 1048 - Update wg-2021-extension-plan.md
Kaz: that implies the REC publication will be the end of June
… in that case, we should rather ask W3M for 5-mo extension instead 4
… I'll talk with PLH about Charter extension today anyway
… so will ask him about his opinion about this point
McCool: yeah
… let's check with PLH
Testing
WoT Architecture Implementation Report
McCool: there are some problems with test tooling
… but that should not impact the WoT Architecture spec
Dedicated call with implementers + developers
Lagally: should we have a dedicated call with implementers + developers?
McCool: would be a good idea
… maybe one in English and another in Japanese
… not 100% sure if the Ege's categorization of the assertions is good
Issue 888 - Evaluating At Risk Assertions
Kaz: agree
… we can use Ege's analysis as the basis but should validate it and finalize the evaluation
Kaz: let's have some discussion using a dedicated MD file based on Ege's analysis
… so that we can improve the analysis result using PRs later
McCool: good idea
Lagally: (creates an MD under wot-architecture/testing)
Issue 888 - Evaluating At Risk Assertions
(discussion on what we really meant for each assertion)
Kaz: as already mentioned previously, using TD to express the device capability itself is a kind of abstraction of device interface
… so any WoT implementations should pass 34 and 35
McCool: that's true but there is an additional requirement for a security later for WoT runtimes
Kaz: in that case, probably we should clarify our expectation includes two levels, 1. using TD to express device capability and 2. additional abstraction for security purposes
Kaz: to be strict, we should have clarified what part of each assertions to be implemented by whom (including external non-WoT systems)
… that could be explained by a guideline document as already proposed
… and potentially need to update the WoT Architecture spec itself in the future
… but we need clarification on what/how to test each feature from the current WoT Architecture 1.1 spec now
Lagally: yeah
… let's continue the analysis