Internet Engineering Task Force Interim Meetings, 16 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: T2TRG WG Interim Meeting, 2020-07-16

Description

T2TRG WG Interim Meeting, 2020-07-16

A

Okay, I think we have reached the.

A

5-Minute comtempo time, so this is the thing to thing research group I'm cast woman. A recurring on is the chair. Who actually does the work and just again my name is Justin under group.

A

This is an IPR meeting, so the IPR guidelines of the IRT F apply, and there are some more detailed note well slides that I assume you have seen. So we have IPR dystocia rules that apply. If you are talking about something ology and know that there are some patent claims to it, then you have to tell- or you can choose just not not to talk about the technology.

A

We try to be nice and try to be professional and yeah. Maybe that bears repeating that this is an eye out here meeting. So we are not forging tenets here. We are trying to talk about research that may be useful for forging standards of other purposes, and we are also not an organization that that has raisins in any formal sense. But of course doing research means that you talk to a lot of people.

A

So do we have that the blue sheet is in the Korean tea notes, which maybe you can send around to the chat once more for people came late.

A

A

Do we have no takers.

A

So I think Aria is going to take some notes in the car DMV. Does anybody else want to help.

B

So, honey it's free to participate in they're, not taking this Kody limpy's open for any anyone to update so feel free to jump in whenever you feel like it.

A

Yes and don't just feel free but actually do this is an ITF car, D and E. So if you want to log in, you can do this using data tracker, but I think the document is free fall to edit right I'm, not seeing that at the moment.

B

Yet it's really up creating a buffer. Thank you.

A

So we actually have a jabber room, I, don't know if anybody is India right now we have a mailing list and we have a repository which contains the slides and will contain any other documents that we want to make available in content. In the context of this media and of course it contains the agenda. The agenda is, of course, also in the usual place in the data tracker, so our agenda is pretty full and I have already used the first 10 minutes, so I have to really hurry up here, because we are already running late.

A

We have a couple of talks, one is at the beginning, and one is at the end for various reasons, and the middle of this sandwich is going to be an segment about industry updates and I lead into that in a couple of minutes, yeah, so we're interested in doing research that is needed to make true Internet of Things the reality, and we do this cross stack.

A

So we're not exactly starting at the antenna, the antenna we are starting, approximately, where the IGF starts at the IP adaptational AR, and we end with users and security and architecture and data. And so if you want to visualize that the research group does some things, the ITF just some things and we do have overlap occasionally and I think we have been reasonably successful in managing that overlap.

A

So let me quickly mention how things are going to go on after this meeting.

A

The most regular thing that currently happens in the research group are the wiki calls which are happening approximately literally, maybe with a pause and in August and the next one is going to be on the 30th during the IDF, unfortunately, that that was something we couldn't avoid, but after the last session of the IETF.

A

So unless you are in China and it's already past midnight I do you might be able to join so we plan to I also have other meetings with other organizations, some some more public based meetings.

A

Maybe we probably will have another sampling meeting edge or around ITF 109 and and we will learn in August, whether that's a physical meeting or another online meeting and yeah the whole idea of co-locating with academic conferences really as taking a break right now, but of course, at some point we will be able to do that again, and maybe we also we'll find an online form of co-locating that we have still have to invent.

A

Okay, we have two documents that our research group documents are. You are trying to be jum one we're not going to talk about rest for design. Today we will talk about IOT edge at the end of the meeting. This is in research group. Adoption call. So if you have an opinion on this, please send a message to the mailings and also we are ramping up something called wishy notes and and right now this probably will start with some terminology, but much grow to include other things.

A

Okay, re. Do you want to report about Russia.

B

Sure, thanks Carsten, so as many of you not only we see is this long-running activity. In the tinkling research group, we've been focusing on semantics and hypermedia interoperability and since the last summer meeting we have had enough for online meetings with a variety of topics. For example, there is no new survey of semantics technology landscape that is driven by new language and michael coaster.

B

This work has two main parts: it first of all proposed a unified criteria for visibility, data standards, but also provides a metamodel survey of 14 different stos, comparing both organizational and technical aspects of those models.

B

Also, we have had Jonathan beri to lead the discussion on interworking of open API, async, API, API description methods and the IETF core technologies, and there we have been discussing a proposal way to extend the open it aspects to support core features. We said I have been for a year already, collaborating closely with one data model. Iesson group and we've been exploring various research and standardization topics relevant for that work, and one day I must also be in topic of multiple hackathons and we explored various architecture or cement interval topics.

B

In that scope, but most recently we have been focusing on its potential standardization of the SDF language and naturally have discussed the upcoming asdf of quite a bit that Carsten will be discussing more a bit later. We also conclude our close cooperation with the deputy receiver of things in particle, have explored the topic of how one DM, SDF and robotics team description and description templates can work together on what I think topics we have been discussing, enabling efficient discovery, and this discovery also relates to the close.

B

The last topic of this identifies reference pattern pointers how we can express the all of these inefficient, versatile base to enable discovery and other uses, and also one proposal coming out of this work has been this potential for chased by Standardization. It's going to be discussed at the idea of 108 dispatch meeting. Oh.

B

B

Then slot we have a quick update on that Helsinki meeting, so I need to have a face-to-face meeting in Helsinki, together with that would receive of things but due to Corona. This was also transforms in half day online waiting, but we still have been calling it in the Helsinki meeting. So in this meeting we did discuss the web of things. Use case connection, therefore it just an effort with about 20 hi t use case in the Python already and what are things folks? They welcome everyone to contribute this work and also use this information.

B

Also, it's just like talk on discovery. Those are topics that we have lots of common interests to talk of things. So, first of all in smart, you can read content activities and we continue also in these mini discussions, but one day, MST F and our of the instant description could integrate and in their work together. Linda's most brief discuss the use and design alternatives of hybrid media controls in descriptions.

C

Re there there are minutes taking from the workshop. Can we maybe put a link to those minutes into these minutes, so you can easily find them.

D

C

To the archive to presentations and so forth, that's.

B

C

I should say somebody's are definitely ongoing. We have a very active, especially right now about hypermedia controls, for example, that if you're interested in that topic, it relates also dynamic TVs versus static CDs.

A

Okay, so we will hear some more about what.

B

C

A

Okay, so the next after the the introduction and the reports, the next talk will be some work on bringing where are things TS and and OPC UA together. But here's do you want to said good luck, yeah.

E

Sure, thanks Kirsten, so yeah. This is a follow up of work that I presented in Singapore when the world was normal and it's in this category of semantics, driven connectivity and we now filled out some details and basically wrote it up together in a paper, that's going to appear in the IOT conference in September this year and it's about you're, bringing deterministic industrial networking to the w3c, bow of things using TSN and OPC UA.

E

It's light, please so for the background I industrial I out, he usually requires something like deterministic networking or some special properties. That pen can be controlled through the whole stack, and the main part here is that the applications get some QoS guarantees from the whole protocol stack and that mainly led to this plethora of few passes that you can in industrial environments. Note were feed here.

E

It's like 94%, wired Wireless has a small part here. Luckily, it's going from just wires to something that is even it based, but it's still different and not really compatible. Some good thing at horizon is time-sensitive networking, which is being standardized for now, quite some time in the I Triple E, and so it's based on standard Ethernet. It reuses the villain headers to encode some more information, and this way enables basically a converged network that can also give these tight quality of service guarantees to applications can coexist with normal IT traffic.

