Minutes for CORE at IETF-93
minutes-93-core-1

CoRE WG @ IETF93 (Prague)
Minutes draft version 0.1 (raw).

Chairs:
Andrew Mcgregor <andrewmcgr@google.com>
Carsten Bormann <cabo@tzi.org>

Thanks to the notetakers:
    Brian Rosen
    Ari Keränen
    Thomas Fossati

IETF 93 core Tuesday minutes by Brian Rosen & Ari Keränen
          RFC-Editor's Queue:
                  draft-ietf-core-observe-16
          Waiting for shepherd write-up:
                  draft-ietf-core-block-17
          Charter proposal
                  https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt
          Discussion on the wording of how TLS is described. Will update text.
          Hannes: Why was this not sent to ADs already
          Chairs: There were some changes
          Akbar: Does the charter mention extensions to RD? Is such needed?
          Chairs: Offline discussion

          CoAP over reliable transports (40)
          -- finishing the TCP and TLS mapping:
                  draft-tschofenig-core-coap-tcp-tls-04
                  Chairs: Who read the draft?
                  --about 10 --
                  Chairs: Who has an opinion (on shim)?
                  --a few, including Carsten
                  Chairs: Who has needs for TCP?
                  -- several hands raised, both servers and clients
                  Chairs: who has implemented CoAP over TCP?
                  -- two independent implementations; mbed and californium.
                  Interoperate. ?Jabber: How do we handle confirmations?
                  -discussion of interaction between TCP and application level
                  confirmations Carsten: TCP has been around for a while, what
                  is missing? -- Application level confirmations needed Jabber:
                  header definitions needed for all transports J Paul: In our
                  switch implementations with mixed TCP and UDP, CON means it
                  worked end to end -- with TCP proxy, use always CON when
                  cross over UDP Klaus H: Confusion on what CON means:
                  retransmission not needed because message has been received.
                  There is no further semantics on CON except no need for
                  re-trans after ACK. Chair discussion of merging with
                  websockets draft. Hannes and Benjamin (jabber) disagreed on
                  the need to merge. draft-carey-core-std-msg-vs-trans-adapt-00
                  *) : People have proposed ideas that misuse NON/CON even with
                  UDP. : Dealing with any reliable transport is needed. Ben:
                  Not about NON/CON, it's about clear primitives : Need more
                  clarity in drafts, happening in TCP, leads towards merge of
                  websockets. <back and forth on merits of defining a messaging
                  layer, and possible effects on existing RFCs and drafts>
                  <presentation from Carsten on confirmable/non confirmable and
                  transfer of custody> <a lot of back and forth on what the ACK
                  hack does and doesn't do> Benjamin (jabber): the primitive is
                  the same in both those cases. This is exactly Tim's point.
                  define the primitives and how each transport provides them

                  Andrew: the ACK hack may be the de-facto way to do that
                  Carsten: 99% of cases don't do custody transfer. Big burden
                  to many applications.

                  Tim: if app does not want custody, can use NON
                  Carsten: but may need only message reliability, but no
                  stability

                  Tim: with UDP; the application layer buffer has received the
                  message. No more semantics needed. Simon: don't see use case
                  for ACK with TCP.

                  Tim: not referring to same custody. Can be failures between
                  socket and app layer. Transfer from TCP buffer to app layer
                  is not 100% reliable. Simon: but lack of response will tell
                  you that.

                  Ari: if you want real reliability, you should use response
                  codes. Even if ACK is sent, the app may still not act on it
                  (e.g., can crash, run out of resources, ...). Only after
                  response know for sure. So still need to use response codes.
                  Relying just on ACK does not buy anything. <Interested
                  parties will meet this week to discuss>

          Resource directory (25)
                  draft-rahman-core-advanced-rd-features-00
                  Michael K: group function is already supported for HTTP.

                  <discussion on sleepy device support and mirror server>
                  Michael K: no need for mirror proxy, just caching proxy.
                  Klaus H: with proxy no one knows you need to go through that
                  proxy to get data Michael: need to register with context
                  option. Already supported. Peter: large parts of MS
                  information in the sleepy nodes draft.

                  Bill S: indication of transport good idea. Check out the
                  drafts. : If you return full URLs, you get the scheme <author
                  asks for some charter text to mention new RD features Chairs:
                  have a draft on RD, so in the charter

          Interaction models/Support for normally-off nodes (20)
                  draft-koster-core-coap-pubsub-02                       
                  2015-07-06 <discussion on libcoap assuming if subscribe is
                  CON, then notifies always use CON.  Should be specified per
                  topic> <observation on block transfer?> Olaf: there is bug in
                  libcoap

                  Matthias: NON/CON issue popped up in plugtest. Server decides
                  how to notify clients. Should be independent from observe
                  request. Maybe publisher should decide. Topic/resource
                  decides.

                  Klaus: can't have max age in PUT/POST; not defined yet

                  Carsten: with block, how about updating one block of data.
                  Would like to maybe send that, but should here advice
                  against. Re-assembly always.

                  Carsten: need to be careful with term QoS

                  Chairs: How many people have read a recent draft
                  == about 5 --
                  Chairs: How many people will review?
                  -- more --
                  Tim: mentioned MQTT couple of times, have done full feature
                  comparison? Michael: not yet, might be good idea.

                  Darshak: origin and security; might be cases where I want
                  broker to host data but have it encrypted. Carsten/Michael:
                  need to clarify in the draft that it's doable with object
                  security

