[T2TRG] Minutes of the T2TRG Meeting, Sunday, 22nd March 2015

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 24 March 2015 20:40 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3FF1A8AE4 for <t2trg@ietfa.amsl.com>; Tue, 24 Mar 2015 13:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w58PErBNV-0C for <t2trg@ietfa.amsl.com>; Tue, 24 Mar 2015 13:40:04 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2F41A8ADF for <T2TRG@irtf.org>; Tue, 24 Mar 2015 13:40:04 -0700 (PDT)
Received: from [192.168.10.145] ([31.133.152.120]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MgpmG-1Ynemv2oAi-00M6tn for <T2TRG@irtf.org>; Tue, 24 Mar 2015 21:40:02 +0100
Message-ID: <5511CB9E.3020402@gmx.net>
Date: Tue, 24 Mar 2015 21:39:58 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: T2TRG@irtf.org
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="TJAGHqXruCKP0w4ln8X4Fvme32ufxoF6g"
X-Provags-ID: V03:K0:lrZ4tM1YaldhsYa7mo6VC+/mzRQ+4NWAvaykzmbjYjMYqrREM0c 7Lt2P3HI+4xMEzvq/nwgr1tjSstYXalNy0PM+nRRXLTnWVYmTcqJS4JSNKJWTQ2jLu4msR1 f9BOzk6Ks/XBBmPmgxQblarI74Z6YMw8t7AIYmo5m1v8K1Kqujld3qHHZkHdlwxUUGK2B7O 1jUkAPcz6jGeKff8px0gw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/t2trg/VQNJ7xAEU0uaLoxdQLzTO4_jeuo>
Subject: [T2TRG] Minutes of the T2TRG Meeting, Sunday, 22nd March 2015
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2015 20:40:08 -0000

Thing-to-Thing Research Group
-----------------------------

Sunday, 9am - 3pm

Slides are available at:
https://github.com/t2trg/2015-ietf92

Mailing List: t2trg@ietf.org ā€” subscribe at:
https://www.ietf.org/mailman/listinfo/t2trg

Idea of the research group is to use applied research based on actual
usage of the standard.
Development of evaluation framework.

Focus of the Sunday meeting:
   - Security and lifecycle
   - REST and Pubsub
   - Management and operation of networks involving constrained nodes.

1) Security Life Cycle (Sandeep Kumar)

Security lifecylce in managed professional systems (industry/office
environment).

Carsten: Possible research topic can be about the interaction between
usability and market differentiation.

Different legislative approaches may have an impact of design and
deployment of IoT devices globally.

Carsten: Decision in Europe that all IoT generated data is personal
data. Can we as engineer remove personal data so that we have easier
ways to deal with the data.

Discussion about what consent means for IoT and what the regulatory
situation is.

Hannes suggested to investigate technical solutions that allow data to
be stored encrypted on cloud environments.

Discussion about what key management means. Carsten suggests to get rid
of the term since it is not about the management of keys but rather the
management of credentials and associations. Sandeep suggested to look
and how to make them more mature (and easier to use).

Suggestion to only focus on the engineering aspects in privacy rather
than on the bigger privacy question. We should also describe non-goals.

Research group should focus on describing how the building blocks get used.

Dave Thaler suggests to look at different use cases of definition of
ownership and to categorize them. He mentions the example of a
buildings: hotel, student dormitory, rental home/timeshare, etc.

Possible topics:
   * Usability for enrolment
   * Engineering privacy
   * Description of building blocks to larger pieces
   * Ownership categories / lifecyle

Hannes raises the question whether companies are willing to contribute
to these efforts since those might be seen as competitive advantages and
the expertise might not be in the room.

Carsten is asking for a small group to summarize the key items in a
slide deck during lunch.

Carsten: Is there anything we can do till IETF#93?

2. REST beyond HTTP ā€” exploring the state/event duality

2.1 Publish-Subscribe Broker for CoAP (Michael Koster)

Is there a need to have a central server? Multicast could be used and it
does not require a central server.

Michael: No, that was just an example. The broker-less case using
multicast is interesting.

Question about idempotency of GET messages for the toggle operation.
Michael suggests to write something down.

Carsten: Multicast does not work. Those guys who worked on multicast
long moved on to CCNs, content distribution network and alike. We have
to learn from them why multicast is such a difficult thing to get it right.

Hannes raises concerns about using server-functionality on IoT devices
since it increases the attack surface for those devices and when DNS is
not used the question about naming show up, as illustrated in the
core-alt-names draft.

Multicast trees are actually mirrored by the proxy trees in CoAP. We
have to continue that sensors are servers since otherwise we will loose
the composability. Hence, the idea of mirror server. Carsten says that
this might not be a research question but at least an advanced
engineering question.

Problems raised with the model presented by Michael where REST mapped to
REST through PubSub in a light situation where a two-phase commit is
required.

Carsten: How can the client manage a set of resources?