E

One thing to consider here is it's not just plugging in your cable. It requires very detailed network configuration as well looks like this, and for this there are different models, so you can do this centralized distributed or in some kind of hybrid way. For now, the centralized model is kind of the predominant way, usually because historically, these deployments in industry applications are planned and then actually also monitored and so on from a central place. On the left hand side you can see how this works.

E

So there are entities involved at our cords like centralized user configuration that the something can talk to the applications and understands the application protocols. That then needs some uniform interface to the so called centralized network configuration. That is, then something that I can talk to all the bridges so managed switches and so on in the network, and, basically, that's the resource allocation, so that this guarantee is that were requested by the users can be met, and so in this world one mainly uses yang.

E

That's something that many of you might know from this connectivity and the alq. Even work often reported also here in the t2 TRG in principle, there would be multiple choices like the historic net conf res Kampf, which is HDTV based and would fit nicely in the web world. Also core conf. The thing is that most network equipment out there is still using net conf. So restaurant is something that at least I mainly see in Sdn controllers that work with a lot of virtual machines and virtual switches.

E

But if you go to the physical world, you have to deal with net conf and according young modules. So this is one one thing we have to and then next slide. Please.

E

Then the other part to address is how it looks at the application layer. So industry, as usually, is quite shielded. One interesting technology here is OPC UA, which is luckily a cross vendor application. So it's supported by a large number of players in the industrial space. Overall, it has an interesting graph based information model. So that's one of the main contributions here to agree on semantics as well, and it defines its own communication protocols under this.

E

However, it's a mainly used a special binary format that can be used either as a client, server and now slowly coming up in products. It's a pub sub version of this that can have different bindings for cloud connectivity, for instance MQTT AMQP, but to use it locally. It also works over UDP or directly over layer to Saudi the most OPC UA applications. At the moment they take care of management and monitoring of such applications.

E

However, on the right hand, side what is currently ongoing work is the so called field level, communications for OPC UA, which then extends this ecosystem to actually be able to also cover the controllers and end devices in the field and to enable real-time applications. It integrates this time-sensitive networking that I just mentioned and tries to provide the full stack for this next slide. Please.

E

So, to give you an rough idea on the left-hand side, you see a screenshot from one of the tools it uses this graph based model that I mentioned in this tool. You can actually also browse through the data that is available on controllers, for instance, and it then has so-called nodes that are quite similar to resources, which is a good starting point if want to include is in the birthings environment.

E

So you can see in the on the left-hand side and the value is this NS equals two, which is an in space, so actually they use your eyes, but they convert it to integers and then follows a note identifier in this case a string this hello world, and if this you can identify a note or a resource and a different is that they are strict note classes.

E

So, unlike resources, which could be anything, there are only a certain classes of resources possible with OPC UA, and there are some more things that make it a bit less compatible with the web. For instance, the references in OPC way bi-directional their support for for bitmap data types. They define word sizes, so you have to know if it's a 16-bit integer or a 32-bit, integer unsigned, and so on, so things that were actually already solved on the web, but still used in this kind of partially low-level allocations.

E

Good next slide, please.

E

The last ingredient is type of things. I. Don't think, I have to tell this group anything more about this, so it's using this overall ecosystem that mainly focuses it integrating different application domains so, for instance, industrial automation with the building, automation or energy management, and this is why we want to bring the time-sensitive networking and OPC UA. Also in this scope.

E

Next slide, please good! So what do we really want to achieve? I just summarized, and how should it look like next slide? Please.

E

So, on the left hand side you see what we call it Serbians, which is like the idea of things, a stack that is able to run applications that are written against the scripting API and what runtime then handles these abstractions and is able to communicate the so-called protocol bindings here, colored in green and here, basically, what we did is we provided two bindings, one for OPC UA for the operational part and net con for the network. Configuration and the overall flow works like this.

E

So, on the right-hand side, I think I can't use my mouse or anything. You see the devices, they would all get a finger scription, but we also provide the quality of service vocabulary, so those can be annotated with the capabilities what these devices can provide, so how fast they could send data, how quickly they could receive data and some other properties, and this then has to be combined with the qsr requirements on the left hand side of, for instance, the controller application.

E

So only this application actually knows what cycle times so meaning how often does a control loop have to be triggered? How often sensor data has to arrived. This is defined by the application and it must match that to the capabilities of these things, and if this it can then basically request network configuration that would suit this controller application. That has to talk to certain devices.

E

The concept here is that the controller app can talk through web of things interfaces so basically, by consuming a virtual thing here, the TSN scheduler app, which can also run on on a servant that scheduler apt and basically calculates from the requirements so which communication is required. Network configuration then pushes this out through the network binding so basically talks to to these switches.

E

Sometimes it's actually also NT vices that support this protocol and are configured this way, and if this is successful, it will respond positively to the controller app, which then can start operation through OPC UA good and in the next slides I will present the building blocks that we provided. So one I mentioned this vocabulary for quality of service. This is a summary table. I think it goes a bit into much detail if I now explain all these vocabularies.

E

This is something that I would love to followup with some experts on one hand, side in the semantic modeling area, on the other hand, and also with people who do quality of service for other projects or technologies. So not only T is n, but there could be other mechanisms and if these actually apply also to these other technologies.

E

Good next slide, please. The other concept is basically that you also have to annotate things with capability terms, so for, as I already mentioned, like min cycle, how fast can it process data? How what is the minimum cycle? Sorry, the maximum cycle, to receive that another aspect is, for instance, a working clock if devices can actually synchronize to a clock, there's this precision time protocol, for instance, or some profiles, and we also need to learn within the forms, how big are actually D messages in bytes, so that we can calculate schedules and next slide please.

E

This is kind of a summary where this vocabulary applies so starting from the left, you have to describe the application requirements, so this is actually some internal data that is included in the application code. So for traffic less it knows kind of how what is the priority? Is it like isochronous real time? Is it only soft periodic or is it best effort? It knows cycle times, meaning, for instance, with what see the control loop has to be run and then some other more details like if it's a isochronous or deadline traffic class.

E

When is this deadline within the application cycle and also what kind of loss is allowed and it also when it knows which device is to communicate with it, has to basically assign some unique names that can then be used by the scheduler app. So in the second row, that is basically vocabulary that it is used to annotate a scheduled action, and this is then basically annotating the input data schema of this action. So this is based on on the scheduler that we have what information it needs and basically filled out by the other three.

E

So the controller knows some of these parts. The thing knows some parts as I mentioned the capabilities and, lastly, the form also has to provide some more details like the the bite sizes that I mentioned, but we also need the information like listen and talker, which is then MAC address. Actually that is required to do so. It can be a unicast interface address or multicast MAC address, but it also required for this layer 2 technology to provide the scheduled good. Just a quick check. Audio is still working. Sometimes I.

E

Add this that I'm talking nobody's there.

E

Ok, ok! Well, it says 8 here, but the next slide is it again. So this is about the mappings that we did so for OPC UA I mentioned already it's quite straightforward. With these nodes mapping to resources, so we could easily fit in into the property actions and events next key, please, for the data schema from here issue was mainly the binary data types, so the json schema is not sufficient to describe to the binding or actually the content service, how to encode and how to parse this information.

E

So we had to add an additional annotation here for the form uri that you need. I mean it's a protocol, so it has to be identified with your ice cream.

E

