13 Dec 2017



Michael_McCool, Kaz_Ashimura, Daniel_Peintner, Darko_Anicic, Graeme_Coleman, Kazuo_Kajimoto, Kunihiko_Toumura, Michael_Koster, Michael_Lagally, Ryuichi_Matsukura, Taki_Kamiya, Tomoaki_Mizushima, Toru_Kawaguchi, Sebastian_Kaebisch, Barry_Leiba, Keiichi_Tokuyama
McCool, Kajimoto


<McCool> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#13_Dec_2017

<kaz> scribenick: GraemeColeman

welcome Graeme!

<kaz> Graeme: from Paciello Group

<kaz> ... interested in relationship between WoT/IoT and accessibility

Quick updates

McCool: Anyone have anything to report?


Next f2f

McCool: Agenda item 1: Next face-to-face, to be held in Prague March 24-29, 2018.

<kaz> Prague f2f wiki

Koster: There will be a joint meeting on Friday 23rd 2018, and an IETF Hackathon in London on the 17th + 18th March
... If you're interested in semantic interop, you are encouraged to go to WISHI as part of the IETF.

McCool: As before, people need to start to propose topics for the plenary and breakout sessions.

Kaz: We are still working on a schedule for the plugfest

McCool: There will also be a Plugfest meeting call today immediately after this meeting.

<kaz> (PlugFest wiki has been updated)

McCool: Do we have a host for Plugfest? At this moment, it's not clear.

Sebastian: We do not have the latest news about who will host, but this will be discussed.

Task Force reports

TF report 1 - Thing Description

Sebastian: MK proposed some changes to the Thing Description, including introducing and renaming such as using "form" instead of "link". This Friday's TD meeting will cover producing a simplified version of the TD. Siemens will provide a simplified version that follows the Mozilla version.
... Also asks the group if it will be OK for this week's TD meeting to be the last meeting for the year, as next Friday is the start of the Christmas holidays, as DA will be not be around (so a new moderator will be required). DA will be back on the 8th January.

McCool: Suggests that the Wiki page should be updated to reflect the new meeting times after the Christmas holidays. At the moment, TD will meet this Friday (15th).

Sebastian: If there is someone able to moderate on the 22nd, the TD will go ahead on the 22nd - otherwise, it won't start again until the 12th January.

Sebastian: They will have a draft proposal for this friday

Task force report 2 - Scripting

<kaz> dp: conditional notification

<kaz> ... and security information for scripting

Daniel: 1st point How often do you get informed, 2nd point relates to security. They noted that security is a bit vague so far, so the scripting does not support any possibility to populate security information in the scripting.
... Once we proceed, we plan to integrate security into scripting as well.
... The next meeting will be next week, and then one in the new year on the 8th, but this will need to be confirmed at the next meeting (once they know holiday schedules).

TF report 3: Binding Templates

Koster: Yesterday's meeting covered the idea of a resource that you get in response to actions as well as event patterns. Another meeting will be held next week, but not another one until the 9th January.
... Plan to have a document around the 9th January to meet W3C publication deadline, even if it is still relatively loose and not fully figured out.
... Also have slides on conditional notifications.

<mjkoster> https://github.com/mjkoster/wot-protocol-binding/blob/master/Notification.pdf

<kaz> (above presentation to be presented after the Security TF report)

TF reprt 4: Security

<McCool> https://github.com/mmccool/ndss-wot-sec/blob/master/ndss-wot-sec.pdf

McCool: Paper submitted yesterday.
... Feel free to point people to the above URL. The paper covers the various issues, risks and opportunities that arise for security.
... Next step is to get the note published. There are still two broken URLs that need to be fixed - if it can't be fixed today, it won't get published until next year.

Conditional notification

<kaz> Koster's slides

Koster: Discussion on notifications

<inserted> [Conditional Notification]

Koster: Talks about asynchronous notification, which results in a sequence of notifications that conforms to a filter specification. These consist of time and value threshold controls. Exists in IETF drafts (e.g. IETF CoRE), OMA LWM2M and OCF, as well as others.

