- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 14 Dec 2017 03:14:26 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
https://www.w3.org/2017/12/13-wot-minutes.html
also as text below.
Thanks a lot for taking these minutes, Graeme!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT IG/WG
13 Dec 2017
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Agenda
Attendees
Present
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
Regrets
Dave
Chair
McCool, Kajimoto
Scribe
GraemeColeman
Contents
* [3]Topics
1. [4]welcome Graeme!
2. [5]Quick updates
3. [6]Next f2f
4. [7]Task Force reports
5. [8]Conditional notification
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<McCool>
[11]https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#13_Dec_2017
[11] 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?
(none)
Next f2f
McCool: Agenda item 1: Next face-to-face, to be held in Prague
March 24-29, 2018.
<kaz> [12]Prague f2f wiki
[12] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_24-29_March_2018,_Prague,_Czech_Republic
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>
[13]https://github.com/mjkoster/wot-protocol-binding/blob/maste
r/Notification.pdf
[13] 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>
[14]https://github.com/mmccool/ndss-wot-sec/blob/master/ndss-wo
t-sec.pdf
[14] 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> [15]Koster's slides
[15] https://github.com/mjkoster/wot-protocol-binding/blob/master/Notification.pdf
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 description 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>
[16]https://github.com/mjkoster/wot-protocol-binding/blob/maste
r/Notification.pdf
[16] 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 [17]scribe.perl version
1.152 ([18]CVS log)
$Date: 2017/12/13 18:13:23 $
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 13 December 2017 18:15:38 UTC