Here we propose to reuse the existing OPC dot tcp scheme, which unfortunately, is not registered with IANA but already used in deployments and but combine it with some information at the later part that gives the node IDs and so on, to have a final addressing of which node you want to talk to, and we stuck to the notation with the semicolon that is already used in all the OPC UA tooling.

E

Instead of converting this to something HTTP located because it's yeah its own scheme, so it can define the mechanism behind it and we start with what is already familiar to these OPC people. Content type. You need some there's nothing registered so at the moment, we're basically working with an experimental one, but it would basically describe this. You a binary, encoding and ya. Can then all the right content service to to parse this to the Jason used by what applications next slide, please for the net conf finding to make it quick.

E

Luckily, there is reskins, which already defines a lot of things and eased basically to have net conf be compatible with the restful approach we find in the lot of things two takeaways, maybe so one for the data schema.

E

You encounter the issue with XML based features, so if you have these XML node attributes and that are not supported by Jason, we somehow or need a mechanism to express them in the JSON schema based data schema, and we did this through additional annotations that you basically use a complex structure, and you say some of these fields are attributes for this object, and so the containing note, and not child nodes or members in Jason terms and for your I.

E

We could almost take it directly and, however, there are still some more features in in net conf, like the data stores, or we have a proposal to include this in the your ice cream semantics that basically, the first half segment is the data store that is selected for for the write or read what you want to perform content type straightforward. We can use this XML type from read. Confident was nice next slide? Please these are some examples. They need detailed, so and I don't have the time.

E

So please have a look offline to this and on the next slide or slides I want to conclude. I don't have nice pictures because our lap was in lockdown. However, on the next slide, I have a nice video that, hopefully works frame rate is not well, but here you see our test bed that we built, so it uses real equipment like this back of XDS transport system and Universal robots robot, and it's basically, these levels that you see in the center top.

E

You see a small bolt that is controlled, that basically only flips the blue bonds, and then we can tell the robot to flip back up the blue ones, and this is running through this TSN network and it's controlled with the Supervisory logic based on nodejs and the node. What projects and overall users is finger, scriptures and so on, for the configuration good last slide.

C

Sorry, quick question: there's AI components of this 30 computer services or a are components of a vacation.

E

There is no UI for for the Supervisory logic. There are some other things that are included, but not yeah. They are separate technology for different purposes like a digital tween, or something like this. Okay.

C

Okay, so looking at edge computing and AI offload in weather things, and some of that may be applicable, mm-hmm.

E

Exactly so, this supervisory logic is basically running on an edge node. So so, underneath the idea is Rex and he has a server in there. It is connected to the Tizen network and for that ya can communicate and with the devices we have open sourced the code for this and the first version or like the early prototype is already merged, and there are some polishing work that we did. While writing the paper, and this update is still pending, but hopefully yeah contributed soon.

E

I guess the biggest caveat is that this TN scheduler app is not included. That's because it's an internal proprietary work. However, it is, interestingly, an open-source scheduler, which could be a good starting point for some future work to to make this kind of scenario, yeah more accessible for the research community and about community and yeah for detailed stay tuned for the paper should be published in September.

E

Thank you. Okay,.

A

Thank you much. Yes, I think we actually do have time for a question, so any anybody else where's the question about this.

C

So I guess: what's the roadmap for Standardization here, do you you have expectation of proposing supplying than ITF or WC or Watts so.

E

There is this open, gisha, github issue, where you ask what protocols, what protocol bindings to go neck in actually planning to put a preprint on this this archive website and and submit it there and then through for this activity, continue there. Okay, currently I'm not pushing this to what I, Triple E or these these folks, because they're more conservative and currently are fully yeah busy with their own extensions.

C

Yes, okay, so we'll see I guess what protocol bindings is the next step exactly.

E

So especially I think there was some more interest in OPC ua, one limitation that I mentioned or sorry it's only on the slides and we started out with the client-server architecture at the moment, because the note OPC UA implementation that we use doesn't support pops up yet I'm working with the C implementation of this. So we have to see if we can get the pops up working somehow in a bot, stack, I. Think.

C

Another orthogonal issue here is the data modeling problems that you ran into. It seems like you know, we should revisit and push harder on, JSON schema and its improvements or to his issues officially in official way, yeah.

E

If you have them like maintenance threat or something for for the data schema, if you could point me to this, then I could at least like these issues with the XML, binding I, think a very generic and and would be good to solve. Yeah.

C

It's been actually last forever and we need to pull in Henry Andrews and have a conversation.

A

Okay, thank you, but yes, that was very interesting mmm-hmm, that that was our first research segment and now I would like to start the industry updates segment and, of course the question is this is a research group, so why do we have industry updates? And the observation of course is that in the air tea space you can invent a lot of things, but if it doesn't make make it into industry, products and and industry standards, it's going to be less useful.

A

So there are lots of SEO is out there that do interesting things, but their communication often is oriented at decision makers and and cannot be understood by engineers, so hidden behind the press releases. There may be some interesting technical innovations and and we're trying to uncover them and, in particular, uncover the research questions that really came up here and I. Think we just did this in Matias presentation, because what he did again has an impact on how we work with data models.

A

So that's a typical thing that that's happening, so we we are planning to have short segments about industry updates in in all future summary meetings. This time it's kind of trying to cover the whole space, which is why we we have so many of those maybe next time it will be more more focused on some specific items.

A

So this is my intro to this, and the first industry update. We seem to have a shortage of Michael's. Today, only have two: we usually have three, so Michael Richardson was supposed to present this. So maybe we can just go to the next Michael, but because they can, you do the sure.

F

I'm here with this yeah I'm ready so yeah advance five. Please.

F

So really I have updates on a couple of activities. The one that maybe not be so familiar with the details would be project chip connected home over IP in the ZigBee Alliance, and just to summarize that don't really have a lot of detail. But I can take a few questions. Basically, the players in smart home, the commercial players in smart home all got together and kind of took over the ZigBee Alliance. If you will to create this project chip specification and the idea is to bring IP protocol networks to smart homes.

F

So it's focused on delivering smart home connectivity over Wi-Fi thread and an IT over ble systems, and a lot of these devices have VOE I. Don't add that as a the transport. So basically, though, this is basically a the push took for common IP connectivity on smart homes, but I guess the.

F

It probably should have thought about a little more technical detail, but it's not really. There isn't really a good architecture. Spec, that's been really being done with a sort of a code. First design document based approach, so there's an open source design, there's a basically an open source repo that you can go to and look at and see everything that's been contributed by the different companies.

F

Local code has been contributed by Silicon Labs, since the sense that the data model part the part that we're interested in it's basically going to follow the Digby data model, so essentially, there's a couple of ways that ZigBee is opening up their data model. One is through this chip project and the open sourcing of this. The embedded stack that processes the data model elements in the meta model and the the data models themselves. The cluster library isn't called the ZigBee cluster library is now published as open source using the bsd 3 clause license.

F

So all of them, as it's an XML format right now, so that there that were basically as you'll hear later, the ways of translating that that we're working on so project chip is being contributed to by all of these companies and many many companies actually many vendors side too. Many to even list they're about two hundred companies signed up twenty or thirty really strong contributors. They have a simple demo that that just became operational, which is basically a little hello world.

F

