Meeting minutes
Previous Minutes
<kaz> Sep-26
McCool: (goes over the last meeting's minutes)
… pretty short meeting, any concerns or changes?
There are no objections, minutes are approved
Implementation Report Reviews
Architecture
<kaz> rendered Implementation Report
McCool: There are still a number of issues that need to be resolved. A lot of assertions are not tested yet, especially regarding (D)TLS versions
… does anyone know of a test for the used TLS version?
Jiye: You could use Wireshark. There is also a library for testing the TLS version
McCool: Wireshark is probably too complicated for most people to use, I was hoping for a script. A library version is probably easier. People could also tell us which version they are using.
McCool: We are currently not in a state to go to CR
… however, only half of people have responded yet
… I think we cannot expect certain test results since they require a more mature implementation that goes beyond a prototype
… I have also not seen any commercial implementations (which would have more mature security requirements)
… the question is whether we can get any implementations like these
… kaz, do you think Takenaka Corporation could provide such an implementation?
Kaz: I will talk to them
McCool: Jiye, do you think Siemens can also provide an implementation? Can you talk to Sebastian?
Jiye: Need more information what is required
Kaz: my question is also which assertions from which specifications do we need their responses.
McCool: We have at least three commercial implementations with no inputs yet (Takenaka, Netzo and Siemens)
… especially needed for Architecture
… (gives an example for providing test results via a CSV file)
Jiye: I will have a look into it and discuss it with Sebastian
<McCool> https://
McCool: Similar goes for Takenaka, I will also speak to Ege regarding Netzo
<McCool> https://
Kaz: We should clarify what we want from them. That's basically manual.csv like ditto.csv. Right?
McCool: (Provides links to the input file and the implementation report)
… also, an implementation description should be given as an HTML file
<McCool> https://
McCool: (posts a link to node-wot's description)
Kaz: and it would be nicer if we could have some description about those expected files on the top page of the wot-testing repo :)
McCool: At this point, making changes to the document is difficult, as every change reopens the review period
… any changes still at-risk are still fixable but are not ideal. I would suppose we should be able to get rid of at least half of them, though
Issues
TD Issue #1670
<McCool> wot-thing-description Issue 1670 - Add informative text defining use of proxy-to link relation type
McCool: Someone asked me to look into this
… in the link relation-types table we have a proxy-to relation-type and we also have a security scheme field "proxy"
… the question is when to use which and if they are redundant
… what is asked in the issue is if we can at least explain what the difference is
… the problem is that this is part of TD 1.0 as well
… we could mark it as at-risk and remove it in the next major version
… there might be use cases for using a proxy link (that indicates what is being proxied) in addition to a proxy security scheme field that provides security metadata for the proxy itself
Jiye: I agree that it makes sense to keep it
McCool: (adds a comment to the issue)
McCool: I have an implementation that is actually a reverse-proxy but we could turn it into a forward-proxy as well
McCool: One issue is that we did not mark this assertion as its own row in the table
… or rather as a general issue: The corresponding table that does not contain IDs for assertions at all
… is rather a best-practice table with example than an assertion table
… (adds another comment about this to the issue)
McCool: So we could add an additional sentence regarding the use of proxy information from security schemes for proxy-to links
… as suggested in the comment
… converting the whole table into assertions, however, does not seem practical
Implementation Report Reviews (continued)
Discovery
<kaz> rendered version Implementation Report for Discovery
McCool: Here we have a similar problem with regard to security
McCool: Most of the assertions have become stale, I will ask again in the security call for people to update their implementations
… should we do something to soften the assertions? In the worst case we would need to change them back to informative
… is having too many at-risk items a problem for CR transition?
Kaz: Too many features at risk would not be great, as I mentioned before we could consider putting them in a separate section and putting it at-risk as a whole
McCool: We could put security at risk as a whole but it does not seem like a good idea
… we could put them at risk and add a statement that we might need to make them informative again
Kaz: Ideally, all security features should be implemented, right? We need to talk to Philippe and Ralph but I think if some security features only have one implementation that might be negotiable
… we could explain the background of why security implementations are missing
McCool: As mentioned, we still have not got implementation reports from three industrial implementers, those should care about security.
McCool: I could implement half of the features in my implementation, a problem might be CoAP
… I would be reluctant to take these features out, but it would be a possibility
… we should schedule a meeting with Philippe and discuss these points
[adjourned]