CoRE @ IETF96, Minutes Draft 1.0
Chairs:
Thanks to the notetakers!
CoRE met Tuesday and Thursday. A summary of the results is given first; more detailed notes are in the next sections.
draft-ietf-core-block–21.txt is in the RFC editor queue.
draft-ietf-core-etch–01: WGLC is completed, issues discussed. To be determined: 4.12 vs. 4.09. When that is settled, updated version to be submitted to IESG.
draft-ietf-core-links-json–06 is in the middle of WGLC (till 2016–07–30) and was briefly discussed. There are some claims in the document that it considers a larger world of JSON-LD etc.; the intention however is to be a simple RFC 6690 mapping and those claims will be cut down.
draft-ietf-core-coap-tcp-tls–03: The merge of TCP/TLS, Websockets, Signaling, and BERT was completed in this version. Several issues discussed. In particular, there was in-room consensus to follow the lead of RFC 7252 and make the use of TLS mandatory to implement.
with the larger number of transport schemes now available, draft-silverajan-core-coap-protocol-negotiation–03 was discussed. There is good interest in this ongoing work, some of which is also related to other ongoing work in T2TRG.
draft-ietf-core-resource-directory–08 is nearing WGLC; reviewers have been identified.
Brief introductions were made for draft-gomez-core-tcp-constrained-node-networks–00, draft-groves-coap-webrtcdc–00, draft-zheng-core-coap-lantency-evaluation–00.
For draft-bormann-core-cocoa–04, there was in-room consensus for working-group adoption; to be confirmed on the list.
draft-ietf-core-http-mapping–13 took some minor fixes and has been submitted to IESG on 2016–07–22.
For the core-interfaces draft, the split was confirmed into draft-ietf-core-interfaces–05 and draft-groves-core-dynlink–00 (plus some material that was removed and maybe can be picked up by T2TRG); as not enough people had read the split-off draft-groves, we will take the otherwise obvious adoption to the list.
draft-ietf-core-yang-cbor–02: target is to do some additional validation with the NetMod experts and check again by end of September. There are a couple of implementations ongoing.
draft-somaraju-core-sid–01. One suggestion was to use a OID subtree. Too few people had read the newest version for room consensus on working-group adoption, but no-one against; to be taken to the list.
draft-veillette-core-cool & draft-vanderstok-comi: around 6 people read the draft, agreement on splitting out the more advanced features so a basic specification can be completed by the end of the year. Work ongoing on mapping YANG and LWM2M/IPSO objects. Some concerns about the diagnostic value of SIDs in debugging and possible problems with YANG “choice”, work needs to continue.
draft-hartke-core-e2e-security-reqs–01: good rewrite; further requirements are being identified, discussion to be taken to the mailing list.
draft-selander-ace-object-security–05: room consensus to adopt as WG item, to be confirmed on the mailing list.
draft-ietf-core-senml–02: good ongoing discussion that should be completed on the mailing list.
draft-koster-core-coap-pubsub–05: brokerless pubsub has been added. Take adoption to mailing list but clear room consensus already (~10 people), reviewers identified.
Chairs’ Intro
HTTP CoAP mapping
Many documents beyond current milestones are being discussed at CoRE.
draft-ietf-core-etch–01
Discussion:
Carsten: server that gets iPatch with non-idempotent change might want to send back error; which error? 4.12 does not fully apply; there are other options; need discussion
Peter: 409 is about concurrency issues
Carsten: Preconditions are more about the state of the resource, not what the clients sends (cf. If-Match etc.). Need more discussion
Michael: Should any responses contain hints about what went wrong? There needs to be some guidance then on the hints.
Jaime (as chair): once comments addressed; will send the doc forward. Shepherd write up already in progress.
draft-ietf-core-links-json–06
Discussion:
draft-ietf-core-coap-tcp-tls–03
Issues: https://github.com/core-wg/coap-tcp-tls/issues
Everything now on GitHub
03 merges different documents: CoAP-over-WebSockets, BERT, signaling
Need to close a number of issues
ALPN required conflicts with implementation support. Exception of the default COAPS port would help.
Observing resources works slightly different. Needs to be addressed.
Security considerations, MUST support TLS 1.2 or higher; how to enforce
Hannes: Inadequate-Security elective option sounds good to me.
Carsten: tried to design messages so that specific options specify how to act on; diagnostic payloads implementation specific. Not sure if a client that tries TLS 1.0 and gets this option as a result would then try TLS 1.2
Hannes: starting with TLS up front; would not see Abort message at all
Carsten: this is for the case where TLS is already setup but application rejects it
Hannes: app likely to define already what TLS handshakes to accept. Maybe we don’t need anything here.
Jim S: in order to get here; there has been two failures to choose TLS already (both endpoints accepted connection).
Matthias: what’s the use case? No control over TLS layer but detect thist at app layer. Prefer diagnostic payload since app specific behavior.
Brian: modeled after HTTP/2; diagnostic payload seems OK
Gabriel: could also be due to misconfiguration and not app issue. Clear signal good for debugging. Could be edge case.
Matthias: aborting is already clear standardized message. Misconfiguration case is already covered.
TLS MUST? (https://github.com/core-wg/coap-tcp-tls/issues/11) Anyone feels strongly about making TLS mandatory?
Capabilities and Settings Messages (https://github.com/core-wg/coap-tcp-tls/issues/16)
Websockets ping-pong vs signaling ping-pong (https://github.com/core-wg/coap-tcp-tls/issues/34) – WS: immediate pong; CoAP custody option to make sure queue is processed. CoAP is superset.
Should it be coaps+ws instead of coap+wss? (https://github.com/core-wg/coap-tcp-tls/issues/12)
Bill: ws for plain websockets, wss for tls. Lots of work on this in the previous transport draft. The scheme should be opaque.
Carsten: technically equivalent. Non-technical difference, so we need to think about the impact on the developer.
Bill: There should be text that the scheme is treated as opaque; we do not do any computation over it.
Dave: Agree with opaqueness, but avoiding developer confusion is important. Personally, I would pick coap+wss.
Show of hands - (roughly the same numbers) (many don’t care)
https://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiation–03
Discussion:
Zach: Agenda bash: Resource Directory is WG doc and we should do that first.
draft-ietf-core-resource-directory–08
Long list of updates. Clarifications and filling missing items.
Preparing for WGLC.
Carsten: 30 second pitches for drafts, please (no slides)
Carles G: TCP over constrained node networks. Lightweight operations of TCP. Other app layer protocols than CoAP considered for IoT, e.g., MQTT. Need considerations.
Christian G: Usage of CoAP over WebRTF datachannel. SCTP DTLS channel. Allow p2p communication for WebRTC endpoints using CoAP. Multiplex CoAP with RTP.
Zhen Cao: Measurement study of CoAP from Android phone with Wi-Fi.
https://tools.ietf.org/html/draft-bormann-core-cocoa–04
Core mechanism seems stable and well performing.
Fixed last comments and started IESG process.
draft-ietf-core-interfaces–05
Objective: Confirm document split
draft-groves-core-dynlink–00
Discuss adoption of dynlink split-off
Carsten: To which document is LWM2M now pointing?
Michael: Was the reason for splitting. LWM2M only uses conditional observe.
Carsten: Who has read the cutout draft? – 3 people
Hannes: It is only a document management issue, so the status should be preserved
Carsten: One issue might be to end up on different time lines. Should finish at the same time.
Hannes: It should finish earlier now, since researchy content was removed.
Christian: Depends on the ambition of the authors (and collaborators?)
Carsten: We now also have more authors, so we might finish before original milestone date
Carsten: take adoption to the list, requires more people to ensure consensus.
COMI and COOL (Alex)
draft-veillette-core-cool–02
Objective: Define next steps
Use YANG “contracts” for IoT
SIDs used for compressing module identifiers/paths
Roadmap; support for LWM2M planned
Open questions
draft-ietf-core-yang-cbor–02
Mapping to CBOR
Difficulty to map the liberal parts (e.g., XML in YANG)
Problems with union type
Delta encoding enables CBOR efficiancy
Questions
Alex: Should we put efficiency over strong typing? Tag everytime?
Andy: Code complexity when different options. I need deterministic results. YANG models need to be cleaned from ambiguity before they get out.
Carsten: How many regular attendees to NetMod (3). Please go to the mic.
Jim: Half of the problems can be solved tagging unions. ?
Carsten: One way to handle this would be by using SID.
Dave Thaler: Consider the use of simple debugging tools, TCPDump. Do not underestimate the power of easy debugging.
Alex: Getting back to this on the mailing list.
Alex: Two identifiers: SID or the name. Should we keep it simple and only allow integers?
Carsten: 6LowPan MIB, the string table is gonna be larger than the whole communication. What do you mean by keep?
Alex: That the implementation can actually recognize both.
Carsten: Then I need to keep those strings on my constrained device.
Andy: We do not need multiple ways to do the same thing, especially on constrained devices. Nobody provides short module names, so they can be very large.
Alex: union of multiple enumeration or bits with overlapping values or position won’t work if they don’t have the same meaning. Is this an issue?
Carsten: Summary as observer: we are about 96% there, but the last 4% are hard
Carsten: When are we done?
Alex: Some last checks with the NetMod people, then we should be done by November.
Peter: ??
Alex: We can continue discussing on mailing list. End of September could be a good time to “re-check”? this.
Carsten: Who has an or plans an implementation of this? (2–3)
SID draft: draft-somaraju-core-sid–01
Integer for every identifier in a module
Tool support, working on .SID files
Registration process: IANA registers blocks and hands them out to SDOs, which populate them for their modules.
Nice scaling for high numbers through CBOR and deltas
Alex: Ready for WG adoption?
Carsten: Who has read the draft? (4) Too few hands for room consensus.
Andy: This is also interesting outside constrained devices (YANG Push). This is going to be used there, it is definitely risky but we should work on it.
Carsten: Complexity is mostly on the policy side. When WGLC comes, we will use other WGs to ensure it is complete. Let’s take it to the list.
Carsten: No one against this work.
COMI/COOL drafts: draft-veillette-core-cool, draft-vanderstok-comi
Consistent with RESTconf bout default values
Four new Content Formats to identify CoOL data
Alex: Should we go with explicit Content Format Identifiers?
Carsten: Yes
Jabber: Mention the usage of block-wise transfers(?)
Alex: In order to minimize payload size. Instance-identifiers requested are elided. CBOR array is not used.
Peter: We already mentioned debugging and this makes debugging harder.
Michael: Does this also include Accept options?
Alex: Yes
Carsten: Accept is not needed, but it may be used to select.
Andy: This is totally broken for YANG Choices, where you do not know what the server will be sending.
Alex: We will need to look how this works. The main problem are the selecting strings in the request that would blow up the responses.
Requirements: draft-hartke-core-e2e-security-reqs–01
Abstract: This document analyses threats to CoAP message exchanges traversing proxies and derives the security requirements for mitigating those threats.
Objective: Confirm reviewers, with a goal of getting enough review for a call for adoption next.
Requirements
Dave Thaler: Given that this WG has a CoAP-HTTP proxy, are the requirements CoAP E2E or Payload.
Klaus: Full CoAP.
Göran: CoAP-HTTP proxy is not included. This is E2E between CoAP Client and Server.
Klaus: We think it is ready for WG adoption.
Carsten: There might security requirements that might not have confidentiality at the proxies.
Jim: Good rewrite. There are situations where proxies become trusted entities. Might be an issue with BERT.
Francesca: it would be great if this could be formulated in an email and sent to the mailing list.
OSCOAP: draft-selander-ace-object-security–05
Abstract:This document defines a method for in-layer security of CoAP message exchanges using the COSE format.
Objective: Discuss latest updates, ask for adoption
This is the solution to the Forwarding Case on the previous document.
Now includes block-wise, OSCOAP over TCP, new implementations (partly open source), ACE profile
draft-ietf-core-senml–02 2016–07–08 Ari
Objective: Confirm readiness for WG last-call
Need more work on extensibility
Metadata support, either inline with “m”/“bm” or external through Web Linking
URI Semantics for basenames
Michael: the draft suggests that senml could be used to represent collections. To me it needs to have something like this.
Cullen J: I am not in favor of this at all. Some people do NOT want URIs; they prefer a string (“channel0”, “channel/0”).
Zach: I agree with Cullen.
Christian A: Some applications won’t work because you concatenate to the base name (“//”). It requires more time to evaluate.
Michael: I can imagine doing an extension to use this explicitly.
Ari: I propose to keep the name as it is and clarify the issues.
Cullen: Several people do not want the uri be the name of the sensor. As an extension it makes sense.
Base stride
Ari: Should this be in the base document? Show of hands good for base (4), not good (3).
Tim Carrey: What happens if you are off-stride.
Ari: You don’t use it.
Ari: Propose that this is an extension. Show of hands (1)
Christian A: Need to clarify that nothing similar to this can exist in extensions.
Ari: Sounds good. It would say: No nested message structures, that is, no SenML in records.
Content Types per Record
draft-koster-core-coap-pubsub–05 2016–07–08 Michael
Objective: Define next steps for this draft
Brokerless pubsub added
Added Topic discovery methods, PATCH support, and queuing
Carsten: Who has read the most recent version? (~10)
Carsten: Who thinks who should make this a WG document? (more than 10)
Carsten: take to the list but quite a lot of consensus.
Carsten: Review by Jeng Wei, Hannes, Jim, Bill, Peter, ??.