A little echo I think you can turn a light on and off, basically or a simulated light on a light switch. So it's sort of a proximal network demo with switch connecting to a light. I didn't really get into it. That I said interoperability of our IP networks. It sort of focuses on being able to have a smart home with proximal networking devices directly interacting with maybe hubs where applications more complex applications run, but also the Internet at large.

F

It isn't really restricted to just the smart home, but what it really is- and I didn't really make a big point of this, but the last bullet it's about certifying devices. So it's not it's not really about network standards. The way we think about them and IETF is about being able to run a bunch of certification tests and qualify a device for for conformance and for interoperability.

F

So, in addition to the historical music being a Nishant mission of device, conformance and more of a business focused this this project chip is definitely more customer, focused and focused on delivering interoperable devices, so that the whole stack is it's a whole stack approach, but using you know, pieces from wherever we can get them. We're currently debating incorporation of seaboard as the as the wire format for data that those two POVs and so we're doing a little bit of a trade-off around that question right now, for example, right, so any questions comments.

F

Okay, either it's nothing interesting or I did a good job of summarizing. Let's do on to the front when data model next slide, please right. So one data model also came out of ZigBee. Strangely enough in the fall of 2018 ZigBee brought together a bunch of other sto, so like oh CF and ona and books from bluetooth and one went into M as well. I think we need to re-engage if went m to M, because the hawawa connection is sort of pulled them away from a lot of the work we're doing.

F

But now we get back in business with them, so I want him to M and some of these other associations they got together and sort of listed their top issues and really lack of a common data model was really something that everyone said was holding things back.

F

So one data model was sort of started out and just lays on through all these O's Tio's and vendors, and some invited experts to to look at this problem and originally I think it was thought that ZigBee maybe had a data model and ocf had a data model, meaning that there were already a bunch of definitions for things like thermostats and lights and switches and door locks, and that that maybe people could just adopt one of those. But that didn't happen.

F

There wasn't any any one of these models that really anyone else wanted to adopt they're all very, very close held to their organizations, and some of them are more general than others, but they didn't really have a use case coverage.

F

So what what the group decided to do was go off and create a common language and a common metamodel first that can express all of the these other IOT data models as a way of basically ultimately driving convergence from diverse models, so, rather than just down selecting on one model but already existed, and building on that it became an effort of converging across cross industry really, even including some of these energy and my crooked verticals, like sun's back that currently has a Modbus model, a mod such a Modbus register definitions for solar, inverters and stuff that they want to use 1d model as well.

F

So we have a language and basically it's based on declining common classes of affordance that allow you to build semantic type definitions on top of that and it's aligned with the web of Things model. In this respect the thing description model: it's a line book for work, we're doing in IOT, schema and there's also earlier Karsten mentioned this sort of cross for 14 different standards and how they all model things and and there's a sort of a common alignment that we're taking advantage there.

F

In one data model that had used these common classes of affordances, so we're not really modeling internal behaviors and and all of that, we're really starting to focus on these common classes of affordances. How do you turn the light on and off? And how do you do it and how do you find out what the temperature is and what are all the semantic types of data? So it's about interoperability, but it at the at a more abstract level. Next slide, please yeah!

F

So where we are with that is, we are phase, one which is nominally complete of the language will, of course, always evolve, but we have a language that we think is stable enough to to be able to create a bunch of models, and we didn't be done that we have about 200 model definitions, mostly from Lemmy and ocf, but also a few examples from ZigBee and Bluetooth mesh and more examples coming along the way for things like field buses and the Sun spec stuff and of ecua, hopefully, and things like that.

F

One of the things we did accomplish and I said that originally these folks all got together under my Azon agreement because they are used to working in a patent cool type arrangement where they kind of share an intellectual property. But what we realize is we didn't want to have these data models, carry any intellectual property with them that generally they're just data models. So we basically got all of the organizations to agree to publish their data models, at least using the SDF format.

F

The one data model, language format under the bsd three clause open source license so phase two hardening where we're looking at data model, consolidation and organizations coming and publishing their models and getting the interaction going to just sort of create some common common basis for modeling and again this is diverse, transfer layer protocols. So so we're really working at the layer above transfer layers. We need protocol bindings, but we're not that's out of scope, but we're working on consolidating just these these models.

F

So since everyone's agreed to publish under BSD three clause, we're going to open up the group to a broader participation based on an open source contribution model, as opposed to a liaison model, we'll probably keep the leis on for a core group of people to be able to maybe do some some long-term planning and governance and stuff, but because we're not going to operate under a any kind of a closed IP anymore. It's all going to be just ESB three clause, so we built public facing website and content and we're basically open for business.

F

If you will we want to, we, don't really have all of our procedures and policies in place, but we do want to get people to start come help. Help us with the next development of the language, bring more use cases, bring more models of basically where we are right now.

F

That's what I have for for 1dm questions comments.

F

No again good, thank you very much. Yeah Michael.

E

No question for the previous one: this project home over IP. Yes, my mister, like proceedings light. Is there a proper name or some somewhat.

F

Okay, so project yeah they're the proper name. That's an interesting question: we're calling a project chip, CH, IP, Connie.

G

F

Over IP, but that's just a working project name there there is going to be an actual trademark name for the protocol. That's gonna be the brand name, so chip isn't the brand name. It's just the working project, name, okay,.

G

F

A member of ZigBee and Huawei is now involved in project chip, so your colleagues may be able to share more information.

E

Okay, so, but there's no landing page yet or something like this, oh well,.

F

There's a little bit, but it's the open source repo. This is easily locate source project and if you really want to know how it's going, you can there's. The start here is pretty much the repository I.

G

F

Send you some pointers as well. Okay, thank.

E

F

A

You thank you Michael anything. We will return to a 1:00 p.m. when I talk about the SDF buff. So me we can have more questions that come up there. So project chip is suddenly interesting and we will need to track what what's going on in there. So the next thing on the agenda is oma. Spec works, I.

H

Am you get a me yes, okay, great yeah, one of just to give you guys an update on couple working groups. We have in MA the device management service, enablement group which is basically the lightweight into em stuff and then the if so, IP smart object, subject so mixed-mode.

H

So, weird about to release the version 1.2, you were just now finishing up some consistency reviews, so you should be seen a release from us here shortly this summer. Just wanted to highlight some of the updates that we have in this new release. If you're familiar with my way, Tim to M, it operates at the application layer of the stack in previous versions. It was a co-op UDP had some Laura involved in 1.1, but it was, you know, pretty much had a prescriptive stack.

H

What we're now allowing in 1.2 is becoming more transport agnostic with the messaging layer of M, TTT and HTTP.

H

There's different use cases that you know some more cloud friendly services that we found that this enabled that capability there's some optimizations in 1.2 of optimizing. You know how much data is put over the wire for bootstrapping and registration.

H

You know reducing the amount of data needed, as well as inner information reporting in an interface we've now optimized how how that operation works.

H

1 Peter, we're really excited about is our lightweight in gateway capability for those in the industry. There's a lot of brownfield devices out there that may or may not have a device. You know a consistent device management protocol, and so what the Gateway allows us to do is start to manage multiple devices in those brownfields scenarios with a common protocol at the Gateway level. Back to you to whatever your servers services side is we're also going to be publishing a new encoding format that we call lightweight, unto MC board, that's it.

H

It will be published as part of the 1.2 release. You can see how the optimizations that we are doing forward for that one next oops.

H