<kaz> [IETF - CoRE Dynlink (draft)]

Koster: IETF - Core Dynlink (draft): The first that the others are more or less loosely based on.
... Time threshold controls pmin and pmax, value threshold controls gt, lt and st.

<inserted> [Threshold controls]

Koster: pmin = minimum period between notifications, even if data are changing frequently (effectively a noise filter).
... pmax = maximum interval between notifications. Even if data haven't changed, you might still want to send out a notification. Useful for long term synchronisation of things that don't change often.
... st = minimum reportable change in data. Prevents seeing tiny little changes that may not be hugely relevant/important.
... lt and gt. If you have too little water in a water tank, it will warn you if it's less than (say) 10%, or warn you if it's greater than (say) 90%.

Sebastian: Question - Is there anything relating to stability flags?

Koster: Stability flags/numbers are indications of how noisy/variability over time is expected. It relates to pmin and st parameters. You could set st to be a bit larger, and pmin to a bit longer.

Sebastian: Stability could be defined with pmin and pmax, because stability relates to how frequently the value changes - but now we have two parameters instead in one.

Koster: You could expose similar things - instead of saying something stable or unstable, you could use st (step) to characterize stability, i.e. "This is how much stability I accept"

McCool: Does the threshold apply before or after quantization?
... We need to be clear, as we don't have any way of reporting the value before quantization. So, these thresholds can only be based on the reported values.

Kaz: This method currently focuses on interval, but what about concrete time synchronization in the client/server?

Koster: You can use pmin and pmax to do that - for example, if you want to create periodic samples, you set pmin and pmax to the same value. So if you want a sample every 5 seconds, you set both to the same, and you get a sample every 5 seconds.

Kaz: This could be useful for origin time.

Koster: You could have more frequent reports by combining parameters, e.g. pmin, pmax and st.

<inserted> [Reporting mode]

Koster: Reporting mode (currently in design and being incorporated)
... Whenever lt or gt are crossed in either direction, you get a report.
... Band mode - when a sample is above/below lt/gt, we want to report whatever is outside the limits of these parameters. e.g. when the signal is above/below these parameters, notify me every 5 seconds, otherwise notify me every 30 seconds.

Conditional Observe

Koster: pmin and pmax can be provided as parameters in the URI, and can be configured differently.

McCool: Can I use decimals for the unit of time?

Koster: Typically, they are integers and in seconds. MK has some use cases that require subsecond resolution, but currently it is integer based.

Kaz: What about other kinds of conditions? e.g. pmin equals less than something?

<kaz> (or (temp<10 || temp>80) :))

Koster: All of the rules are applied together so that everything is true to trigger the notification.

MLagally: How do you change a subscription of observer? Do you have to clear it first? Is there an unsubscribe mechanism already defined?

Koster: Currently, with coap, you have to unsubscribe. Per client you can only have one subscription, although theoretically you can have any number of clients each with their own subscription. For one client, you cannot apply more than one filter.

<kaz> (we're getting the end of the hour...)

<kaz> [Koster goes through the rest of the slides: CoRE Dynlink Bindings, CoRE DYnlink example (local update), CoRE Dynlink example remote update), OMA LWM2M Notification Control, OCF Conditional Notification, Notification Patterns, Subscription creation, What is an Event?]

Koster: The rest of the presentation covers different ways of applying these parameters - link bindings (example provided in the slides), OMA LWM2M notification control, OCF conditional notification, notification patterns, what events are.
... The slides introduce use cases, but the next step will be to make a specific proposal about how to handle all this - such as exposing specific parameters to the client, but also how to let the client know they are available, while other times how you can set this up with an observe.

Kaz: Can we create an issue on the Github repository for this? This topic is related to TD, scripting and binding

McCool: Can the presentation be shared?

<mjkoster> https://github.com/mjkoster/wot-protocol-binding/blob/master/Notification.pdf

Koster: Will open a Github issue related to this presentation.

<kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/12/14 14:57:37 $