2.2. Creating Automation Systems out of Things with REST (Andreas Scholz)

Georgios recommends to also look at distributed brokers.

Michael states that mechanisms to build relationships between devices
and services do not really exist today.

Currently I don't have a mechanism to introduce a broken into the system.

Hannes asks some clarifying questions regarding the

Andreas suggests to look at middleware frameworks and how they could use
CoAP.

Matthias suggests that we better understand what REST means. The CoRE
Interface draft provided one way but it is not the only approach.

How does the sensor actually know where to post to? We don't want to
configure all devices with information about the server where data is
posted to.
Hannes argues that there is little difference between configuring an IoT
device with information where to post data or to configure devices with
information about that other devices are allowed to access data on that
server.
Matthias argues that the use cases differ in terms of security.

Discussion about what the origin the data. For a toggle state where is
the origin? At the light or at the switch that sends the signal.

Carsten: We have to look at very concrete examples instead of talking in
abstract.
We have difficulties understanding how to setup these systems. We have
to understand management to design better system.

3. Managing the IoT

3.1. Ana Hedanping: Parameters to be monitored for IoT

Mehmet asked why the COMAN work is not mentioned. Here are the relevant:
https://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-05
https://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-05

3.2. Andy Bierman: RESTCONF and COMI

The IETF network management model moved from SNMP to Netconf and with
COMI there is now a new attempt to make the netconf work more efficient
(similar to how SNMP initially was):
http://www.ietf.org/id/draft-vanderstok-core-comi-06.txt

Carsten says that we have two choices:
 * Fall back to SNMP to have efficiency for network management
 * Work on ways to make network management for efficient.

Hannes added another option, namely to use IETF/OMA/IPSO Object

Andy argues that YANG is pretty important since it is used by management
tools.

There is not much difference between management data and application data.

Hannes argues that the difference is at the level of who needs access to
the data and points to the OMA LWM2M.

Carsten says that there are two approaches to advance this topic:
1) Look at the OMA LWM2M that solves certain use cases very well. Then,
extend it.
2) Look at the work done by the network management community and start
from there.

Andy mentioned that there is also network management work in ANIMA.

3.3 Determinism in the IoT: the example of 6TiSCH and OpenWSN (Thomas
Watteyne)

Thomas talked about 6TiSCH in his slide deck.

6TiSCH uses COMI for managing the schedule required for IEEE 802.15.4e

Thomas suggests that it would be good to have a list of research
challenge listed on the IETF webpage to solicit feedback from the
researchers.
Also the question how to get feedback from those who use the technology.

Carsten says that there is an incentive issue. Maybe the applied
research price could be helpful to encourage researchers to work on
problems we consider important.

Georgios mentioned that publishing the taxonomy/categories suggested by
Dave as a reference point for the research community.

3. Wrapup

Carsten asked whether the meeting was worthwhile? Overwhelmingly
participants said "yes".

Carsten asked whether it makes sense to talk to the W3C Web of Things
interest group. For example, a possibility would be meet with them (a
sort of co-located meeting).

### General ###

- Lifecycle
Discussion between Hannes & Carsten regarding the description of the
broker-less scenario.
Carsten clarifies that for him broker-less only refers to not using a
broker when accessing the
resource server. Brokers, like authorization servers, might still be used.

Was seen as useful to work on terminology for broker-less communication
/ lifecycle terminology first.
Carsten suggests to look at draft-garcia-core-security-06 since it might
be a valuable resource.

Interested persons: *Sandeep, Hannes, Goeran, Ari, Kerry, Carsten, Anna,
Emmanuel, Georgios, ...

- REST-as-we-use-it
Idea: Examples and explain how to map these examples to REST. What is a
consistent state / event model?
How and where are we {b,ext}ending the REST model?

Interested persons: Carsten, *Michael, *Matthias, Laurent, Andreas, Simon

- Selective Data Privacy based on draft-jennings-perpass-secure-rai-cloud-01

Interested persons: Sandeed, Hannes, Kerry,

* Evaluation / reference frameworks to compare between re-usable
components
    Technical parameters of scenarios/use cases (security credential
types, offered load, etc.)
    Could end up as a template for plug-tests. 	
    Hannes to share design pattern write-up.
	
Interested persons: Peter, *Thomas, Dominique, Anna, Hannes, Diego

### Ongoing Discussion ###

* Collect research questions and open issues
  Generic topic: How do we close the gap between standards community and
research
  Relates to evaluation frameworks

Interested persons: Kerry, Hannes, Sandeep

### Back-Burner ###

  * Out-of-band mechanism for raw public key verification
    Hannes could give a presentation about how this could be used.

## Freezer

  * Tool support
  * Data privacy issues and tools that can be used by manufacturers
  * Ownership classification for different domains (home, office, industry)
  * Usability
  * Description of the peer-to-peer / broker-less pattern
    (security, naming, multicast)
  * Security in PubSub model