Okay, just some more updates here we have new notification updates attributes available work. We didn't want to work on the security later with TLS, be TLS 1.3, giving a lot of flexibility by separating this out and making it a configurable information piece and untangling the way that we handle security credentials with the server.

H

We are also getting a little more. You know as we grow, we have to like figure out how we're doing versioning. So we are getting more clear about that with our lightweight and objects. That also goes in and end without episodes doing the same thing with their personal as well as we, we published some additional functionality for how to how to do firmware. Updates next play.

H

So they shown, and what comma or kind of are the eclipse IOT groups referenced open-source implementations. So if you guys want to go check it out, it's easy way to uh to see how this works and get your hands on with what's called a mix button.

H

So this is on the episode side of Fame's. So here you can see the stack where, if so, Fitz is at the data model layer I appreciate the 1dm update that we just had. The ipsa group is working with the liaison group there and.

G

H

Contributed, albeit so, objects that we have to the 1dm playground as well. You can go to the next slide.

H

So just real quick just they understand the hip, so object structure, it's basically an object and instance, and the object is made up of resources and we have a format URI for not here that we can have extensible objects. Objects can be composite objects. You guys are familiar with this structure. Maybe I can go to the next slide. So.

H

Here's a number of objects that are made up of resources that are some examples report there. They are published and shared with one DM and we have object. Ids for these, for these objects be go to the next slide.

H

You'll see those objects are made up of reusable resources, so this is at the lower center level or individual resource level, and so really encouraging the object. Definitions to use these reusable resources- and we would you know, want to grow. This word we're possible, but leveraging a lot of the stuff that we have in one DM cinema.

H

Definitions for these resources- you know episodes point of view. Is we want to create if so, IP, smart objects that can work with our lightweight in the Emma management, but we really want to follow whatever the broader industry adoption standards are. You know, I, think this one vm effort is is really interesting to us. We don't want to be declaring a particular way to do this. We want to to find a broader consensus when I kind of our approach to this next slide.

H

So we have published some tools from the group: oh so there's some open source projects and scripts to get your hands on what it means to create and validate and if so, smart object, so whether you're working in seed, JavaScript or there's an interesting one with this. So for ble characteristics they here's just you know for your reference, a way to look at the tips of registry as well, as is the scripts to you, interacting in and publish your own objects here.

H

That's all I have any questions for us.

A

So those things on those slides can can all be followed, so we can see where it's always done and so on.

H

A

Yeah we have a little time for questions.

A

Okay, I think that the fun part will be to see how this all then comes together in the one Yin context, so I'm looking forward to that, but we already have a hundred or so, if so, models in the one diem playground. So much of the work has already been done, which is encouraging. That's.

F

Worth pointing out that there are open source tools now that automatically convert between the tips of XML and SDF and back and forth, and also the OMA models that more or less automate the conversion. Maybe you're going to talk about that in the SDF part. But I thought it'd be a good point to should point that out.

A

So I'm looking for voter, who doesn't seem to have himself free from his previous meeting. Yet what, as sharing a meeting, has been sharing a meeting in the previous hour so sometimes hard to get rid of that?

A

So I think we're going to skip this part here and go right to the w3c segment which I don't have slides for Michael. Do you want to do that? Yes,.

C

So if you look in the minutes, you'll see that basically I've linked to the face of face slides I'm just going to share my screen. If it's okay and.

C

So hopefully you can see now my slides, let's go full screen here, so I put a link to this repo into the minutes and I also link to some particular slides.

C

So I think that if interest to this group is probably the topics on security discovery and probably a life cycle particular but also I, think profiles and of course thing description are likely to be of interest. Now. We've already discussed discovery, I think at great length in previous meetings, so I don't think I want to die to a deep dive into that. I think I'd like to start by just talking about the plugfest, which has a summary deck here. So actually the meeting was two weeks long.

C

We had a one week plugfest and we had a a one week face-to-face and the virtual face of face was 15 hours of total minutes for hours in meetings, which corresponds to a two and a half day face to face. Basically, so it seemed like the time as far as total meetings now the plugfest was also rather than being a weekend. It took place over an entire week and we just synchronized.

C

You know one hour a day with time zone changes, but we also had a virtual VPN setup to share a kind of a virtual network. Now I will say that I think we didn't get well organized enough in advance of the face to face of the plugfest rather, and so we only got a VPN really functional like on Wednesday of a week, so we didn't accomplish much as I would have hoped, but I think that we'd kind of figure out how to do the VPN and if you how to do a VPN bridge.

C

So as Michael Koster mentioned before we had a set up for Raspberry Pi, where the reservoir could in act as a bridge to the VPN network, then other devices could connect over a Wi-Fi access point or over a wired network. I'd not really know what the be Pilon all they just connect to a network.

C

I never had a DHCP server in an app and so forth, but running in the cloud you could also do broadcast packets, so things like, for example, mdns, would work, so we we've got that working and I just want to kind of summarize. You know we got this here down down here below. You can see my little raspberry pi going through a secondary network interface into a Wi-Fi access point, and they could also have a second upstream interface that it talked to you know the local network, and so that's all working.

C

It's not a hundred percent, reliable and so I think we need to. You know, get improvements here. Like I said: I wanted to coordinate with IETF hackathons I think something's similar. We were useful for the idea that- and this is just a summary of the various devices that we had running so on the VPN.

C

You know we had, you know a set of people from different companies, some in Japan, some in Europe, summoned in Canada some in great places, and there was a Matt ringing, the cloud that also provided Internet access, and then there were various other services that have their own internet full Internet cases.

C

The project we had running was Fraunhofer having an implementation of a directory service and front hopper has been very active and I think and a person involved in front offer is going to be also the end of their editors list for the lot discovery standard, which is in in progress and soon as we had this prototype and we had it running, actually had both locally behind the NAT and also as a network interface, and one of the Japan looking at is kinda had a federated erector eServices, but we had you know TVs, for devices getting registered with this.

C

It was a bit of a hack, because basically, we had a script that has pulled TDS out of the gifts, github repo. We had them archived, but I think. Eventually, we need to figure out a way to discover devices or have them register against the directory service. Wasn't quite done yet, so we faked it by pulling things from the github archive and then and then the DNS sd was being used by this directory service to provide kind of introduction service to be able to find the directory in first place and.

I

C

I

C

So, to recap: I talked about for discovery, the ideas they have a two-phase process where, as first introduction mechanism that finds a directory and there's be a standardized directory service, this generates API and so DNS s. Ds is one possible way to do the introduction service it can be. You can even just give it a URL. That's the bit most basic introduction mechanism, any rate we we did the solve fee: how to populate the directory service problem.

C

We can register things against the directory, then you still have to you know figure do registrations, and so you might need a separate service that is a Discoverer that finds devices and then takes on the task of doing the registrations on the behalf of device that don't do themselves. So that's still under discussion. The other project we did was auto population of a node-red.

C

So there's another project done by Itachi and they would had a no dreaded interface and so what we did is we had a script that could pull information out of the directory and could auto generate node-red nodes. So you could have a use case where someone could just no dread. Have all the devices you know magically appear in the dashboard for node-red, then you can drag and drop to build.

C

Iot orchestrations and the idea is the directory would could keep track of the various devices and let you search for things you wanted and then you can have something to generate things. Yeah lost have some testing tools. We looked at technically. Vinci of Munich has a testing tool where they were reading things.

C

