# T2TRG/OneDM pre-IETF107 work meeting

Attending: (your name here)
Amelie Gyrard
Ari Keränen (AK)
Carsten Bormann (CB)
David Dai
Ege Korka (EK)
Henk Birkholz (HB)
Jason Koh
Jim Schaad
Juan Carlos
Klaus Hartke
Michael Koster (MJK)
Michael McCool (MM)
Michael Richardson (MCR)
Niklas Widell
Sebastian Kaebisch (SK)
Wouter van der Beek (WB)

Agenda

09:00..09:10 Welcome, Logistics
09:10..09:40 Versioning/evolution of data models/data model language
09:40..11:20 OneDM key technical issues
11:20..11:50 OneDM SDF and IETF standardization
11:50..12:00 Wrap-up and close

## Welcome, Logistics (CB)

Slides: https://github.com/t2trg/2020-03-vancouver/blob/master/slides/2020-03-20-vancouver.pdf

The meeting was originally planned f2f but now virtual. RG has events where we try to figure out how to advance things together. This WS is on standards that are being created right now. Bringing together here OneDM liaison group (that doesn't officially exist yet; just like IETF didn't used to). Informal group of IoT SDOs trying to get common data models for IoT devices. Including interaction models.

OneDM successful in having 3-digit set of datamodels and common idea of language that is used to represent models.
OTOH have T2TRG that is RG inside IRTF (IETF research arm). IETF creates standards and we in RG look for missing gaps and things to do, for example at IETF.

(agenda bash; no comments)

## Versioning/evolution of data models/data model language (CB)

Evolution and versioning discussions in the WISHI calls. Evolution comes at different levels. One is that models evolve over time. During development; when sloppy versioning maybe OK. After agreement they also evolve. Need to handle the evolution in a way that not all changes are destructive. Also SDF language will evolve; get new features. Hopefully staying backward-compatible, but even that is not given. Need to have different versions of SDF co-exist. Different models with different versions of language.

Important to make note what exactly talking about, e.g. schema of syntax of language or models.

"Versioning" is not actually what you want. Often can better describe evolution of interface with "features". Can be unidirectional announcement; becomes actionable if/(not) acted upon by a peer. Different kind: interpretation agreement, "we all speak French". Preventing false interop important aspect here. To make sure French is not mistaken for German.

Version is a set of features that are "blessed". Collectively discussed with version number that is restricted to linear space. Makes sense for software but much less for interface definition. Sometimes makes sense to roll up set of features to version.

Third term: revision. Specific "files" have revisions. For example fix a typo in comment. Not necessarily creating a new version. Lexical state of file that is used in environment, data model of schema. Changing that doesn't mean we change the interface.

Lamp may or may not have RGB feature. Another thing that is relevant for evolution. Difference between capability of a model and capability of implementation that uses the model. Also with roll-ups new versions of models that unify features.

Any particular model will use one specific language. Need features A,B, and C. Model would declare unidirectionally what features it assumes. Interop requirement. Can also be optional features that can be ignored.

Models also have names. And could be referenced from other models or a device may refer to a model. Not interested to a specific revision. Sometimes we reference docs that are meant to evolve. Don't always reference one specific revision. Something what YANG folks are trying to do. There need to indicate that revision. But makes very hard to fix a bug since need to change all specs that referrnce that.

In software use often semantic versioning. For example, "2.5 and 2.3 are both OK". Would have interesting features for interface description. Versioned references important part of model.

Also want to know if language spec implements the features of model spec. Usually expensive to have spec evolve and all implementations have all features. Better to say this is SDF 2.0 but we only use features A and B. Need to find out if we want to reference specific revision, semver, or features. The last one most interesting. How can lamp say "I'm lamp and using that model and also use these features".

MJK: makes sense to think from point of view of refences. Most informative thing we can do. Immediately made to think "I don't want to carry around logic to apply different schemas to different instances of thing". Complex if different models point to different schemas. If just used for validation. Don't want to pile set of strings to single reference. Indicating features as individual things; capabilities are by nature backward compatible. Could add without changing version. When agreement changes that's when needs more rigorous review.