IETF 93 core Friday minutes by Thomas

* CoMI (Peter)
- clash resolution: assume that within the same module there is no clash, on
clash add module name - notification: keep it simple, i.e. one slot buffer.  to
get the whole stream the client need to Observe - select and keys parameters
syntax - TODO: (Fill in lost part from audio)

Peter: next step is call for WG adoption
AP: appreciation for this important piece of work
CB: small issue: the item has been added to the new charter, which needs a
couple of weeks to be approved Barry: no need to wait for the new charter to be
approved: clear for call for adoption now CB: this is important: it'll
influence the way we handle complicated resources HT: we are creating a
competitor model for LWM2M, which could create more interop problems and more
code CB: next is to call for adoption on the mailing list

* PATCH (Peter)
- PATCH idempotent?
CB: HTTP PATCH is not idempotent, if we want a non-idempotent PATCH we should
name it differently (IPATCH has been proposed).  produce examples, gain more
experience (suggest to continue the discussion on this on the mailing list)
Peter: atomicity and sequencing is a complex topic CB: suggest who is
interested in the topic to look at one (or more) specific content formats of
choice and see how that would work with an idempotent PATCH.  Once we collect
more information we can take an informed decision. CB:  who has read the
document (about 5)

* Simon reports on reliable transports hallway discussion

Simon will write a document to document the semantics of each message type so
that it can be reviewed and we eventually all agree on the semantics Main
points of the breakout session:
    1. Message type as defined in RFC 7252 shoud keep the same meaning
    regardless on what transport they are used 2. Some want to add a new
    feature in regard to what was discuss (the need for an appplicaiton layer
    confirmation) 3. The need or a message layer API needs to be evaluated

CB: who has an opinion on the length issue?
3-4 hands raised

Simon: main point to consider
1. what is the max length that the framing offers
2. what is the format of the framing

Simon: question for the chairs: where are we as to adoption?  Also, merging
reliable transports (TCP and websockets) in one doc is deferred CB: polls the
room for who do/don't want to merge 2 wants to merge, 2 don't want to merge

CB: the length issue must be solved before call for adoption
CB: people with an option need to meet to solve the issue

* Alternative Transports (Bill)
- -08, shibboleth: streamline!
- scheme hosts the transport information (done by London); do we need
guidelines on how to use the namespace?  just a set of recommendations or
should we establish formal rules?