Reading TDS I mean generating basically fuzz testing of devices, so you could automatically, you know, poke at devices, make sure they're operational and maybe identify security hazards, and some there also is ongoing work around hypermedia, and so basically the problem is that you know how do we deal with things that chemically created resources in like a like a so there's, both things like ongoing actions and events subscriptions, but there are other kinds of created resources you might want to have it's.

C

The question is: do those resources go into the TD which will require the TD to constantly be changing, or we have some other mechanism to statically declare? I could say URI URI template that would indicate the format of a dynamic resource will not have each individual resource. The problem is that dynamic TVs cause all kinds of complications for directories, because then you have to like invalidate caches, and things like this. It also is potential privacy concern because you don't want other people to know about research into didn't create, and so we are currently wait.

C

What's that the photos.

A

C

If there's a question, please get it clearly and I can answer it.

C

Yeah. So I pointed oh.

C

Well, I will say in the earlier section about the one of things a beginning of this meeting. I had a link to the current main issue discussing this whole TVs versus dynamic force of static TTS, and it is a tricky issue and there's kind of this. What is the bound between data and metadata and the idea of dynamic resources is kind of one of those boundary cases. So we have to make a decision about. You know how static RTDs.

C

There are certainly cases they need to be updated, so wondering or looking at, for example, is rotating IDs to disable to to break tracking algorithms, and that require some kind of way for directories to notify quality. T's changed okay, so that's that was the plugfest and we we had some interesting work going on, and so we we did in a five bunch of issues, and we we put those into the testing repo and we we are tracking them, so particular some things of relevance here.

C

Are we found out that the implantation to JSON path we're not really consistent? In particular, the version we were using of JSON path didn't allow recursive searches which we actually needed for discovery Fleck listing TVs, so we had to use XPath because it doesn't wasn't that doesn't exist in JSON path. Is that the implementation didn't have it so a problem with not knowing you know not having a complete spec for you for the standard means it's hard to know when an implementation, you know, is completely doing things. We also have an issue with IDs.

C

Ids are optional and TDs, but they're often used as primary keys and databases, and so you have to generate a local key. You can't use the ID field in a TV, as your primary database couldn't mean I'll exist, and so that was another issue at chemo, so students I think also of relevance.

C

You knows we need to look at introduction mechanisms that don't have typed links so they're, actually our introductions that only have a URL, and so we have to know who does at that point at a directory or directly at a device figure without kind dynamically kind of without having the help of the type okay. So that was a plug this and I.

C

Think, like I, said other things of relevance. Our security is actually one point here: I want to bring up so I basically brought up some things that were critical for security, so one is we're planning to do our plane at least propose having ability to sign TVs.

C

So we want to be able to have basically a proof section based on json-ld proofs. That would allow us to maintain the integrity of TVs and actually dids can also have encrypted IDs that do like a hash of V of the content. So you can avoid having to change things.

C

This is implications for whether or not TVs can be updated, because if we hash the content of a TV and then we update it, then it changes the ID and and if we sign TVs, there's actually a mechanism for doing proof, chaining that we'd have to use there, but it's basically signing TVs is basically a you know: chain Technica, so we do want to have some way, though, of walking down the content of T DS.

C

Your big topic has been ooofff too, and we very recently posted a update, T DS, so right now the spec only has the code flow that turns out. Oh aw actually requires you, know: human interaction for granting authorizations and so forth, and so there are cases where you don't want to do that. There's also an IETF spec for a device flow which is kind of designed for IOT devices. There's also 200 flows, they've been deprecated, and so we didn't want to necessarily. We had discussion whether we include that the TT spec or not.

C

What's currently on the table is we will not include by default the deprecated flows, implicit and password. We will include core client and device and device being the kind of new one. You can still use the old deprecated flows you really have to, but you have to include an extension vocabulary to do so. So that's the current and that's not that released, but it is on the table for being included in 1.1 as a backward, compatible. Extension.

C

Let's see, I think that lifecycle, we've also discussed in the workshop, shall I won't dive into that. There was some small updates profiles were every ongoing discussion about. You know how to get interval T and basically have you discussed about what a profile should include and there's also a whole lot of work going on around use cases and we actually had been missing actually statistical.

C

We had a michael galley from oracle I've been working on sorting use cases by parity and who's working on them, and so we had a survey, and he has marketed versions of this yeah so trying to prioritize the various use cases, and it is based on the number of respondents that said it was critical or business relevant. It looks like you know: smart city, manufacturing, energy and smart building column top.

C

However I think there's also things like retail and our agriculture that are also pretty well: ok, retails, a ones that's close, the top and so anyways. This is a sort of discussion. We're having the other thing worth saying is that some of these cases are vertical like agriculture and some are horizontal, like accessibility, okay, so we're I think we need to kind of divide these up into horizontal and vertical and also there's requirements that we need to extract from those cases and there's also some things in flight.

C

There's more agricultural things coming on on online. There is some stuff on educating that is in in flight and there's some smart city related stuff and retail rate stuff what's in front and then there's these horizontal ones. Okay, so that's use cases and I think you know thing description. I have some updates as well, and you know this is mostly these slides because it go through. So right now we're basically in cleanup days trying to clean up some issues that are in you lists are confusing or under certified and get to one thing.

C

One thing: one discussion there is we do if someone has wind chimes going, we make.

A

Sure that our cowbells and.

C

I

A

At the end of the time, we're location for us look: okay, I'm done man, that's that's what I want to stop so great. So we have the the pointer to that presentation in the notes. I hope well.

C

Yes, so I have pointers to the entire repo and then I have points to some particular ones. I looked at and but yeah so just follow up and you can see what details as you wish. Okay,.

A

Thank you any quick questions before we go to the next item.

A

Okay, voter, can you present your slides? Yes, I can please do because my computer, so all right.

A

Now we see a black up.

I

It's like hey, it's faster through probably the US and then back so happy to preserve one thing that happened in ICF, so I did not use the whole all spinning in what ICF means.

I

And I was very very recently because it's only something like a week ago that we released a new version called two point, two point: zero and what is very new is that we now have an aspect called ocf cloud API for cloud services. What does that do?

I

Well, if you see a little bit to the right, the diagram, if you're talking about IOT and you're talking about things like device device communication that was already there from the beginning, then we started to talk about bridging, so basically that you have all the devices all the ecosystem, a can talk to. So we have a complete bridging architecture. Then, of course you have the use cases that you have a smart phone IP connected and you want to talk to your home, and so you want to do something.

I

We'd remote access through a cloud service, sound and cloud technology is born, and then certainly you have another issue that if you have a device connected to a specially specific cloud and you have another device that is connected to an other cloud- that you want to aggregate them from user perspective.

I

So that's where the cloud to cloud stuff comes into the basic thing and I think it's also nice integration layer that can be used going forward, but that's something for the future and basically, if you have an account in the cloud by means of an out server, so you have for years a user account there and you have another cloud and with another user ID we use standard technologies to do that matching up and then, of course, all the ocf devices device listings.

I

You need to communicate that between those clouds, so that you can synchronize the view on both sides with devices and clients you have. So that was a decent amount of work to get done and everything is there open source? Is there as well so I think this is a huge step forward for cloud integrations as well. It's really making things easier for ourselves.

I

To underpin all this work, and that's why most of this stuff is hard to do. We have a running code running on the device in our activity.

I