CB: in perfect world capabilities would be orthogonal. In reality not always true. Interpretation agreements needed to avoid false interop. More disruptive but great opportunities to clean things up. For example in HTTP 2 could take a lot of cruft from headers that were put there to work with 1.0 implementations.

MJK: seems consistent with not wanting to carry too many schemas but maybe have a few

M-J: how to deal with systems that are dynamic. Where feature could be time-based. Feature important now but may not be tomorrow. Timestamped features. To make difference between current and stale information.

MM: how would remove a feature? How to represent that?

CB: could imagine on specific features being available on device. For example stops supporting TLS 1.0. Less about features that spec language has. Implementations that uses old version of language will always be around. For new implementations could point not to use that.

MJK: like with Python 3. Both co-exists but phase out one over time.

MM: Might be brownfield devices that can't be updated easily.

AK: one way to deal with faetures coming and going is to (re)discover occasionally

WB: huge difference between data modeling and what is implemented on device. So far more about what device can do. Not much to do with data modelling.
What can be implemented /defined in DM, can be already a subset. Up to ecosystem to convey what is the subset. All requirement of DM need to be transported.

CB: may not be known what model supports when it was defined. Two levels of talking about this are inter related because features are added over time.

WB: if have model A, and want to add something optional, need to indicate that. And if is available. If want to add something that is mandatory, should probably not call data model A but Av2, so that it's know there's fundamental change since something mandatory added. Adding new model that encapsulates big part of the old model. Normal way of doing versioning.

CB: interesting case where want to evolve model, and want to make something mandatory, say TLS 1.3. But all brownfield that not aware, need to support TLS 1.2. Have mandatory part in model that the peer device doesn't care that doesn't hat doesn't hat does from device interop point of view and need to handle at interop level.

WB: not sure if TLS stuff is right example. Rather servers do DM A and Av2. From client side need to have support for both. Some forward compatibility needed on client side or at least more upgradeability. If everything upgradable could do that. But in brownfield never have that possibility. In factory might be, but in smart home where people buy devices from different vendors and have mix of features, likelihood that device A will use older model, that could have been updaged, but didn't do that is quite common.

CB: agree TLS maybe not best example. One thing we may want to take some work that illustrates what we want to do here. So that we can point to those when we explain our design decision

MJK: also when talking of models and language. How much lang versioning should we embed in the model? Maybe time to start talking about strawman for langauge and models that use SDF language.

CB: we should go home with what we want to do; taking home the need for examples is very useful. Also someone needs to write this up. Looking for people who are interested.

AK: some written up already by Jaime; could continue from there. Anyone interested contribute please let us chairs know.

CB: Also have versioning considerations for SenML ongoing now at CoRE WG

## OneDM key technical issues (MJK)

Hoping to have with OneDM: something people can count on being stable. Want to start being more consistent on releases etc. Versioning scheme in the heart of this.

Version scheme for language and models as discussed. Don't currently version models for Smartthings. Have policy that we don't version things. If make big changes, make a different model. Doesn't always work; have special exceptions, etc. Also doesn't allow for the evolvability people like. Hoping to contribute our models to OneDM.
Creating new versions of models might be a breaking change \[and this discourages evolving models].

We have semantic versioning and Github path with versions. Might be directory that points to schema and markdown. Accompanying schema with the models. Version models based on branches. Look like directories that have semver in the path. Concrete proposal we have on the table if no better way to do that.

Language versioning rules; have to figure out scope of changes that trigger versions. Would say we want to have only few. Or maybe no version changes at all.

For models, one further idea: coupling models to versions. Have quality in SDF models that is key-value pair that says "SDF version" and points to the URI that is the version this model is expected to conform too. But seems to have its own set of problems. Peoples opinions on these? Model versioning, features can be added and don't worry about versions? For language versions have github branch with files? Require that models point to schemas they expect to validate with? Also subject to discussion if models would validate against new scehmas.

CB: fact that model complies with specific syntax for model is almost unrelated to fact if it uses particular version of language. If we fix some problem in meaning of language, that may mean that specific instance can be interpreted differently [?]. That instance validates for schema is nice but does not tell what version of language was used.

