IRTF T2T RG/W3C WoT IG Joint Meeting

Today's agenda

carsten: quickly skims the agenda

Reports from breakouts

W3C and IRTF Alignment

@@1: W3C WoT IG is tackling Thing Description

scribe: machine-readable format based on JSON-LD
... Data Model and Semantics and application protocols
... testing for IPv6
... understanding WoT IG's work
... long-running apps and status transition
... it sounds like generic and not application-specific
... "TD" stands for Thing Description
... mapping to CoAP
... abstract conept and bind to protocols
... focus on REST
... plugfest done for REST-full systems
... need to see how TD works for non-REST systems
... discussion on cookbook
... i.e., Ari's early adaptation document
... TD more like the entry points
... model of the services must be programmmed into the client
... collection resources (CoMi, CoOL)

<scribe> ... new concepts

UNKNOWN_SPEAKER: Question: should we have compatible "IoT" and Web" worlds? or isOK to have app/domain specific proxies?
... problem is nothing for testing
... PlugREST discussion
... T2T RG to finish our testing and W3C WoT IG to see the results
... big idea to use REST architecture
... joint meeting ind of January in France?

carsten: webex call, hangout, etc.?
... would be good to have discussion on the ML
... issues complete?

@@1: collection of resources

scribe: Alex will also continue that

ari: would try to discuss more

@@2: should not try everything

scribe: if there is a single resource, it's OK
... but not, we need resource collection

carsten: how to continue?

@@1: ought to continue discussion

Security breakout

carsten: what are the output documents
... draft-garcia
... cover whole lifecycle, avoid "media breaks"
... everything security, including ACE
... Sandeep's comments
... easily could become 100 of pages
... terminology
... SF's comments
... handing over device ownership
... e.g., hotel room scenario
... vendor role, OS provider, app-store provider, OEMs, ODMs
... cross domain, e.g., car-to-car communication
... Editor team: Sandeep, Mohit
... the second document: Security Bootstrapping
... very old document
... need more vendors
... a new survey document different from the previous one
... Contributors: Mohit, Carsten
... list solutions and reference draft-garcia
... everything securitybut not covered by ACE
... app security vs. network security
... pre-operational security issues
... terms
... pre-operational setup including discovery
... possible solutions documents
... small windows of vulnerability -- acceptability of limited opportunity to exploit
... usability
... per-solution charastrics
... manufactured with key
... out-of-band channels
... usability
... what is provisioned
... bundles
... interfaces to shopping systems
... peer-topeer vs. infrastructure-based
... registration, authentication of human users
... rebootstrapping, ownership handover

kaz: there is security discussion within the W3C Automotive group as well
... would suggest even stronger collaboration between IRTF T2T and W3C
... e.g., work with the W3C Automotive group as well

carsten: agree
... next, Report from W3C WoT IG
... Oliver reports from W3C WoT IG IoT breakout session
... W3C is a Member consortium, so need to be a Member company employee or an Invited Expert

cullen: W3C discussion is done using public mailing lists

carsten: consensus on landscape of security&privacy means
... extensive toolset for security&privacy
... web security mechanisms need to be standard
... technology generations
... classic (Kerberos, SAML, TLS, ...)

<scribe> ... new (OAuth, FIDO, ...)

UNKNOWN_SPEAKER: and future ones
... specific WoT needs
... physical objects
... constrained devices
... constrained networks
... TLS is the only really standardized one
... links to the W3C work
... https://www.w3.org/WoT/IG/wiki -> ttps://www.w3.org/WoT/IG/wiki/Security,_Privacy_and_Resilience -> https://www.w3.org/WoT/IG/wiki/Landscae_of)Security%26Privacy_Means -> https://wee.w3.org/WoT/IG/wiki/Design-time_Security%26Privacy_Means
... can invite people to W3C's bi-weekly webex calls
... other W3C WGs exist
... want to understand the relationship to Web security model
... Actuator security
... need freshness
... DTLS (replay protection) doesn't guard against delay attacks
... limited validty time of authorized commands
... 1st exchange: get a token and a clock value
... 2nd exchange: client updates the clock value ... another 2nd exchange: client updates the clock value again
... standardization for token and clock value
... ideas on the next steps?

dsr: happy to talk about my personal views

carsten: more like the breakout A (=W3C collaboration)
... move on the agenda
... alex to give his presentation

s/@@3:/alex:/

alex: would present a couple of slides
... CoOL (Constrained Objects Language)
... Alexander Pelov
... You want to manage things
... constrained domain vs. non-constrained domain
... RESTCONF + YANG model language

<michael> Is there a feed or file for the slides?

alex: yesterday we had a couple of discussion (during the breakout A)
... want to manage LPWAN (LR-WAN)
... 10000 devices per antenna
... 50kbps max (can be 270 bps)
... 1-10% dury cycle
... see draft-pelov-core-cosol-00
... CoOL
... CoOL + YANG
... Identifier 32 bits, CBOR magic (1 byte) + Collections