Probably most of the people know that already that that's places available open source, Apache 2 license so what's not to like, but the cloud stuff is well, it's it doesn't have to be targeted to a small device, a small CPU and crunching and the size to fit on own small CPUs cloud stuff is really really different. So you really want to make it scalable having that done in different technology. So that's why we have a different code base there and it's based on go and it's a well.

I

We know we call it go ICF and there's one repo that has a quite a lot of dr. contain is already completely configured and the results are an experimental.

I

Instance of the cloud and cloud cloud technology there already, so if it's already available that you can play with it, so this well, together with the spec work, spec works that we did and getting this done. That was a major work that we did in the last year.

I

The directional change that is nice to mention is that previously we something like a year ago, two years ago, we always talked about ocf as a complete and complete stack, full full stack, including data models, but we got some indications by other vendors, but also from other organizations that what we are doing as a framework is pretty nice.

I

So what we did as a directional change is that you can also use what we call now toes. You have core framework and as a complete stack, and you can just build your own app and your own, your own protocols, on top of it, and what is ifs, is then that you can use a notarized framework and that standardized framework itself is completely secure.

I

It secures all the endpoints of your application and that's hopefully, a step forward to the market and because there are quite a lot of IP projects that well don't want to use a standard, but use needs to be secure and we try to enable this kind of work of a pioneer. By having this as you've Co framework, we would like to enable there's kind of possibilities for non-standardized ecosystems or ecosystem that want to move to IP.

I

It's what you want to do with it. What make sense- and this is all across all the models that network during races that I showed in the first slide so and you can transport your model, then, on top of the framework and on the proximal network, but also through to the cloud and cloud technologies that all works thing is also a step forward for the whole industry to get more adoption for IOT.

I

The other thing that we are looking at is the security we may already have. Can I have two more minutes, so one of the things that we think is good to have and everybody's looking at what is like the legislation government's doing about security.

I

So we already identified five different documents that have security requirements and we are ranking ourselves against those requirements and well, luckily, well stop mark, of course, that we are trying to match as much of them the red ones that we think we can meet, but we did not meet them yet and of course, there are requirements in those documents that are not applicable because they are not about a standard or an ecosystem. They are about vendor kind of technologies.

I

I think this is also a step forward in recognizing that we are looking at what the legislation.

I

Organizational wise is doing that we are trying to meet the challenges that I see and the last slide. So one of the things that we are doing quite a bit is cooperating with other standards. Recently, IP bliss has been announced, that is, a cooperation between BACnet thread organization, ZigBee and KNX, and RCF to move forward in building automation that everybody wants to use IP. So that's a huge thing, because clinics and BACnet are known to have not yet to be there on IP, so they that they are saying that they want to move to.

I

Ip is a big thing and.

G

I

Is there is as well a minor thing because we are already IP based from that perspective, as a directional setting, IP bliss will do good for IOT as a whole that everything will move to IP and, of course, all the security stuff that I mentioned in a previous slide will come into play.

I

Another thing that we are working heavily on is one DM. That's a cooperation between us also started out as a liaison between multiple parties, but it's now public, and one of the things that we are trying to do is making sure that data models as a whole are being aligned across yeah.

G

I

Many as possible industries, please take a look at that as well, and that fits into that. We have something like the core framework and so that, well, whatever models comes out of this work, you can just transport it over the ology of core framework, and even if you haven't different model, that's not being accepted, then you can also transport it over the pour framework thanks for additional minutes, because that was my last slide.

I

Any questions I.

E

Would have one but here's this IP police? Is this like a continuation of thing here or how do these two relate.

I

No, it's not a continuation of fair hair. Fair hair was a separate.

I

Organism as I PR did not exist, their IP bliss is really a liaison between those organizations and it's we are saying that it's marketing, but, of course it will do technical things growing forward. It's mainly getting everybody on the network and making sure that the coexistence of those different application protocols will will exist, but it's not go exists and it is and leverage each other so that you can use OCF together with bacnet together at KNX.

I

What the best way of doing is so one thing that we did in one diem is looking at the different organizations and where they were good at and basically in IP bliss. We will do probably the same thing in what is good and what is where an organization is good in, and you use and try to push that and leverage that as much as possible. But it's it's definitely not a continuation of fair hair, but yet the principles that were written down if fair hair probably would apply.

I

A

Let's look at the schedule, we have pretty much squeezed Michael's presentation about IOT SF out of the agenda Michael, you maybe just want to say one or two sentences why my chrome is starting to share things again. So.

D

I did do a presentation at the ITA Directorate, which is recorded and they are IOT. Sf is doing a series of training courses which I'm involved in creating and those will get announced. Probably next week.

D

And they also have some work on supply chain security, but it is still very very young.

A

Thank you, a quick question for Michael. We can link to our Directorate notes in our notes. So if you want to learn more, you can look there.

A

So sorry for, for squeezing you out Michael back.

D

Straight up what our start came an hour: late, yeah, I,.

A

Think we can have a more detailed discussion of NTSF next time we meet. So thank you for that and let me quickly point to the asdf buff that is happening at the IETF, 108 and I. Think we have talked about one year and the interesting thing from an IETF point of view is that they have been a few people pointing to one DM repeatedly over time, but because one VM tried to avoid being that 15 standard and really wanted to operate as a liaison organization.

A

They haven't done the press releases and all this stuff that competing organizations usually do so they were essentially running in stealth mode for a year, and now we have a little problem because a lot of people in the ITF don't know about that. At least those people who haven't been to research group meetings where we have talked about 1 p.m. so three days ago. One DM finally decided to actually do the coming out and there is no website 1 DM dot, org.

A

That has a lot of information and I'm saying this, because one DM essentially has done three things that that of Note. One is the agreement on a legal model that Michael talked about that things done, based on the USD three claws and so on. We are not doing this old, IPR heavy way of doing things that has already killed other organizations.

A

The second thing is, we have a common specification from it, and this is really what the buff will be about, and the third thing is, we have started to collect a couple hundred contributed data models. Right now there are forest eos in the hope there will be at the stos pool. So we are trying to show that the mechanisms actually work.

A

1Dm spend a lot of time about pressure testing the specification which is really just trying to convert data models into the common forward and see whether we can express what we want now. Stf has been released as a 1.0, but it's not yet completed. It doesn't have all the features. It doesn't have all the all the Tiff's passivity that we want from a standard and so on.

A

So the question is: who actually does the work of leading SPF 1 / 1.0 forward to a standard, and that's actually something that one DM things could be done in the ITF, so the ITF would define the format, but would not really be working a lot on doing data models. I mean I, don't want to completely exclude that this ever happens that the ITF thinks it's useful, Drive data models defined in SDF, in particular when it comes to network management that that might actually happen.

A

But ITF would then be one of the the blue boxes down there. Blue green boxes ecosystem, one ecosystem that that are contributing to the area where one DM really is about harmonizing the data models. So this is the idea and the buff is happening Tuesday in 12 days, it's called asdf a semantic, efficient format. It's a non working group form forming buff, because some people thought we need to have this.

A

This dialogue about what what one VM and SDF and or the other s do in this space are about and whether we even can find a way to work together, a common process that is not stuck in some IPR issues and I think we are in a very good position right now, due to the work that one DM did. But we have to complete that and and get people talking to each other.

A

So this is the the objective of the buff and I would hope that we can get people from all kinds of organizations coming in and and explain how they are trying to work together using this symmetric definition, format and how IETF could do its part and in completing this specification.

