[wot-ig/wg] minutes - 13 December 2017

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:37 UTC