owned this note
owned this note
Published
Linked with GitHub
# IETF/IRTF OMA SpecWorks joint meeting
https://github.com/t2trg/2019-07-oma/
## Attending
Michael Koster
Mark Yang
Klaus Hartke
Christian Amsüss
Ivaylo Petrov
Michael McCool
Rikard Höglund
Sandeep Akhouri
Michael Koster
Mark Yonge
Klaus Hartke
Christian Amsüss
Ivaylo Petrov
Michael Mccool
Rikard Höglund
Sandeep Akhouri
Dominique Barthel
Alan Soloway
Emile Stephan
Marco Tiloca
Martino Turcato
Jim Schaad
Mohammed Dadas
Hannes Tschofenig
Ari Keränen
Carsten Bormann
Ana Minaburo
Laurent Toutain
Matt Gillmore
Remotely:
Mojan Mohajer
Stanislaw Jakiel
Bill Silverajan
Joaquin Prado
## Tutorial about LwM2M with focus on the latest release (v1.1.1) Hannes
Hannes gave intro to LwM2M: https://github.com/t2trg/2019-07-oma/blob/master/slides/LwM2M_Tutorial.pdf
Dominique: LwM2M enforce device client/server roles?
Hannes: LwM2M client is on device, but it's usually a CoAP server. LwM2M server can be also in GW or elsewhere on premise.
McCool: URL scheme for LoRa stuff?
Hannes: yes
McCool: data model list of numbered references?
Hannes: will cover later in preso
Christian: SEND interface looks like CoAP non-trad responses? Aligned with IETF work?
AP: let's have a closer look at alignment of non-trad responses and SEND interface
Emile: can mix read and write composite?
(not today; would not map nicely to REST operations)
Alan: update could do something like this. Composite write should be atomic operation.
Alan: OSCORE object missing on slide 19, but is one of the core objects
(Q mode)
McCool: recommendation how long client should sleep?
Alan: up to device
Hannes: and use case. Spec doesn't go into details whether server caches values etc. and what is the behaviour on app server. That interface is outside of scope of LwM2M spec.
Bill: is there any provision give if transport address changes when the client goes offline?
Hannes: potential challenges especially if IP address changes and invalidates the sec context. The new version will have TLS Connection ID functionality.
Christian: why needed? When Q mode actions are performed registration has been updated and new TLS session established if needed?
Hannes: may need to run a new handshake (not in figure)
Mojan: worth indicating if new DTLS session need to register again.
Alan: re-reg is a costly process and need to establish observations. Costly operations. Want to avoid those as much as possible.
Hannes: not shown on slides but maybe discussion point for later
(slide 26)
Carsten: reason for including CBC?
Alan: commercial deployment. Some devices not going to be updated on others' timelines needed to keep usability.
Hannes: in 1.1 replaced lots of the text with algorithms. Added features to deal with error conditions etc.
Carsten: more about the SNI thing?
Hannes: In 1.0 it talked about DTLS, but not about extensions. In 1.0 you had to provision server such that client gets something that matches the server URI. That's a problem b/c it could be an IP address, and you don't want certificates for those.
Carsten: addition to URI also provision something that gives SNI information?
Hannes: Imagine the SMS case, or the URI for LoRA-WAN. Certificate contains an identifier that's expressed in the SNI, but information on how to contact the device on LoRA-WAN is in the URI.
Carsten: just instance of a general trend we need to work with. Need more info than in URI
Christian: or want to think of info in SNI as part of the URI
Carsten: before talk of mechanisms, need to talk what we want to have. Originally wanted all in URI. Getting more difficult.
Hannes: in some deployments server URI contains IP. Not using DNS. But don't want to have IP address in cert for good reasons. Even if change config info dont' want new certs
Christian: in OMA thinking in terms of of URIs or having an object with address and SNI next to each other?
Hannes: yes, really URI in LWM2M server. That's why needed LoRA URI scheme.
(slide 34)
Carsten: how trigger secured?
Hannes: existing security associations. During lifetime server can request client to re-bootstrap
(slide 35)
Carsten: "re-use" perhaps funny term for use of IETF stack
Alan: also small tweaks on top of CoAP etc
Hannes: object specs etc specific to LwM2M and not contributed to IANA so still some parts that are LwM2M specific
Laurent: in LPWAN WG doing compression. What is your position on this work?
Matt: would be outstanding to have stateless compression over any network
Alan: haven't talked about it yet
## Object Registry Matt
Matt presented IPSO work: https://github.com/t2trg/2019-07-oma/blob/master/slides/IPSO2019-OMA-UPDATE.pdf
Matt: IPSO models can be exchanged on any transport/transfer protocol. Focusing here on LwM2M.
Christian: how number registrires aligned with LwM2M and IPSO?
Matt: the same registry managed by OMA
Christian: when doing IPSO over non-LwM2M the LwM2M IDs dont' apply?
Matt: could use the LwM2M objects over non-LwM2M too.
Matt: also WiSUN use some of these objects
Hannes: also lots of other orgs and vendors have registered objects in the registry. For example lightning consortium and GSMA.
Ari: also github version of registry
Carsten: structure of object, instance etc. Resources have fields, like type float etc. Who defines those?
Matt: who defines object
Carsten: can have "type Carsten"
Ari: has to match LwM2M types
Hannes: using data types that don't exist would be problem
Carsten: how to evolve these vocabularies; what structure and what meaning
Hannes: spec with the XML schema tells the semantics
Carsten: need a rev of the spec for new data types (yes)
Hannes: opaque data type that's bit-string where could stuff stuff. For example for backward compatibility.
McCool: where we draw units from?
Hannes: discussion for later; decided to use SenML units. But some problems we run into.
Matt: years and seconds for example
Christian: BLE mapping; how much overlap with IPSO and netconf models? Is IPSO being used to conf network parts?
Matt: not aware of
Carsten: device object has some conf
Hannes: very simple, for constrained devices. Not talking about using LwM2M to conf routers.
Christian: SIM APN and PINs?
Matt: objects for that
Carsten: netconf is used e.g. with trains
## LwM2M v1.2 requirements Alan
Alan presented: https://github.com/t2trg/2019-07-oma/blob/master/slides/Joint_DM_IETF_LwM2MReq.pdf
Alan: these are the requirements we'll be working next
McCool: security impact?
Alan: industry problem. If you ask me, use OSCORE. Also have link layer security, ecosystem security, 3GPP Security. Not othogonal, but not defined for the GW. Not sure how will be solved here.
Christian: trigger mode?
Alan: telling device to connect.
Alan: info reporting might be interesting for IETF folks. Need special values that don't pertain that to whole observation set but onyl some observs. Write attributes: permanent change, but look here that you would override those per request.
MJK: like multiple attributes as discussed earlier?
Alan: related to partial updates. Can talk offline. Something ridiculous that needs to be revisited. But this requirement different. You want have here attribute for a certain request only.
Alan: Write attributes for observation parameters become defaults for observations that don't set them explicitly in query parameters. We want to make sure all this adheres to a standardized way. Even if just our standard.
Christian: wonder how edge works for observe that only returns true ever?
Alan: notifying going to to true but not to false. If have boolean attrib and want to know only when it goes to true. And I don't care when goes to false. Say, door is open.
Christian: any intermediary may swallow that notification because eventual state has not changed.
Hannes: There are no intermediaries now.
Klaus: valid use case but not supported by Observe RFC.
Alan: hence added it. Common point: should we contribute this back to IETF?
MJK: seems that additional filter for booleans should be discussed
Alan: what would IETF like to see process to implement when we want this kind of changes? Send email to Michael? Or have these meetings regularly? Write draft? Send to CoRE mailing list?
McCool: reminds of discusson in WoT for events vs observes. Different that Observe for eventual consistency.
Alan: observataions are chenges to persistent values. Events are occurrences.
Christian: could obs be used in a different way. For example how many times something changed could be exchanged with Observe.
Alan: when start adding complex logic, try to create local state machine. Now would have to model language to enable that. Also providing and/or logic accross multiple obs. For example "if temp less than X and door open". But that is not observation. Want to separate the complex thing from simple observation.
MJK: rule would be more than just obs logic
Alan: standard way to define rules from IETF would be great
Jim: with events, more interested in getting them delivered.
McCool: events vs alarms, care about them delivered. Eventual consistency OK with others.
Alan: significant advatantage when saving the air waves. When not sending individual elements but can make determination at the edge.
McCool: orthoghonal the events vs rules.
Klaus: Alan's question on how to proceed: when identifying such a gap where it's not obvious how to model something like "when is a door opening" with observe, many options: Could shoot email to the list and ask "why it's not there". But could also create extension and propose that. It could be great to quickly run extensions by the CoRE WG before putting it to standard. Have serious doubts that "only notify me when door opening by sending only 'true'" works.
Alan: so "don't do anything stupid and we'll tell you if you do". Sounds great!
Klaus: plenty of people in CoRE WG who are willing to have look at these. But can't follow all other SDOs using CoAP, so SDOs have to come to CoRE WG.
Alan: one issue that came up with IETF specs: have to have a look at RD registration lifetime of 60 seconds that would be useful to have shorter
Alan: also need a way for LwM2M client to refuse create/delete operations. How to model that.
McCool: when can't create new sensor, what's the error
Alan: we have simply return codes now
Carsten: can always have body in error payloads
Alan: want to have machine readable
Carsten: give it media type.
Christian: just not "diagnostic payload" (b/c that's what CoAP calls the payload if an unsuccessful response doesn't have a media type)
Alan: side comment: represent here my own opinions and views on this topic
Alan: lots of security reqs from Hannes (TLS 1.3)
Hannes: not just from me; the CID useful for many cases
Alan: There's group consensus that this makes sense as a requirement for the next release.
Alan: Firmware updates; talked about SUIT but there's more to it.
Stanislaw: why skipped DTLS requirement?
Alan (back to HLFR Communication Security slide): just giving high level here; not skipping
Stanislaw: Connection ID is still not approved standard, and moreover it's kind of controversial regarding the session ticket extension. Would like to know whether Connection ID will be a long-term supported extension, or quickly replaced by session ticket with state on the client.
Hannes: next week have TLS WG meeting. CID is on agenda. Hope if all goes smoothly that will go to IESG for approvale. Previously when talked about NATs and IP address changes, but that doesn't necessarily need full re-esblish but can use classic methods. Latest incarnation of the work providing more efficient mechansism than the ticket mechanism.
Alan: in general willing to use IETF drafts but not always possible. Try to minimize risk. If CID expected to be removed, we'd love to hear about it. If we see something in draft we are concerned about it's in our benefit to engage with you and make sure it's accepted part of a draft. When CID added to the spec, if not comfortable adding that, we may delay merging the PR to LwM2M TS.
Jim: It's not on the TLS agenda
Hannes: return routability check agenda item. That's the controversy.
Hannes (back to firmware slide): have two types of update mechs: software update for complex devices (like linux) but for lower end have simpler mech, Firmware update. Both can use SUIT.
Alan (on Bootstrapping): As explained earlier.
McCool: are we getting feedback on privacy? Persistent IDs for devices? LwM2M have them?
Alan: Yes.
McCool: Can they be rotated?
Hannes: Complicated question. Text in spec says that bootstrap server can rotate credentials used with LwM2M server, including the identifier.
McCool: got feedback that should avoid persistent IDs. Have device associated with person, could track person attached to device. Need to rotate IDs.
Alan: There's the industry concept of temporary non-trackable identifiers (like 5min valid identifiers). Not considered yet.
Hannes: have one form of temporary IDs. If Bootstrap server changes credentials server sees different IDs. Spec is open but discusses the issue. Here mroe about trusted 3rd party.
Christian: BS credentials come when device initiates BS
Alan: Profile identifiers. Much about optimization. Profile ID is optimized registration process by having predefined configuration.
Christian: sounds like something like could be aligned with static header compression
Alan: mentioned somewhere (SCHC).
Hannes: talked about different ways of compression
Alan: with SCHC, over LoRAWAN every byte important. We have a member who looks into this. Our URI def is objectid/objinstance/restype/res-instance. These could be compressed by making elements numbers.
McCool: profile IDs with common set of objects with single number sounds useful
Alan: different levels. This req specifically numeric IDs.
Chris: set of COAP options and data in payload.
Alan: is something IETF would do? We think these are changes to be made in our specs. If some of these ideas make sense at IETF?
Chris: similar ideas at IETF
Dominique: SCHC does this natively. Stateful.
Carsten: state lives longer than session
Hannes: colleague wanted to have stateless compression
Alan: for example right now ID 5700 is 4 bytes on wire. Number would be only 2.
Alan: created a depth parameter for discovery in RD. Depth=0 would send only objects. 1 would give resources too.
MJK: query parameter?
Alan: yes
Chris: filtering request to give only X long paths?
Alan: yes
Carsten: what components talking about?
Hannes: RD / discovery from client? Will have to have a look.
Carsten: Let's look into what this actually is during lunch break
Alan: It doesn't exist yet, it's just a requirement
Alan: have different views and discussions on BS vs. MS who can do what
Carsten: if client support v1.0 server (even if it's v1.1) interop with v1.0 server is fine from system PoV
Alan: negotiation to do that. Also "what optional features are implemented"? FETCH/PATCH are optional for client. Client can say "operation not allowed", or "don't do this on tuesdays". May need to have some representation of optional functionality support.
Carsten: several levels here. Protocol can make version transition: means that you can't communicate anymore. One use of versions. "I get 2.0 request, so as 1.0 server know I can not answer". Very good. But if object to maintain interop across different versions, version number usually doesn't work. Something like feature flags works better. Ability to ask "do you have this feature". Problem with future versions is that you don't know what is there.
Chris: version 1.1 becomes more marketing "I support all features from this release"
Alan: the discussions we're having. Basically at protocol level but just started the convos on feature level.
Carsten: features work as long as they are addititive. At some point you want to do cleanup and remove baggage. Then you have to do a version jump. Like HTTP 2.0 -- that's what a version is about, everything else is features.
McCool: negotiation like browser talks to server.
Carsten: HTTP 1.0 was interesting. When find out other client is older version, switch to that
McCool: In IoT, there are groundfill problems with devices stuck in versions.
Alan: can tell excplicitly, when asked from servers in network, are you always be updated first and support version in field? I was told "yes". Made my job easier. Server is responsible for backward compat.
Carsten: But what you described was the inverse, when a client finds an old server and has to use an older protocol.
Alan: think that's value-add from client PoV. If haven't updated server yet, the new client should be usable still.
Carsten: One way is to have all versions in all devices, or you do features.
Alan: regardless, we have requirement to do at least negotation. To know if we can do something.
McCool: asymmetric since clients are small
Alan: would expect servers to support all versions in the field
Chris: may want to remove the implied assumption this is done with versions
Alan: we have version field
Carsten: but good to not use that for all kind of evolution. Feature tag better.
Chris: if feature more about evolution
Carsten: on specifics for IETF things, need to support own versions but also evolution of application. CoAP has version number. I never expect to change.
Alan: FETCH/PATCH there?
Carsten: yes, feature. We have method numbers for extension. But how do I find out if other guy has feature. Don't have good way to find out. Except try and fail.
McCool: openGL had this problem for long time. Had machines that would lie which features they support. Problems with testing.
Alan: MQTT and HTTP 1.X support interesting. MQTT seems important enough for us to implement. We don't know the solution yet. Could be envelope or adaptation.
Carsten: CoAP over MQTT?
Alan: if more marketing? We do the easiest way. If also need support for MQTT infra, then becomes more binding on transport layer. Discussed this at the meeting. Will be addressing different transports.
Hannes: we have different ways to collab. We have public github for issues. Matt talked about object repo and open source implementations. For some items, opportunities for joint IETF contributions.
Alan: there is OneDM effort in industry. Everyone knows about the fragmentation issues. All of this causes significant issues. Several orgs got together, Zigbee, Z-wave, OMA, etc. There's no value add having data model and we should all talk same language. Not security, addressability,etc since there could distinguish. There's langauge defined on this. Is this something that should be just "well known" or should be captured in RFC? Easier to justify use of RFC than just something "everyone uses". Is it worth time for the industry for IETF to define a universal data model language.
McCool: already exists 6 langauges. Should we extend one of those?
Carsten: for IETF to take some work IETF wants change control. Something to discuss what that means.
Alan: this is not data models, but language
Carsten: IETF takes standard effort that IETF has change control. IETF will not do something stupid. But have to balance some considerations.
Alan: when have RFC, people tend to pay more attention and migrate. That's why we use CoAP, DTLS, SUIT, etc.
Carsten: like the idea
Ari: will be workin on OneDM in the WISHI hackathon over the weekend
Hannes: lunch, back in one hour
## Open discussion All
## OMA-IETF specification dependencies
Ari going through the documents from the agenda.
Hannes: adding "local base name" / or in unconference part.
Chris: More T2T communications for LwM2M?
Hannes: not for 1.2 but could be interesting later
MJK: proposed a design a few years ago
Hannes: so far mostly has been interest in the client-server model
MJK: bunch of issues for example on discovery
McCool: peer-to-peer to the unconf list
Bill: research topic for us: looking into edge computing. When have infra at the edge. When connectivity intermitten makes sense to have virtualized system to push LwM2M MS to the edge. Becomes more resistent to connectivity. Interesting for future topics.
McCool: more flexible architecture makes sense for edge computing
### CoAP over SMS
Carsten presented: https://github.com/t2trg/2019-07-oma/blob/master/slides/T2TRG-2019-07-OMA-SMS.pdf
Hannes gave short intro to OMA use of SMS:
* Triggering e.g., registration. Implemented and used.
* Transport for all messages on a device. Not well-received as SMS less and less used, little implementation.
Described mechanism has some lose ends to put it mildly. Hoped that mechanism that works efficiently would be specified, which could later be referenced by LwM2M, that would make things better.
Carsten: What are the issues: Document is old (2012-ish), and only describes how to do CoAP-over-UDP messages over SMS. Had two use cases back then, waking up devices and supporting applications where SMS is just the right thing (eg. parking lot sensors). Questions: What kind of SMS? It's an old service, defined in 1992, implementations vary; some only do 7-bit SMS which is not ASCII. Most IoT usage has been 8bit, draft describes both. Could simplify by saying it's 8bit only b/c it's 2019 now? Draft also had a mode going one direction over SMS and answer over "GPRS" (IP). That's interesting, but ahead of our time in 2012 – that discussion is not even finished now, so let's leave that out. Third point is how to do URI. Is that defined in LwM2M?
Hannes: Thought it's just sms, but look it up.
Carsten: make sure we don't break things. Good to revisit the case once.
Carsten: Example had phone numbers with leading zeros, E164 says that doesn't exist.
Hannes: our examples?
Klaus: in the draft
Carsten: Have to agree on scheme. sms:// is something different. Maybe if split is at security component and context address that's what you want ... but that's the URI discussion again.
Carsten: And we don't need a reliability layer, SMS does that, we can use the underlying transport's. We may still have messages as CONs and ACKs but w/o much meaning. Objective should be to find out what LwM2M does and stay compatible.
Laurent: max size with SMS?
Carsten: 140 bytes with binary. Have to take 2-3 bytes for fragmentation mechansims that is part of SMS. If willing to spend 3 SMS could use that.
Hannes: will check who implemented what. One company did CoAP-over-DTLS
Chris: question is CoAP over DTLS over SMS something to do in the same documt?
Carsten: Recommendation would be to take existing draft, strip down to what LwM2M does, only maybe extend later. We should also create DTLS over SMS doc in the IETF. And copy things from LwM2M spec to draft if license allows.
Hannes: parts of this were in IETF already in DTLS profile doc. Written by Thomas and I. So lots of this was already published as I-D. Will double-check.
Matt: binding in LwM2M is done with 8-bit coding.
Carsten: max compatibility with 7 bit but let's go with 8-bit. Last part easy technically harder process-wise. Could be TLS WG but they might not care.
Hannes: impact on DTLS is very small. Just timer settings.
Carsten: for 7925 created a new WG. Had some problems process-wise.
Bill: when Hannes presented LwM2M v1.1 didn't see difference of SMS with NO-SEC and smart card modes. Any difference there?
Hannes: would have to check. Current assumption: no difference. Had participants from smart card group who wanted to have smart card mentioned.
Carsten: action points for someone from OMA side to look into how SMS is being used with LwM2M. Verify the issues in the slides. Find out how URI being used.
Hannes: will do that.
Bill: have Github page for transport team (https://github.com/t2trg/transports) with issues there.
Klaus: also CoRE WG repo we should probably use (https://github.com/core-wg/sms).
### Resource Directory
Ari: Qualcomm wanted to make instead of 60s min lifetime have a shorter
(There is no interdependency with the 16-bit field counting in minutes in the RDAO option.)
Hannes: The problem showed up in testing!
Conclusion: let's abolish the lower limit
Hannes: also we hard-code to /rd path
Carsten: when you define a protocol that is based on HTTP; don't sit on the namespace server may want to use for something (https://tools.ietf.org/html/bcp190). But doesn't apply here if you use only for this purpose
Klaus: in CoRAL reef may want to then continue explore the way where links provided by client
Klaus: what parts of draft-ietf-core-resource-directory are used in LwM2M exactly?
Hannes: LwM2M only uses the registration interface (https://tools.ietf.org/html/draft-ietf-core-resource-directory-23#section-5.3)
Carsten: some issues on which method to use when
Hannes: also endpoint client name. In v1.1 made it optional.
Chris: is optional if your sec context has it
Carsten: which is maybe translation that server generates it from information available
Carsten: RD passed WGLC. Next step IESG. Area Director will review it and probably ship back to WG to fix some things. Next step IETF LC and might get responses of people outside of CoRE. Like DNS-SD folks. Now the WG is not in position to make changes, but we have AD and IETF reviews, we can still fix things.
### Dynlink
Hannes: we could use also band
MJK: 2015 discussion with OMA and IPSO on how observe stuff worked. Added then band as optional mode.
Hannes: current pmin, pmax etc matches?
MJK: should be, also state machine.
Hannes: good to double-check. Also should we push some things to IETF we speced?
...
Hannes: not all needs to be supported?
MJK no.
Hannes: no attributes for
Chris: in generic web doesn't work well as model
Carsten: in management want to have telemtry stream from devices. Current model is that you can subsribe to telemetry stream that is fixed. Or you can create your own telemetry stream for that. This creates app state in the server that allows you to subscribe to that. This is very similar to that.
MJK: in dynlink we didn't publish that as preffered method. Idea was that it was a special case
Carsten: in management really need it
MJK: empty PUT with query params was anti-pattern that didn't want. POST with payload better?
Hannes: problem that this was in 1.0 so would need two ways for backward compatibility. We want alignment, but if it's different doesn't make sense. Wanted to make dynlink normative.
Ari: can cherry-pick?
MJK: can point to different parts and say how they are applied.
Carsten: what we want is a common data model. Different ways to carry data. Query parameters one way. Whole query parametrs and POST payload is again the XML elements vs. attributes discussion.
MJK: could be appendix on how you do this
Hannes: OCF using?
MJK: OCF has their own thing. Properties on resource, doing min/max only.
Hannes: who is using this document?
Carsten: now intended status of dynlink is informational.
Hannes: but should be honest reference, that we use it.
MJK: make clear in the draft what is the storage and binding model. Could make distinction on protocol vs storage.
Klaus: need to fix descriotions of the attributes.
MJK: whole discussion if the attributes are acceptable or not
Klaus: now phrased in "compared to previous notifications sent". That is problematic for Observe PoV since observe doesn't support it at all. Consise summary: Observe is hop by hop. The query strings are end-to-end. Can't use parametrize query strings for hop by hop. We have to make it work for all CoAP ecosystem.
Hannes: one is transport issue, other is when to trigger transport
Klaus: now using resource parametrization to achieve where want to modify how observe works.
Hannes: don't modify how observe works. But something triggers transport of payload.
Klaus: now triggered based on condition relative to previous. Has to be based on the current state of the resource.
Chris: if two observe same resource. One client establishes observ and gets list of notifications. Other client gets another list. Proxy gets value and that is propagated. Now "last" value is different.
Klaus: there is no "previous notification"
Carsten: (draws a figure) if first client gets temperature and is 13. Second gets 20. Both have "observe >10". Then temp changes to 25. What happens? Hard to implement since need to remember for each client what was the last value.
Chris: proxy gives same value to both
Carsten: different query params, different resources. In this example same query params. Not possible to implement this in any meaningful way without keeping state per client.
Hannes: perfectly fine to have per-client state. Non-issue in LwM2M. Devices not talking to many MSs.
Carsten: the big interesting issue: CoAP is designed to allow multiple clients per server. If don't use that and thinking is shaped by 1-1 relations, then get different answers.
Hannes: not CoAP issue
Carsten: REST issue
Klaus: REST has stateless requirement
Hannes: but not application layer
Chris: safe requests may not get to app layer
Carsten: need to know what state to generate and what rep to give to whom and when. Today can implement the observe on CoAP layer.
MJK: not convinced that's a problem
Carsten: either application starts book-keeping and handles this -- CoAP library then needs to have ability to do this.
MJK: why two clients need to be kept in relation to each other?
Matt: need to have having correct values. If do microgrid and have voltage regulator.
MJK: seems you need to synch time
Matt: would use table where each has joined and keep track of that
MJK: seems only small addition to current observe
Carsten: the example of where temperature turns to 13 and never changes has challenges with eventual consistency here. We change that with the ">10".
MJK: might be system level problem.
Klaus: (draws a figure) if lost notification and not using CON notifications, what to do?
Carsten: if don't use CON notifications, things break here. At least every 24 hours.
Carsten: observe has seq number for order part
Chris: expectation with state machine to have possible list of changes to justify notification to client? OK for client to receive 20 and 21 but no 30 in between? If fine, we just maybe need to rephrase. If not, Observe not for us.
Carsten: still have to store app state in CoAP implementation or have to store obs state at the application level.
Bill: also if resource state does not change client may want notifications
Matt: pmax. But not good engineering configuration to have temperture step 10
Chris: but makes easy example
Klaus: recommende approach is to project your state with a function. For example rounds to multiple of 10 and observe that.
MJK: would be another mode. "Round = 10".
Hannes: worry that implementations will hugely vary. Even if sensor values are same would get different behaviour. If care of detailed values, maybe using attributes not the best idea.
MJK: have done prototypes with these attributes and didn't run into problems.
Hannes: pmin pmax in the same realm. Have to keep track when to provide response back.
MJK: not sure we concluded much. Adding round mode is one way.
Ari: issue described in the draft?
Matt: not broken and capable of being configed in useful way
Carsten: other way fixing example sending notifications to everyone when someone joins observers
Jim: keep state of last observe and at most everyone will get more than one they expect. Then in synch with everyone.
Chris: if OK there are more notifications, don't even need to go to round mode.
MJK: need STP if can't affor to miss one
Carsten: will have to write to get pass IESG: how damage someone who can do gets is limited.
...
Jim: next one joining should get theirs faster than expected but not the others
MJK: nature of the issue now known
### SenML units registry
Ari presented: https://github.com/t2trg/2019-07-oma/blob/master/slides/SenML%20units%20OMA-IETF%20meeting%2020190719.pdf
Units = short strings for units of measurement.
Ari: Units provide a semantic tag to the value. In LwM2M/IPSO, there's different usages of unit:
* all resources have an optional attribute in the schema that fixes its unit
* there can be a resource that is readable that sets the unit of the value of that object
LwM2M had no registry for that, recommended UCUM but didn't ratify that. Options were to use UCUM (but it's very rich, with several units for the same measurement (km, m, etc.)), so gave it a try and went with SenML instead, that's small and has one-unit-per-type. Some units missing, eg. J/m and bytes. Registering new short string identifiers that describe specified definitions.
Challenges: Scale. SenML doesn't put scale prefix in unit, but just base (eg. no km or days, just m and s). On wire there's JSON (4e3 m is 4km), CBOR has decimal fractions. That gives good comparability.
Carsten: Units in IPSO are used for two things. Could use them to send along unit with value, but usually is in model but not in instance. When it becomes easy to add to the instance, [...] can create cognitive dissonance: have to send more bits over the wire, like e3 or the CBOR exponent.
McCool: Unless exponent is in metadata.
Carsten: That. Can put scale into units, can also put scale into metadata. An attribute of the resource. Clean solution would be scale in IPSO schema.
Matt: Disagree, that makes us put scale everywhere.
McCool: [?]
Matt: We have hundreds of ms here now.
Ari: It's a schema change but backward compatible change if we go to s and 10^-3.
Carsten: Seems that minimum friction solution is additional registry with additional unit names, registered in terms of unit name (base unit), scale, and offset.
Ari: Second registry with derived units gives small set to use for interoperability.
Dominique: Some dimensions have different units (s, min), some only one (V, only with scale prefixes). Why not treat scaled units like secondary units?
Carsten: Advantage is that it's a machine readable resource, never have to touch code, only get new version of registry.
Michael: How about fractional units from base units (miles etc). Keep fractions?
Carsten: In SI, unit is vector of seven numbers. Some problematic ones (J/m) b/c something else has the units. Would recommend to add recommendation that scale units are only used in models, but in interchange (on the wire).
Hannes: In LwM2M, units can be in model or over wire as part of unit resource if queried.
McCool: Natural unit for time is s, but timestamps are composite number things (ISO format date). Carsten: But that's not a unit thing b/c you can't use it with a number.
Ari: What's something we could have for SenML that gives us some of the good properties but doesn't hurt too much?
Matt: Carsten has draft for degree etc. ms is the biggest impact to IPSO models.
Carsten: dBm vs. dBW (or even BW). That's where we need offset and not only factor.
McCool: Similar thing in illuminance.
Ari: Could we have that in SenML?
Carsten: dBm/BW would be in the secondary four-column table that's an extension of SenML, and LwM2M could reference into that table.
Hannes: Then still need scale?
Ari: scale and offset are in the table, if we go that route we don't need the scale per resource. Hannes: But say value is always multiples of 1000.
Ari: So then it's about compression.
Hannes: Like the separate table, solves our problem.
Ari: Converging on two-table approach. If that's even not enough ("something that's requested not gonna go through that registry even"), so maybe use also external registries and point into them (full-UCUM, own).
Carsten: That's the X- problem. Don't do that.
Ari: If someone wants furlongs per fortnight, still add to registry?
Carsten: Yes, if someone wants it. Designated expert only prevents *complete* nonsense.
Ari: Wrapping up; that could go into Carsten's document.
Jim: Can get a registry with informational document, that's fine.
AP: extend Carsten's SenML more units draft with the second IANA sub-registry for the units with less strict rules and ways to transform to units in the first registry.
## "Unconference-style" discussions (see list of proposed topics below) All
### Data model convergence
MK: SDF Simple Definition Format. ODM is activity to unify device/data models from different vendors. Normalized around events, actions, properties.
Temperature measurement thing could have "current" property, "read" action and overtemperature event.
Semantic definitions are created there that can be used in other kinds of protocol bindings. Take things already defined and define it in this format, and later convert it to all the other formats. Machine readable / convertible. High-level -- no need to talk about packing bitfields. Namespaces using CURIEs. Plain JSON format.
Hannes: translated to LwM2M, switch could be object, property resource and action executable resource?
MK: yes. OCF and OMA are just RESTful. Doesn't allow to say "event", "action".
MK: Can add semantic hints, eg. that the "on" action acts on the "value" property.
Carsten: when extend ODM with new keywords, all existing specs become carbage?
MJK: have to reserve all the name spaces. Could make more use of prefixes. Need to be more explicit what terms are from which namespace.
McCool: also ways like @-prefix
AP: will have to look SDF from this PoV. More namespaces.
Carsten: once have solved namespace issue, JSON rep has become unreadable. But can also translated to something readable.
(slide 6)
Ari: are the enum values from a namespace or literals?
MJK: need to think about this too.
Carsten: is this JSON schema fragment?
MJK: Meaning of data constraints comes from JSON schema. But we are (re-)using that.
Carsten: which JSON schema?
MJK: 07
Carsten: everyone using -04. JSON schema doesn't have namespaces. We need something that goes to SDF that solves the problem.
McCool: at least 3 places where JSON schema snippets used. Has weaknesses that need to be clarified. TD, OpenAPI has JSON schema embedded.
MJK: could use the names from the SDF in WoT TD to annotate controls. Not defining anything on wire except for data types. Could annotate TD or Swagger.
McCool: how to distinguish value of switch from other value?
MJK: choice, decided that value would be property of switch here. Could also make data type "transition time" and "value:.. type: transition time". All scoped relatively to the thing they are in.
Carsten: if translate to c++ creating class "switch" that has 3 members, one of which is data field "value" and two member functions "on" and "off"
MJK: could think of that way
Carsten: weird thing: type comes first, then list of things that are classes. And property. Weird to read.
MJK: Patter is inverted
McCool: syntactic thing, but can have events too. Not typical to C++ class.
Carsten: events not clear, but we'll find out
MJK: long term discussion
Klaus: memberss in class of C# are events, actions, properties. Like have Java add-listener pattern.
MJK: in nodeJS have handlers
Klaus: observer fits beautifully to pattern if always state change events
McCool: in TD observe on property. But events might not be associated with state change. Person in room might be event.
Klaus: in C# define properties and each property can have events
McCool: we have non-observables too
Klaus: could improve here with C# syntax?
MJK: Adding further constraints to JSON schema with bit fields etc.
MJK showed IPSO example: https://github.com/mjkoster/ODM-Examples/blob/master/tdl/ipso3300-new.sdf.json
Using re-usable resources and composing object from them. Same pattern as we have in XML.
Matt: how to handle reset action?
MJK: becomes ODM action. With IPSO don't even need protocol binding. The pattern is very consistent.
MJK: have example with "microns" units (um of hg)
McCool: units are contextual here
Carsten: how include works?
MJK: construct that includes another definition. Have new pattern in the SDF doc. No more include.
MJK: can also have defaults and consts. That's why use JSON schema -07.
MJK: also using JSON schema keywords, like oneOf. Could say measurement type is one of scalar or numeric type. Also anyOf possible. Want to use those in any place of the definition.
Ari: for testing LwM2M schemas in SDF can use the ipso2odm program: https://github.com/t2trg/wishi/wiki/IETF-105-Hackathon#ipso-to-onedm-translator
...
McCool: timeline of data standards converge. Couple of things to work on: many standards that use JSON schema inside to describe payload. Some use XML, etc. Would be nice if we don't have to worry about that. Could just stick data to db and not care how it's coded.
Currently no standard ways to convert XML attributes to JSON for example.
JSON-LD 1.1 is much more idiomatic JSON than 1.0. That's what used in WoT TD. Nice common format.
Ultimately want to have common semantics for IoT. What to do towards that? Iotschema has start but lots of work remains. Intermediate step to converge on common framework.
MJK: the goal of OneDM
McCool: if RDF in the background, that's fine.
MJK: big deal here is to use device type defs along with things like haystack to build a model.
McCool: want to build in one graph data base so can reason about it. Multiple resource / service descriptions: TD and OpenAPI. Fuzzy boundary what to use. Want in the end of the day to have one way to describe distributed systems. Would like to add semantic annotation to OpenAPI to facilitate this. If could use JSON-LD to enable semantic annotation, would be step forward.
If we had one data schema that is independent of encoding, would be useful for ingest. Just to do the structure, not semantics. Things like bidwitdths would go to standard that can be used to describe also CBOR etc.
Similar kind of potentials in edge computing. But also lots of battles being fought. Standardizing on data would help edge compute a lot.
Carsten: one thing, maybe not discussion here, trying to find out how XML fits to picture. CBOR, JSON, and YAML have same model, XML doesn't. YANG has been ported to JSON.
McCool: encoding the schema in JSON is fine, but trouble to describe structure of XML. Primarily interested in OPC-UA.
Carsten: guy coming to hackathon who is looking into formal description languages that could go to RFCs.
McCool: one question where this belongs? Have W3C here in the slides. IETF has activity but hasn't started off yet.
MJK: isn't "resource description" work already ongoing?
McCool: made up the word here
McCool: could annotate OpenAPI controls and have something like TD as result
### Role of hypermedia formats (CoRE link format, CoRAL) in LwM2M
Klaus gave whiteboard intro to CoRAL.
Klaus: link format has problems. Hard to parse. Has oddities. Originally for .well-known/core but then moved to RD and things got messy.
Carsten: data model is bad. Easy to parse actually, but next step has oddities.
Klaus: extensibility issue too. Additional rels, attributes. We don't have IANA registry for atributes (which we could create). Current relations not useful for IoT. And hard to get new entries there.
Klaus: other side: need to know what resosurces are there. In LwM2M don't know without discovery step how many instances are there. Need discovery even if know class of device. Once have discovered (CoAP) resource, need to know what is it about. Also want to know what can you do with the resource. Class of description could tell "can turn on" and might have protocol binging "can use POST". But with for example FETCH how do you know if it's supported. Would like to know what CoAP messages that you can use with a resource for example. Currently mostly avoid the discovery step but follow the OpenAPI Specs for example. From IoT perspective where have billions of devices deployed, and different devices have different date models, different things supported etc. CoRAL has primary use case: representation of resource that tells what is the resource, what can do about it, and how it relates to other resources. Can discover other resources and what to do with them based on that without doing trial and error.
Hannes: if go to my colleagues and tell we need to replace link format, they will ask what customer problem we are solving. Parsing they have solved already.
Klaus: would need help there, how much we currently have need for discovery of features and resources? In OneDM f2f had discussion on MVP of a fridge. Better not have that discussion at all but compose fridge of different components and discover that. All about long-term evolvability. Mostly about removing the cost of making changes.
Hannes: today in LwM2M the objects and instances are communicated in reg message so server knows what is implemented. Normally silod devices bound to application. Fridge would talk to whoever manges the device and would know what to do with that. In deployments have seen there is good understanding of that. Seems this is more dynamic environment. Smart home where devices showing up.
Klaus: multiple levels where could use hypermedia. In static view get devices, plug them, and have commissioning tool that retrieves descriptions and connects who is talking to whom. Still want to know since have huge amount of devices from different vendors that have subtle devices, what a concrete device can do. Can also go to higher level of hypermedia where the description tells also what can you do. For example device that is off would not give option to turn off. But can do just the static view too. There's overlap with TD.
Hannes: competing with TD?
Klaus: in purely static case yes, but lots of value in the dynamic view. Some talks with W3C guys to use CoRAL in parts where TD too static
MJK: was discussion on dynamic TD that would tell what can do next. With new object would get controls what can you do with it.
MJK: is there description language that underlies hypermedia here? Do I nede CoRAL file for each state? How to unerpin what gets on wire.
Klaus: full dynamic thing was probably what Fielding envisioned.
MJK: how can I generate clients without having to make lots of code
Klaus: don't have fleshed out proposals but interesting to work
Hannes: CoRAL in CoRE yet?
Carsten: WGA already ongoing
Klaus: overall thing stable but tweaking details.
MJK: examples and graphics would help with CoRAL. Now have to read a lot to get understanding.
Klaus: only need firsts 14 pages to understand and implement.
Carsten: CoRAL defines two serializations, but you only use one. CBOR hard to write manually and text representation has the name space sweetspot hit. But only for the text definition half of the text.
Klaus showed pub/sub broker example of CoRAL: https://github.com/core-wg/pubsub/blob/master/proposal.txt#L77
(section 3.1)
Klaus: can with coral choose if what you can do with resource is in the description or outside. Didn't use forms for pub/sub broker.
MJK: how was the namespace problem solved?
Klaus: for weblinking RFC can have IANA registered or extension types. Here with "using" defining default name space and then have prefixes.
McCool: how compares to Turtle?
Klaus: compact binary format. working on lighweight simple compression.
Carsten: 10 IETFs ago presented "type 6" compression. Generalized way to do what makes this stuff compact. Do we want to have general compression or semantic compression? In type-6 strings that have same prefix might turn out to use different prefix. Hard to process as strings. Trade-off there. We should develop both, look at the result, and see what is better. I have written code for type-6 but no text yet.
Hannes: where's the code?
Carsten: locally on my laptop. Writing compressor is harder than decompression.
Klaus: now collecting real-world examples of CoRAL docs and using those trying to find best compression. As example good to have LwM2M link formats as CoRAL and see what works best.
Ari: CoRAL could have potential for how can you add to an object without revving the spec
### Access control modeling
Carsten: ...all existing ACL models compress the lists somehow. For example in filesystems have groups to compress strcutre of ACLs. Interesting to see how we model this ACL information in various places. Is there something IETF/someone could do. Also easier for one org to pick what others hav done. No concrete proposal for what OMA should do here. But good to think of OMA systems in access matrix. Also access matrices of other orgs, like OCF. Is there something missing? Number of subjects smaller in OMA since only servers do access.
Hannes: is there lot of issue with access control first place? Constrained device here.
Carsten: several aspects 1) before can do AC, need to have authenticated various parties. Usually difficult part. Then relatively simple to do AC. Only few different roles. But auth needs to authorized too. Creates weird cert chains etc.
Hannes: haven't seen for constrained device multiple servers often. Have to deal with state, etc. BS has access to everything and MS not to security material. In LwM2M also more elaborate part with entity can access which resources.
Carsten: with speaker have volume, and can have like max volume. Maybe latter only accessible by some.
McCool: also roles; set of users that have certain rights.
Hannes: when had the use cases in ACE; access control not provisioned. Different model. In LwM2M BS provisions the ACL strucutres. In ACE more token based. Implemented in undefined way what distinguishes how abstract permissions map to local things. Implementors define this.
Carsten: to interop between different world, need the concept of roles.
Hannes: Do we know how people do it today? Only see our products, don't see your (McCool) Intel products.
McCool: comparing to modern operating systems...
Hannes: Wrong comparison. Windows/Linux are very sophisticated, different usage model. IoT is much more constrained, and what's written in a specification like LwM2M has many things that could be theoretically done but aren't, less that's implemented and even less that's used.
McCool: With high complexity comes cost and complexity for users.
Hannes: Didn't even think about user experience, but about complexity on devices, which pushes them to larger processors with larger systems with their own processes.
McCool: OAuth has scopes etc
Hannes: It was assumed that there were all those policies, but even then there was pre-setup required to use that. And still, that was more appealing to developers than XACML (Oasis document).
McCool: And then there's all that attribute and role based access control.
Hannes: Are there such speakers like the one Carsten suggested, and how do they do that?
McCool: See more need for strong access control in military or safety critical applications. RBAC comes up there often.
Carsten: People say that you need more complicated things in gov't/industrial, and that's a question of what "need" means. Many things we do are enabled by having the right security. If we didn't have lockable doors, our daily lives would be different. Someone w/o that experience might not see them as solutions to their problems. Having the right enablers around gives you a way to define products that can do way more than today.
McCool: Reminds me of perimeter security discussion, and … . Finance also uses RBAC for limited liability, b/c nobody can blame them for doing things they didn't have permissions to.
Carsten: Reasons why speakers are not like that is because w/ today's access control, it's hard to do.
Hannes: that's what trying to find out.
Carsten: Some parental control do thigns in that space, maybe not for separate speakers.
McCool: "role based stuff" don't need to update clients (see XACML wikipedia page).
Hannes: Guess it depends on the communication model. In ACE/OAuth we had technician in smart factory use cases, that connects directly to device. In many cases, whole point of internet connected devices is you can go through the internet and everything through a pipe and do access control there.
Jim: Offload the decisions.
McCool: can manage roles in higher level; clients can be simpler
Hannes: When device produces just raw data, what is exposed is a very different view becaus it cares about different aspects.
Mccool: unclear if we need complicated systems for sensors. If access to data in database/service level
Carsten: When you do it right, it is a task delegation architecture. As little business / application logic as possible on device, then fan out to somebody else. But in the end the device needs to protect itself.
McCool: are important roles like who is allowed to update the device
Hannes: Classical approach, you don't need dedicated access control for firmware updates, it's sufficient to have a trust anchor and then what [...] says.
Jim: often fairly complicated; attribute based
Carsten: A certificate tries to be a parameter to an authorization policy, so what does it mean, and how to you arrive at a decision in a sea of certificates.
Jim: If there is an attribute that says that they can update firmware, the devices can all look in that field again, just have to set up the certificate up the same way.
Hannes: We did not describe in SUIT what needs to be in the certificate to authorize the update.
Carsten: other thing trying to do alot: what are the statements that can make about a network? WRT access control would be nice to enquire components of the network what are the access control policies. That asks for some form of standardization, so a mgmt application can find the vulnerabilities.
Hannes: would query for example router?
Chris: all routers
Carsten: sometimes even all iot devices. For example what's your software version. Who controls you.
Hannes: In LwM2M you get to know details about software version, and who controls it (but only after you already went through security).
McCool: should have some access control before query these things
Jim: Might say "go talk to that guy for access control"
Hannes: But it doesn't.
Carsten: in brave new world of networks built out of jails where we're going, may not get out of jail without providing some access control info
Jim: MUD describes some of the stuff that goes into certificates.
Ari: So where is potential for alignment?
Hannes: someone probably did that homework? What are the different modeling techs for access control policies. We have been complaining about our design. Feels complicated to implement. Now those who care have implemented. Those who don't care, haven't implemented. So nobody cares enough to fix this.
Maybe OCF has a better approach to this, maybe look at operating system access control policies.
Jim: Anything that actually controls access to resources in OMA, or is it only "can" or "can't"?
Hannes: "for an object ID and instance, this server is allowed to Read Write Exec"
Chris: talking of several servers per client.
Hannes: exists but not very common due to the need to keep all the different states.
Ari: common model (in discussions): one MS for managing and another for application with access to IPSO objects only
Hannes: hard to get good info of real deployments because not public.
Jim: SSL scanning gives wrong positives too (non-HTTP)
Hannes: Yes but here we don't get data at all; those devices don't wait for incoming connections.
Ari: Back to convergence. If we had more common ground there, ...?
Hannes: Yes, could be.
Ari: Since many have not implemented ACL in LwM2M because complex, would it make sense to use a model that is shared by many orgs (OMA, OCF, etc.) so that we would have common mechanisms and code to use. All would benefit. So matter of talking to them, ask what they use, what they think they're missing.
Hannes, Jim: would be interesting survey.
Ari: and IETF natural place to spec these together
### Serious Transfer Pattern
Carsten: Did short draft to remind that observation is not getting a whole time series. If we want to make sure a sequence of "events" are there, have to do more complicated things. Problem is that when having an event generating/recording device, and someone observes, how do we know that all events got there? Becomes interesting if there is a second client that also observes and also wants all. Any RESTful way needs state per client. That needs to reside in the client. At any request the client sends to server, it needs to send a bit of that state, in the simplest case the serial number. Therefrom comes the series transfer pattern. If a client doesn't tell you how far it got, it's hard to make sure it got all of it.
Carsten: b/c devices generate small events, usually want to do some paging. Trick is to build a page structure that's useful for conveying multiple events in one request. Can be done with a head resource that contains link to most recent page, that's observable, and it changes. All pages end in another link.
Carsten: Other question is custody transfer. Original owner at some point is satisfied that copies are in safety, and can delete them. Criteria are application dependent, no generic answer.
Hannes: Could have used that for logging mechanism.
Carsten: logging is interesting example, still different from sales. With sales, data Can Not Be Lost. If something goes wrong in selling logic, you stop selling. With loggin, you don't stop logging but have a strategy for discarding data.
Carsten: short draft, stands for it self. Have a look and see if it solves problems. Are interested in feedback on how to improve it.
Klaus: Even described two or three approaches to series transfer, also in the document. Important is that getting all the list of data items doesn't necessarily happen as fast as possible.
Sometimes need to inform as fast as possible but sometimes need lossless history. This is more in getting-entire-history class.
Carsten: if need full history can't do getless logging
McCool: Reminds me of blockchains. Also relevant for provenance of sensor data.
Carsten: need variant of Godwind's law. If someone says Blockchain the discussion is ended.
## Conclusion and next steps All
Hannes: we had couple of background presos and action points
Hannes: I'll just start picking takeaways. I had item to look at CoAP-over-DTLS-over-SMS to see whether that can become draft. Reach out to OMA to have ppl look at RD and check registration interface. From dynlink, there is potential for alignment but also homework, specifically Carsten's/Klaus's drawing.
Ari: work on clarifying in dynlink draft how the observ parameters actually work and lookinto mechanisms to achieve what we wanted to achieve
Hannes: Then there's SenML second table, populating it, extending offset/prefix/scale-up.
Hannes: Next Testfest; there might be a possibility for online participation
Ari: On engaging the CoRE mailing list, conclusion was OMA should be more active and just preemptively fire mail to CoRE; so that's a generic action item.
Ari: On security mechanisms, survey for common mechanisms and common code.
Ari: And then the whole data model convergence. Thanks both Michaels. On OMA, it's more making sure we make our part fitting nicely in the picture. OMA is interested to be part of that. Let's keep good collaboration going.
Hannes: Have a look at the object repository we're planning: gas/water/electricity metering objects are being added.
Carsten: When next time?
Ari: Yes, more often.
Hannes: Next IETF meeting is not ideal for us b/c no contacts in Seoul. Next is Vancouver. Could come up with similar setup, combining OMA face-to-face with IETF. Tough on us, b/c exhausted even before hackathon.
Ari: IETF is set for five years, aim for alingment from OMA side.
Hannes: March would be possibility.
Carsten: OMA has the ball to look at their scheduling.
Christian: Have virtual meetings as well.
Ari, Carsten, Hannes: Yes.
Ari: Best suitable for more concrete issues.
Hannes: There's also fair overlap between all of us, companies implementing/deploying etc.