A

Any questions about that.

A

Okay, in which case we go on to sorry.

G

Thank you, Karsten yeah, so hi I'd like to present our progress on the draft IOT edge computing challenges and functions on behalf of my co-authors. Please go to the next slide. Thank you. So I will not go over. The history of the draft is just here for reference and to show that basically we, you know this work started two years ago and it evolved quite a lot. So today we are looking at revisions four and five and five is proposed for adoption. So we addressed comments.

G

We completed sections, so we will look at this in the next slides.

G

Thank you so, in the first part of the update, so we address the comments, mostly from Tomas on the list. There were improvements to section 3, ru, t challenges leading towards you know the adoption of edge competing, for example, resilience to Tammy 10th services now include enabling a cloud service to access a device currently asleep and hiding traffic patterns from devices is another privacy application of IOT edge computing.

G

So there were also improvements to the document structure, so we removed the appendix it was moved to another draft address for reference, and we moved also a section on an overview section later in the draft just to improve the flow, and we made editorial fixes as well and also re provided some comments, and we made a revision 5 prior to the call for adoption.

G

Thank you. The other part of the update was planned since the last ITF PT. So we completed the sections 4 & 5, so we we added an example of distributed I you th computing next to the general model, and we the next one, is a bit major one. We added the research challenges associated with each function that we identified, and then we fill the security section with a positive and negative impacts of each computing, so I think together. This kind of completes the the draft set itself.

G

Many editorial changes were also made to improve clarity and flow, and in the next slide, will you know, since there is a thank you, since there is a call for adoption for this draft I just would like to give a quick overview of what is in the document so that you can see if you are interested in looking at it and waiting in in the in the mailing list.

G

So after the introduction, we have a background section covering IOT cloud computing edge computing and with a few use cases and the the core is really of the document as we sexual 3 and 4. So in section 3 we cover IOT challenges, LED, leading towards the adoption of edge computing. We have challenges that are time sensitivity, a pink cost resilience to intermittent connectivity and privacy and security. So those are based on earlier work made in in the tto TRG research group.

G

Before we started the draft I think even direct involved in this then section 4 describes IOT edge computing functions, so it starts with an overview of the current use of peyote edge computing, based on a review of current standard research and industry projects, which is now in the separate draft, and also it has a very simple general model that we use basically to introduce a list of functions or components and those are organized in the three groups: OAM functional and application. So this classification is for in orally for clarity.

G

Only different systems or system designs may couple those functions in various ways. So we here we are not prescribing one particular system design, but really trying to cover the different types of functions that you may find in IOT edge computing systems.

G

There is also short discussion on simulation in emulation environments and security considerations. So, in conclusion, the last slide. Thank you. We believe that it was believed that the draft is now complete, so in conclusion it it or it really introduces as you th computing, and it describes why we need it. So that's, of course, part and also it describes the simple architecture model, at least major of functions and associated research challenges.

G

So as a conclusion where you know, we think it provides context for future work in this area in IRT F to be used as a reference and also to provide some context and how you know. Future work basically relates to other parts right. So a good review, which was made since last IDF helped fixing some issues with the flow and reduce the size of the draft, and so now we proposed a draft for adoption and if you are interested, please review and provide some feedback on the lists. Thank you in carsten back to you thank.

A

You so are there any questions what parts of you presented so we have the adoption called running, so you can respond to the research group. Adoption call.

A

Is it funny ouch? Does anyone remember.

B

Okay, look two weeks started on Monday, so we can have to go. I have.

J

A question at this point.

J

G

J

Good, it was the last email about the call for adoption of this draft, and it was mentioned that in the end, it's also interested to hear about further reviews. So I wanted to know if there are still places for open comments in these documents or on only minor editorial changes.

G

Thank you for the question. I mean I, think that here the call is for adoption by the research group, which means it will change in the future. That is basically instead of being driven by the of the authors it becomes driven by the group and, as a personal, you know put on that. I think, for example, the research challenges that are listed, for example, that's a very good part where actually we need input from people here like, for example, we heard today some discussion.

G

There was a discussion about discovery and I think that's also related to edge computing. So there is a part of this in the research challenges so anyway, so that that's my take on it. Maybe yes, so.

K

I think save yarns trying to say is that yes, please, if you have interest in reviewing it, please review it. Yeah.

I

It's not fixed.

K

By any stretch of the imagination, you know it's like just being affiliated now officially with the working group yeah.

J

I'm still yet to go through the full version, because I recently was working on the research and edge computing myself, so I may have some points to as a feedback or as a comment, or maybe some new points to add. So what is wondering if this is the end of the draft or you know for the divisions are on the page. So okay I'll have a look and then, if there's anything, then I can maybe propose on the on the mailing list itself, or it would be a new version. I.

G

Think, please please go on the mailing list and indicate if you would like the research group to to continue this work. Basically, that's why I believe that's what the core is about, so definitely your input would be more than welcome. Thank you. Thank.

C

You you put a link to that list or something in the minute, so we can find it more easily afterwards. Afterwards,.

G

Yes, a link to to which well can.

C

You just give a name the list in the minutes explicitly as we can find it, so we can and also maybe a link to the draft. We could also find it more easily.

G

Okay, so a link to the draft, then you mean the list: a link to the call for adoption, email.

C

Yeah so there's a mailing list, our call, and so we can follow up. I will say: I'm, I'm gonna be reviewing and playing my support here and, in fact, I just wrote a for what it's competing use case and I want to align that with this.

G

Thank you yeah. Definitely, please provide feedback and input on this, and that would be very happy to to integrate and to to grow the document, because I think the course was really provided. We provided what we could but I think now, that's a time where, where we need more inputs, yeah.

C

It's also an activity going on in web in networks around edge computing right now and WC. That I think is also very relevant like and point you some stuff they're interested. Thank.

G

A

So, just to throw up a few more things that people might want to think about the questions that came up in previous discussions of this focused on on two questions that I think we we will continue discussing when this becomes a research group document and- and we can start thinking more about it now. One question was whether edge computing. Actually it's sharp technical term or is it actually just a marketing term, and there are maybe one or more concepts behind that trying to get out.

A

That would apply beyond where we are the marketing term edge computing work. So I don't want an answer right now. I just want to throw up the question, so I think that that's one of the things that we try to do in a research group really sharp in the terminology and and understand what the terminology implies and does not imply and and how it can be useful on a technical level, and the other thing was that the culture had a nice. A register opinion talked a while ago, where he came up with a number of.

A

Requirements that that really must be met for for edge computing to actually happen to be widely deployed and I think that's also something that we need. We might want to pick up and and discuss in more detail, but what? What are the success factors here and, of course the success factors are not all technical. Some of them are actually very much commercial, but I. Think it's a good idea to think about those as well.

A

So we don't have nicely structured item of work that is not being used anywhere, so these were the these would be the two things where I would like to see more more input in reviews and and in the discussion on the menu.

A

Any other comments.

A

Thank you were, in which case we are done with the agenda.

A

As I said, we are probably going to have a summary meeting before the before which I eat EF 109 again and in the meantime, there is the mailing list that was just posted to the church, and we also will have the regular wishing codes on on one of our subjects, and that doesn't mean that we cannot have regular calls on other subjects as well. It's just that we she seems to have a lot of energy, so any last words from somebody else.

A

Thank you. So we made it on time and have a nice IETF 1:08.

C