MJK: version of lang may change independently of schema. Can change the syntax without changing meaning to fix a typo (like "writable vs writeable"). Would we say that inclusive OR that would trigger language version change? Most restrictive.

CB: in general case yes, there are cases where you can get away with. If clarify something in language. Any version or update to language needs a spec to indicate that it's used. Whether model as version number of features mostly has barring on how inexpensive it's to make the change. Features are cheaper.

MJK: editorial changes can do without changing language version. Revisions. Anything that adds capability/feature to language requires a revision, but not necessarily a version. That class is interesting; limits the amount of versions.

CB: if language has good extension points that limits versions. With CDDL have control operator that allows adding features without changing versions. Looking at spec what operators are used, can know what features are used.

MJK: analogous to W3C TD with protocol bindings that don't require changing TD document. Clear extension point. Seems like reasonable set of rules to go forward with. Could also have the directory method as discussed if no objections.

MJK: what about model versions? Seems like we have some experience with that. Deprecating old model eventually but can't force people to change. Will do at their pace. Any generic guidance here? If we were to version models, would that cause necessary overhead?

AK: revision information useful. Also indication what model has deprecated some model. In OMA ongoing debate what is the best way to do versioning.

MJK: also lifecycle of the model. We could put qualities that enable lifecycle management of the models.

CB: really important we spend some time thinking of model metadata. Thing being modeled doesn't care which version it was modeled with.
...
CB: something interesting for evolution here. In IETF have this myth that you can change anything in a doc before it becomes approved. But not true. By sitting out there and being implemented, a revision of a model gets some weight. Can't get rid of that weight in reality. In the IETF, in YANG world, trying to have well defined transition from draft to published state. Not sure that is not just trying to fantasize reality. Would be nice to correct that and have nice way to handle draft versions that people implement.

MJK: we see some of that. Like JSON schema. Totally agree. Supply side solution is the right solution. We need to deal with a way that is realistic. Good to track what's happening for LwM2M good and elsewhere.

MM: in W3C recently been discussing DIDs. Would it be appropriate to use DID for versions?

MJK: if need to validate if instance claiming to have ID, always optc
...
MJK: if some coupling we need to be aware of, good to address

WB: something framework should handle. Have full chain of HW etc. Load software that is signed etc. Ends up that you have to do something correctly with your data model should be part of validation chain.

MM: versions mean that you satisfy certain things. Really stating requirements.

WB: if take deployment into account, want to know versB: if take deployment into account, want to ion of metamodel on wire. Need to be implemented correctly. Certification programs should take care of that.

MJK: would think JSON signatures would cover that. Could checksum and validate that.
...

WB: not about data modeling but whole set of doing device correctly. All features that belongs to. Way more than implementing model correctly.

MM: in other groups problem with device lying about capabilities. Not actually passed testing.

WB: that's why have logo'ing program. Extensive certification program. People should not be able to lie or they should be able to be called out. Get letter from lawyers.

MM: letter implies that there is contract and program

MJK: and haven't decided in OneDM what to do about that. Not perhaps resarch topic but if you decide to cert something if should use crypto chain.

WB: huge difference with IoT and distributed system. With XMPP was clear why no cert program; people will just use another client. Is not in same league. If XMPP client doesn't work, I will get another. Or browser. Not interop, but one of the reasons why they can get away with not having rigid cert program. But if need to rely device working together that you buy, different ballgame. That's why cert program for Zigbee, OCF, etc pretty important, even if not for a browser.

MJK: we want OneDM to be used in those orgs so need to think about the coupling. Our users will cert devices that we'll produce as input.

---

(discussion on the priorities for the next topics for key technical issues)

---

CB: should focus on interaction patterns. Event/condition/actions, but no relationship otherwise. Also definition of what action is would be interesting. For event even farther away. Maybe could make some progress for action. If have time left could talk about complex data types. But interaction pattern for most of time sounds good. Suggest we take 10 min break now and convene 10:45 pacific time.

(back)