CB: there seems to be some kind of confusion, some kind of guidelines is needed
JP: suggests {coap,coaps}+<transport> over coap+<transport>{,s}, this is what
they do at the moment BL: have you talked with Graham Klyne (designated expert
who reviews these things)? BS: yes, and we also spoke with Dave Thaler about
the registry BL: good to hear that these discussions have been done

CB: what is the next step for the document?
BS: authors feel it's ready for adoption
CB: is there any dependency of this on the TCP doc
Simon: (Fill in from audio)

CB: about time for call for adoption
some nodding noted
CB: will move the poll to the mailing list

Bill continues discussion on the URI-aliasing issue

* to be solved via Protocol negotiation (Bill again)

three people read the draft.  no one in the room thinks this is not important

* HTTP mapping draft (Carsten)
- all tickets closed
- ready for WGLC
- who's going to review it?
Michael K., Klaus, Darshak raise their hands
- three thorough reviews should be enough. we are going for WGLC and hope to
finish it off soon.

* CoRE interfaces (Michael K.)
- illustrates the high level concepts (Overview slide)
- goes through the recent updates to the document (Update slide)
- should we move it to standards track?  Michael thinks so.
- could the WADL be substituted by hypermedia controls?  Klaus has
hartke-core-apps-01 that is starting to looking into this same space quite a
few people in the room seem to be familiar with the draft CB: this has been
dormant for a while, it has still informed a lot of work in other SDOs.  the
discussion in the research group about how to do this thing in a proper way
shouldn't stop us for doing an RFC out of this.

JP: we are willing to use the bindings

AK: this document describes one way to do these things in a specific scenario;
the research group is going to carry the general discussion CB: we don't have
to take any decision at this point HT: back to the "Open Issues" slide: says
"NO" re: standards track; "YES" re: this is the way we recommend people to use
CoAP; "YES" re: hypermedia controls

* Object Security (Goran)
- wrap a CoAP message into an auth-encrypted COSE message
- two modes: COAP (include header, options and payload), PAYL (payload only)
- current version is -02:
    include block options
    use COSE profile
    provides overhead figures
- next steps:
    improve blockwise support
    uniform treatment re: encryption and integrity protection for options

GS: use cases?
MK: pubsub LWM2M would use this instead of DTLS transport

GS: what to do regarding size optimization?  (refers to a related presentation
done in COSE WG) HT: no strong opinion on this. I want to raise the point that
no one stepped up for cached-info option in TLS CB: TLS is difficult to
schedule for many here (agenda conflicts) CB: I will speak up in COSE to make
that useful for CoAP Raza: anything below 100 bytes overhead that is
encrypted/integrity protected is fine CB and RC discuss whether it's possible
or not to compare DTLS overhead with object security overhead.

* SenML (Ari)
- goes through the current version of the draft (see slides)
AK: is it ok to have base values at the beginning?
CB: who has read the draft in one of its incarnations?
20 people raise their hands
CB: who has implemented it?
5-7 people

John: we use a streaming parser (ordering matters there, plus other nits). 
will bring the discussion on the mailing list. AK: is the proposal broken? HT:
incompatibility with the security modes that we are considering? AK: let's
think about this more JA: it's not always a small set of data, could be
aggregate measurements and therefore very big Matthias: CBOR preserve order?
CB: CBOR is the same as JSON AMG: the proposed way supports google use case
with big amount of data AK: asks people to call for external parties using
SenML to ask them whether the proposed approach would break horribly.  if not,
I think we should be doing this way John: multiple bases are a good thing for
our use cases

AK: will continue on the proposed "Location of base values" and "Multiple
bases" then

* HTTP/2 for IoT  (Gabriel)
MK: is working on a binding of LWM2M to HTTP/2, and it's promising
AMG: notes that QUIC is not proprietary

Homeworks:
    read link formats (JSON, CBOR) and bring the discussion to the ML

meeting adjourned