<Zakim> kaz, you wanted to ask about rent-a-car scenario

dsr: depending on the number of the server?

alex: T2T management
... Thread/ZigBee/Other
... Architecture
... CoOL client over CoAP client over Lower layers
... CoOL server
... CoOL
... perform on a single resources
... "Fields" option contains the list of nodes

s/nodes/nodes/selected, encoded using a CBOR array

scribe: CoMI vs CoOL - Identifiers
... CoMI: unmanaged, Hash(long identifier), Collisions (re-hashing, handling thousands of nodes)

CoOL: managed, module ID (20bits) + Node ID (10 bits), automatically allocated, cenral repository for modules, e.g., IANA
... regarding URI
... CoMI: BASE64 mapping (30bits -> 5URIsafe chars)
... Conclusion CoOL
... managed IDs
... RESTful collections

s/RESTfull/RESTful/

scribe: explicit PATCH
... use CoOL to manage apps
... next steps
... use of deterministic multimaps vs maps
... multicast for application management
... e.g., turning on all lights on one controller

daniel: @@@d

alex: module IDs
... 200-300

carsten: we have had discussions on what the efficient tools for managing devices
... structure of management information
... transition from SMI to YANG?
... next step to see RESTCONF
... module identifier
... YANG is xml-based
... using XPath
... have to do something for any cases

@@@4: constraint to get back to every device?

scribe: issues on hierarchical mechanism vs. flat mechanism

CoAP FETCH (Carsten)

UNKNOWN_SPEAKER: this problem
... https://maps.google.com/maps?........
... What if > ~ 1KiB?
... switch to POST?
... can send detailed parameters in payload instead
... lose GET properties
... safe, idempotent
... HTTP SEARCH
... like GET
... add a body
... no longer need to POST a > 1KiB search
... CoAP FETCH
... similar to HTTP SEARCH
... add request payload to a GET
... slightly different semantics: cacheable
... FETCH and collectins
... FETCH request payload has a media type
... can define application-specific formats
... addressing collections
... Caveat
... GET operates on a link
... FETCH additionally requires guidance how to construct payload (form relations!)
... with GET, can tell how to move to the destination
... FETCH rhymes with PATCH
... GET, PUT, POST, DELETE
... FETCH, iPATCH, PATCH
... patch payload, e.g. { * selector => action }
... moved towards to this general solution

johannes: clear mapping for FETCH?

carsten: good questions
... probably more than one operations for FETCH
... e.g., the long URI of Google Maps
... can be mechanically translated

johannes: might be a recommendation/guideline for that?

carsten: 1h50m till lunch
... can go into breakouts again

(some comments)

carsten: coffee break till eleven, and then breakouts

[ morning break ]

Charter (Carsten)

carsten: put topics on his emacs
... Charter
... -- deliverables
... ---- REST cookbook (limited discussion of HATEOAS)

<inserted> (from draft-keranen-t2trg-iot), design patterns

carsten: ---- security considerations (from draft-garcia)
... ---- bootstrapping survey (from draft-he)
...

<inserted> ... ---- link types, form types, HATEOAS

carsten: ---- plugREST
... ------ documents: reference framework, prototype formats/protocols
... ------ software

ari: give comments

carsten: updates the list

(some more comments)

carsten: a couple topics from draft-keranen-t2trg-iot
... milestones?
... next joint meeting with W3C in January?

dsr: Jan. 26?

joerg: maybe 28?
... actually earlier
... 25/26
... plugfest and plugrest might be linked to breakout a

carsten: splits plugREST into two pieces and bring "plugREST: initial testing" to track b
... goes to breakout b
... add "weekly activity mid-Nov to mid-Jan" to milestone section
... meetings:
... Jan 25th
... Eurocom says they have space to meet

<inserted> ... (April 12-14 W3C, North America, maybe MIT)

<inserted> ... IETF95, April 3-8, Buenos Aires

carsten: Berlin IETF96, July
... Carter for proposed RG
... Logs: https://jabber.ietf.org/logs/t2trg/
... T2TRG Charter: https://datatracker.ietf.org/rg/t2trg/charter/

joerg: suggest we make the charter discussion the focal at Sigcomm conf

Achilleas Kemos: AIOTI work

<inserted> achilleas: AIOTI European Commission

UNKNOWN_SPEAKER: achilleas: T2T RG work active in collaboration with IETF innovation
... 100M budget
... 6 big areas
... workshop Wednesday, 2015-11-04 in Brussels

[ break for Lunch till 1pm ]

breakout A: Room 304

breakout B: room 513

s/mark:/cullen:/g

- DRAFT -

IRTF T2T RG/W3C WoT IG Joint Meeting - Day 2

01 Nov 2015

Attendees

Contents