MJK: prioritizing architecture makes sense. We have events, actions, properties that share data types. Could have action that has setter with same data type as event.
Properties generally readable and writable. But slightly different with pub/sub. But properites in general settable. Actions are how we represent commands. More complex than setting. Might take time to complete. Actions more like how to get this perform something. Events typically: something happening. Affordance you use to learn something is happening. When making definitions of these things in OneDM. Property definition. Data definition with type. Well understood.
Have reusable properties in OneDM. Data that property carries also usable. For example temperature property has temperature data type that has some qualities like unit.
Events and actions not that well defined.
Definitions of action has semantic anchor. Dim light, brighten light. But could be time or slope involved. When we define action it is really semantic anchor to what action is. Input and output parameters. Could get response back that tells you what is happening. Different ecosystems handle this differently.
We have Zigbee and UPnP devices have actions that are quite consistent. Events more variance. UPnP have events, Zigbee devices send notifications. Those all fall under what we call events. Might be generic device alarm or specific event. We just need to figure out something that is modelled.
This morning had discussion around condition pattern.
How we use events and actions related to event condition action pattern.
There are rules we used to setup behaviour and events. How events and actions seem to me very similar.

HB: brought up because try to incubate something like that in YANG push. Was uphaul. Now another effort in netmod with ECA framework and in management domain in general. The more people do it, the better it's understood. If we would adopt that model, we would not be doing this alone.

MJK: I'm not aware of formal definition but more of the pattern. Seems we have lots of interest in this group to define more events/actions/properties but something that is reusable and interoperable. Define things like context of device. Also to define behaviour. Groups and scenes. Lots of interest in the model -- Also for ECA could be something we can .... Is there well known framework we can take into account?

HB: would not call well known but is narrow. Complexity can be vast.

MJK: need to see how our definitions relate to there

CB: really a fallacy for using same terms for different things. YANG system is subset of rule systems. In rule system define behaviour of one system. This is unrelated to issue here. Here we have interaction pattern of A/E/P. Might mix those, use event as input but then create action based on that. But all ECA stuff is happening locally in one system. We may want to describe that but it's completely different. For data modeling aspect event looks just like a property. Both have one data type which defines what the thing looks like when it's interchanged. From data modeling point of view events and properties are identical. Other people think aspects of events other properties. Need to look into details to find out the actual semantics. Big difference from temperature sensor telling 32 or 24 degrees from coin checking device telling "someone put a coin", "someone put another coin". In the first OK to lose values, in the second no. What does it mean for something to happen. ECA is not going to lead anything here, except if we could feed the events we model here to feed to ECA system.
We have to look at details here. Don't let us be misled by using thoser three words, they mean different things to different people.

MJK: in our model we mainly only define input and output data. Not what it does. For the two special cases: we have setters. We call actions because trying to map other device ecosystems that have that term. State change event is another; could be change of enum or scalar value. That looks just like a property. We have other things called actions and events -- what is not setter is action. Has multiple values and long running activity. Can't model as property. Similarly for events have beyond state changes and properties. Properties that you can't lose. If miss a change, you don't end up in same state.
Maybe ECA is not helpful beyond use case. But is use case; heplful if can define what happens betweens events and actions in our system with ECA. What we need to do to reconcile actions and events. Need different classes?

CB: they have used idempotent property alot. Also have idea of unsafe. Really about, when you do it twice it may or may not mean same thing. Two dimensions. We maybe need more. Various uses os E/A/P in 2-4 dimensional system and could be more precise than we are at the moment.

MJK: one way to accomplish in OneDM: we could have additional descriptors. To describe like idempotency and safety. Also seems that model could simply model properties and have additional frameworks like protocol bindings. Have additional semantics that give them metaoperations: like actions have multiple data items. Still modeling data but have state machine semantics.
Actions and events make sense since classes of devices where these seem to align semantically. Would make sense to add things to actions and events to further describe them? As opposed to having just different kind of properties.

CB: still need distinction of something having input and output data. Property is of second kind, kind of event talking about, kinda like that as well. Property always examined from other side. Event triggered by the side that has this. May need to keep terms because people like them but we should nail down to one interaction pattern.

MJK: thinking of boundary between systems. We have properties that are examined from other side. Actions are things that go from right hand side to left. To device from the controller. Events go from device to controller. The only thing we say about now. Properties you examine, actions you send. Events usually transmistted async. Could be batched. If we only say they are things from device to controller, and further characterice idempotency and safety. Maybe need to have something on event on serialisable, monotonic, etc.

CB: in actions we have confirmable actions that give something back and non-con. Which could be event. The non-con brings to table that it has implicit connection with the invocation and return value. Would need to model explicitly with non-con and event. Need to write this up and look at all the cases, including CRUDN, and see how they fit here. Then will have 3 bits that you can either set or not set. Then could see which are A/E/P.

MJK: also notion of input and output data. Need to think of examples. CRUDN without actions and events a win here? Still need to say how you send multiple things. System for RESTful interactions from beginning may not have these.

CB: notifications don't work well with REST. But actions exist with POST pattern.

WB: looking how UPnP works, action pattern with SOAP. With eventing need server side for events. Call Generic Event Notification (something). Working already for many yars. CRUD can't do actions is not true. Need to build something on top to make easier like what SOAP did. Could use Observe with CoAP to get updates.

MJK: which doesn't require server since long response

WB: CoAP works because both sides have always client and server

MJK: if want just notifications don't need server. Client responds.

WB: soliciting that server sent something back to you. Need to have open connection or have server make that connections. If open web socket, plenty of implementations use that.

MJK: modelin of qualities of data should not be bound transport. You can send as POST and call action. Can have different qualities for data. ...
The more we can abstract how we define things in model, better for mapping to ecosystems.
Events are things you receive that you get async. Actions are not safe, might be setter and idempotent and look like property. Could still model as action. Could be practical direction to reconcile.

AK: for definition of actions; often heard you would get handle that you can use to inspect what is going on with action

(MCR +5'd in chat)

...

WB: could also model that time aspect is being handled correctly by model. Action returns and you get information where you can access time aspects. Duration, progress, etc. Just normal pattern. Nothing to do with action pattern. Just pattern on top of action pattern.

MJK: sequence clock. Kinda idea we define action in the model semantically but also input/output datamanti with qualities.

WB: that's why think action should be something similar to SOAP call. Define input and output parameters. Argument list with return clause.

MJK: that's what we do with actions today. What you build on top is modeling. ... should not affect language, just the model.

WB: if go back to UPnP we had state variables like ODM properties. Then had SOAP actions, same things as ODM actions, then had events that you had to subscribe. Architecturally define what kind of data it is and when would be triggered by something else. The concept we do in SDF, which works pretty well. Could map all UPnP to SDF with not much problem. UPnP arhcitecture fills in a few blanks. Want to do that with SDF but how you do the mapping is up to you. UPnP doesn' talk about SOAP but state exchange and events. Then another doc how these go on wire. Similar to what we do with SDF.

MJK:

...

MJK: to summarize, we recognize we mostly describe data. We want to descibe individual qualities how these work. Even if actions don't work same way. Want to use Actions and Events as semantic anchors. Takeway: we want E and A in context of qualities how data is exchanged without mapping to specific protocols.

WB: most things belong to architecture. Should not be in model. That's just data. How transferred depends on how you want to use that.

MJK: if I have action, do I expect return? Decided that needs to be part of model? Maybe sometimes up to impl?

WB: if don't model return values it's a fire. Still should be confirmed. If also have defined event, if something changes in systems that event will be sent, you have fire and forget and return value by event. Can model with -- eventing. Can also have action that immediately returns with data.

MJK: want to describe data interaction and abstract from network model

AK: good material to continue discussion in OneDM; need to take last segment next before out of time

## OneDM SDF and IETF standardization (CB)

In previous OneDM meetings was sentiment IETF might be good place to complete the SDF spec. IETF has well defined way to engage with community, good process for thorough review, and good reputation for docs from IETF. Good reasons for choosing IETF as the org.
On other side: IETF is not leading org for defining modeling languages. Modeling langauges defined typically by ISO with programming languages, and like UML. For document languages W3C well known org. OTOH, IETF has its own spec for modeling text based protocols, ABNF. Recently done CDDL for modeling JSON and CBOR data. But not like all the community is there yet.
Also need to be aware that starting work at IETF is arduous process. Also risky: may not get what is logical from your point of view. Usually works but can turn out to be detour that doesn't lead to result. Thorough process also takes time. For rubber-stamping could just go to OASIS.

Next steps to answer: what we exactly want to standardize? SDF the language; several aspects. Structure (syntax), semantics, processing model. How models in SDF are used. Need to keep in mind we need to define the processing model at least to level of meaningful semantics. Also data validation aspect. Currently done by json-schema.org way. One way is to convince IETF that jsonschema should be standardized. Not happening yet. We could be on that side of argument. Or we could look what else is at IETF that could solve this problem.
People at IETF haven't thought a lot of SDF like languages so might get push for that part.

Next steps would be to decide struture. Probably right answer is WG in ART area. WG would work on Internet drafts and ship them to IESG. Helps to have implementation efforts out there. In best case open source. So that people can talk about successes and efforts.

To get WG, would run a BoF. To do that would need to create a charter and milestones. In order to survive, would need to demonstrate interest that people would use this. And also need to demonstrate that there is a chance for consensus. We're probably good for that. Also would need to find WG chairs; Area Directors might be doing that part. Probably good idea to have people in mind who could run the process in reasonable detached way. So better not be authors.

For timing, good now since we have stable set of people to talk to for a year (new IESG now). But IETF now in COVID-19 state where the way we normally work is disrupted. Not succesful to go to ADs next week, but maybe after a month could have these discussion and prepare a bit of consensus for a BoF for next IETF. That's in July, but people who understand COVID-19 say there's no way to have f2f then. But by then there should be good way to run things on line.

MJK: maybe we can be the 1st virtual BoF

HB: DRIP was first. Takes long time in IETF, but creating charter brings very good focus. Review process of chartering is also a good enabler. Just trying focuses the work very well. Have chartered just one thing but was very good experience.

MJK: we're well positioned for consensus. Have achieved quite a bit already. Have good working process. Have lots of stuff to deal with and have implementations. Either of those should not delay us. Timeframe sounds about right.

(MCR, from chat: would email an AD and ask for IAB BoF mentor)

CB: different people have different experience

MJK: 1st engagement would be BoF. For us to do homework would be to create charter and start working on what I-D would look like. Could work on processing model. Things could start come together by Madrid meeting.

CB: we need to talk to people. We have new ART AD coming in next week. One of the 1st things doing. Getting informal meeting with ART ADs on this. Gauge their concerns. What Michael said, also good to have -00 ID. Doesn't need to have all answers but can identify what is needed. Could use next month to get that draft out there.

## Wrap-up and close

CB: when shall we do this again?

MJK: IRTF, data model, next steps. Before not too long. Even during next month. IETF virtual meetings happening.

CB: Slots until April 28th. We could do RG meeting independent of IETF side. Could be April or early May.

MJK: early may is OneDM virtual. Something before that.

EK: work is closely related to WoT TD that has very similar model to SDF. What are conrete differences?

CB: one of the questions we'll be bombarded at IETF. And we need answers to this.

MJK: how OneDM definitions get used in TD and how work together. Some concrete examples.

EK: model itself can't be used

MJK: provides terms to be used in TD

MM: we should coordinate activities. One thing about JSON schema: we want to use the same set. We should make sure we're complementary. Currently talking about TD templates and pointing to things. We should set formal liaison. Think would be nice if we don't use different terms. If we can agree on common terms.

EK: in TD can double annotate by using the model. Can annotate TD with TD. What is added if I annotate with OneDM model?

MJK: get application specific class types. Get light switch, on/off control, etc. With its defined data types. Exactly like iotschema. Application layer types. On/off state for binary switch for example.

EK: goes further than A/E/P model, agree. But then goes further than OneDM's A/E/P modelling? More specific classes like iotschema?

CB: running out of time but need to have this discussion. MCR proposal to do same thing on April 24th.

EK: happy to participate. Could have clear session on this.

MJK: absolutely

CB: relationship with W3C WoT TD and the TD template. Could discuss that and if can find someone who can tell about templates would be great.

SK: have to check if Easter break but should be possible to join in April. Let know of time.

CB: will have also other things on agenda and will take on mailing list. Made progress today. Need to write things up and have something to discuss.

AK: (wrapping up) good discussions and we have way forward; next meeting April 24th