Internet Engineering Task Force 106, 21 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF106-T2TRG-20191121-1000

Description

T2TRG meeting session at IETF106
2019/11/21 1000

https://datatracker.ietf.org/meeting/106/proceedings/

A

A

B

C

A

A

Okay, welcome everyone: let's get started with the finding research group session so, as usual, since we are in an ITF meeting, the note will applies. This is the short version of the note. Well, there's also now an updated longer version essentially says same thing: IPR rules of IETF. They apply also in the IRT of sight. You are being recorded and be nice to each other and the goals of the IRT F. It's good good to remind that. Now we are on the research branch of the of the of the organization.

A

So here our idea is to conduct research instead of two standards, but of course we do a lot of collaboration with the IETF, so we are discussing a lot of things that are related to standards, but here are really our goal is about advancing knowledge and sharing the knowledge about topics relevant on IOT at the IETF, so the pink sheets, or nowadays, bullets are going around thanks for volunteering, note-takers, Nicholas and evil Oh. Anyone is also free to chime in on the note takers on the etherpad online.

A

Let's hope it works better than earlier this week. Is anyone using jabber? Okay, you can also just in case hang out at the jabber room, see if we have. If you have anyone chiming in on the chat room as usual, you will find our daily activities and more information at our mailing list and we do share all the materials. As usual at our github repository, we have had one reposted per meeting. You can find me information about this meeting, particular at the github repo tools in 1990 f-106.

A

Agenda for today we are now in the introduction part I will give a quick update on the research group status. What is upcoming meetings and activities, then we'll have reports from our other activists, including we shape a meeting.

A

We had on Friday before the IETF week, hackathon and quick one on the core application site meeting after that, Michael coaster will give us an update on the activities on IOT data model convergence in particular one day tomorrow, Michael McCool will give us an update on a double receiver of things and finally, we have reserved a quite substantial slot towards the end of the meeting for discussing about this general IOT operations, security, management of on boring life cycle, etc, a potential for a new group or activity at the IETF or looking at the IOT aspects at large.

A

This is a discussion that has been going on for for a while now our channel T, Directorate and also this meeting during the site meetings and well not in this slot, would like to share some of that discussion and engage the wider IOT IETF community. So Michael, Richardson and Elliot Lear will be driving the discussion over there.

A

Any agenda bashing questions or comments.

A

Okay, then we'll get started, that's a reminder of the tingling artsy scope, ankles, so asthma. In the beginning, this is the research arm, so we are working on the research issues, turning the IOT into reality and in particle. What we be focusing on is these low resource nodes, things or constraint, nodes as they're commonly called how they can be part of the wider Internet and wider IOT.

A

We are focusing here on things that are have relevance on the IETF standard size, and so, if you think about stack wise, we start roughly at the IP adaptational a or sometimes don't we have to connectivity aspects, but go all the way up to the application layer, including architectures api's management and, of course, security.

A

How we really relate to the groups on the IETF site? I mean there is a lot of overlap when it comes to tips so where we are look at this research issues, for example, taking two groups that we have a close collaboration, IETF site core and a looook in core we're doing a lot of the restful protocol. Data model, design that sometimes originated on from the archie side sometimes comes from elsewhere, but then sometimes get core working group. For example, we come across some issue that we realized.

A

Okay, we are actually not ready to do to the standardization on this. We should do a bit more thinking, architectural considerations, etc and sometimes then move the work, moves from the core cover or other working groups to the thing. Looking Archie side in a similar fashion with albick, which is focusing on giving guidance on implementation on the iot aspects, then we have, of course, other groups like IIT Directorate, looking at coordination across IETF, Cruise and beyond, and also including Archie.

A

We have been traditionally doing a lot of coordination work with other stos, including OMA spec works, oh-o-oh, CF and double 3c. For example,.

A

So, in addition to this meeting, which we commonly call a summary meeting, we have had other related activities. Ietf 1:06 we had on on Friday a pre meeting with ability to see well things at the at the National University up, or it's one more slide coming on that in a moment, and also there was a core application site meeting on Tuesday. Where we're discussing the problem, leaders for coop API, Sandero responses, there will be draft coming on. Both topics are likely on the core side, but was very much related.

A

Discussions also happening at the RG side.

A

So a few words on the workshop we had on Fridays. This was a joint work with Doubletree see what are things, what we were focusing from the archie interest. We have had generally six interest areas where we're looking at energy and a lot of those. Basically three were mostly in the scope of this workshop, which we also commonly have in the scope of the wishi activity, so modeling data interaction for IOT, rest-based, hypermedia for IOT, and also connectivity for IOT.

A

So there was a discussion how w3c what were things we say to stare where they're going and also how things relate to what we do at ATF site. Quite a lot of discussions on one day tomorrow. What it says is there how things relate together? However, things thing descriptions relate to one DM and how the code all comes together in a bigger architecture and then also on on connectivity.

A

How things like much, for example, can be used to give more semantics on the connective you're trying to establish or how you get, for example, use protocols like ice in a constrained environment and what are the semantics on when you in when you exchange candidate information data in that kind of environment, but there's a whole host of nodes coming on that which still need to refine them at will, once they are published, will will let you know on the mailing list, but all the materials are already available on the github repo of that meeting.

A

Going forward, we have had usually these we, she calls some couple of time between the ETF's. We are planning to go roughly monthly based on those December looks rather booked already so probable kick-start that in January, but it's gonna be notifications on their mailing list. We have had traditionally virtual meetings. Oca Ole, Miss pack works double to see whether things occasionally on the topics that we have common interests. We all like likely to continue those, and then we have had almost every IETF a a joint.

A

These summary meetings happening so likely will have one in Vancouver and in particular the hackathons. We have been very active or a seven of them, or so far so will most likely have a we. She hackathon activity go located with ETF.

A

Also. We have been very interested in on having colocation with academic conference. You haven't had too many recently, so if you are aware of or even potentially organizing a relevant academic academic conference or other activity, we'd be very interested on co-locating with you. So please do approach us chairs and let's talk about it.

A

Then, moving on to the stages of our work, while, while our research group don't necessarily produce RFC's, we have a, we have been having separation of trying to document the major outcomes of this group in you know in drafts, so we already published one RFC about a security right now we do have one research group document on restfully, so in priority.

A

I'll give a bit more details in a moment and we have a set of documents that are or upcoming or not currently a research group documents, but are something that we are considering for adoption in Portugal. That's one active per connection: IOT will have a short update in a moment, also insecure, bootstrapping for IOT, u P and then on core applications.

A

There have been discussed and probably gonna be documents either on the course I on the research group side or the insulate both on some considerations layer, three there has been discussed and we should document more aspects that are relevant there and then also on Vichy. What will be calling um we? She notes. We might be coming something up on a part of all day tomorrow and semantics area at large.

A

So few words on the rest of all designs. What is one of our long-running research group documents? We did an update for this idea. I did informational, choral and constraint. You arise those two technologies that are now being developed on the core working group side.

A

How do they fit into the larger architecture and on the rest of the IOT, and also we add a dimension of how you server push mechanism configure pick or dialing so core dialing again is a memorizing be developed at the core working group side we are now considering, should we add, as some more information but affordances and also on discovery side, but overall we're thinking that it has been becoming rather stable document, not much updates coming. So we should probably do a request for publication soon and get it get it get it done.

A

With a quick update on secure bootstrapping for royalty, I asked from the authors. What's current state seems to be it's rather saying that was on the last IETF, so documented device, bootstrapping terminals and relationships identifying some common design assumptions and investing in benefits and challenges of EAP. There was no update for this ITF, but we should be one coming for the next IETF meeting.

A

And then on the quick update on the wiki activity, so this is I'm. You could think of a sub activity on thinking research group focusing kinda on the top of the stack. So, as the name implies on semantics and hypermedia interoperability, we had two meetings between the idea tips. There was one face-to-face work meeting, because one DM had a three-day face-to-face meeting in cheese town in Sweden about a month ago, so we had a face-to-face we. She works up right after that meeting on that meeting.

A

What we did we focused on the 1 billion topics, because they were still fresh in mind and there was some interesting, architectural and research considerations to be think about. So we did think about the architecture and terminology discussed like how we get some more alignment on a bigger picture and, in particular the chasin pointer and somatic breadcrumbs was a topic that was I discussed in quite in detail and then further on the processing model. How do you handle one VM and descriptions and how you turn them into something are useful in other contexts.

A

We did also have one wish the online meeting a few weeks before the idea there. Our key focus was on data molar versioning. So this is a topic. A lot of IOT organizations seem to be heating right. Now you make your first version of data models. Then you realized. Maybe there are some things that should have been done slightly different way. What is a good way to support this evolution and versioning is one mechanism what we have been using in the past.

A

That has some some challenges in particle in this discuss, so we're talking what are those challenges and how war, but perhaps better ways to achieve the evolution aspects, so we are planning on only wishing note on that aspect. Right now solves a lot of material in the in the meeting notes from that discussion, and also, of course, one data model and and hackathon activities that were focused on this online meeting.

A

Then, to give you a quick update on the vichy hackathon, so, as I mentioned, we'll be having these hackathon activities over seven times at the ITF hackathons in this hackathon, our plan was to focus again on the data model, convergence of quite similar to last IETF and in particular, translation using the one day tomorrow, tools and models.

A

Also, since we had this joint activity, we double three C of starting on Friday and going on axis. For years we were working together with web of things and they had their breakfast and they were planning to work on integration of core resource directories to further their own support, discover capabilities in the book wave or things context and then already aspects. The past few ideas will be working on this. You P young, face conversion for binary to see poor enhancements, but Eve Allah will give an closer update on this.

A

So what did we achieve over those past two days? So, as I mentioned, big activity was around one day, demo tools and concepts. So we've been working on conversion tools to move between live with em time. If summer rolls and one day the model models automatically, so you wouldn't have to do that kind of conversions. Ever manually we already at the previous ayah 80, °f and hackathon, we did have a first version of coming from apes at 1:00 a.m.

A

we did enhance that conversion to will mainly focusing going from one DM to if so, and it seems that we can do mainly loss translation between these two models already right now. Also, what we did is enhance this data more all winter, so it's very convenient to have a tool to actually check out your conversions, make sense and have automated tools in general. It may it's very helpful helpful in this context.

A

So what we did use these tool tool sets also to set up a automated continuous integration in the github of one VM test repo, that whenever there are new submissions they're automatically tested, they actually do confirm to the guidelines and and style set up for that. So all those three tools: they are available as open source contributions and you have the github. You are right there if you're interested to have a look at the details.

A

In addition to hacking, we also had very good discussions on architecture how we use semantics, how we, how can we deal with dynamic descriptions of things and data models and, overall, how do we get convergence are occurs? Sto switch off course. Lot of stos are working on very similar topics. How do we get more more and more convergence across those, so we have better interoperability going long-term on the double 3c web of things topic. There was now a first version of thing, description, discovery using qua party up up and running.

A

That was also a good success and also we asked good progress made on yupi. That Ivalo will tell you more in a bit one thing that we are discussing going forward. How do we bring these things together? Was that how can we take from one DM SDF descriptions to create thing descriptions? Perhaps we're using some are already of tooling in between and then be able to expose this?

A

You know what we are now calling semantics proxy that would enable to use one applications and and devices from different ecosystems and then working together using a proxy or a gateway, but Michael coaster will be going in more details on on his own on his presentation. Slot.

A

So that was a quick update on the research group activities. Any questions comments on those.

A

Okay, in that case, that's Ivalo and you pee.

D

Hello, everyone, my name, is Eva Petrov and I will present you the advancement of you pee, so a little bit of context in some networks like everyone, another constraint networks. Quite often we use binary formats in order to send data and it could be Modbus.

D

It could be some other proprietary formats, but those pellets are rather difficult to use in other systems and in order to improve interoperability, it would be good to have a common way to express how the binary data could be parsed into JSON sibour or something else that different systems could use directly.

D

So this is the goal of U P and what happened during the hackathon was I implemented, part of the encoding. It worked well and there are still some parts from the encoding that are not implemented, but so far there were no difficulties. I looked how we can express parsing, coop and different other different formats in U, P and Delta. Encoding server rather unattractive so to speak, but I think I'm and to get that done using experts which are part of yonk, so no magic there and I looked at Modbus, which seemed to be rather easy.

D

So I think I'll be looking a little bit at some concrete examples to see that everything works out well and that I can implement some applications with TP. The differences in the draft are I introduced, one statement and expert expressions in case. We need to express more difficult or more complex parsing.

D

They are the details about list, then definition before that was to be defined now I mean the building types are explicitly listed and there are details about how string values could be mapped to numbers, namely using enumerations, and try to improve the readability by moving some things around. So my idea for steps forward is to implement some real example. Using models, maybe have some I, don't know lights or some other actual devices that use models and implement use. Each of that with you P and C. What are other examples that we want to do?

D

Use get any feedback, hopefully some feedback, hopefully, and take it from there, so that it's any questions comments.

A

Okay, thankthank see Bella. Do we have a next puppy? Yes,.

E

We're well on time I heard I'm mateus Kovich, I'm presenting and the IOT h computing draft, also on behalf on my of my co offers so to look a bit back, so this draft originally started as basically, we are providing use cases and examples how much computing can help IOT.

E

We saw a growing interest with this, so in Prague. Actually we had a discussion at one of DT to TRG pre meetings and number of new offers joined and in the last meeting this was done actually also merged with the already existing work. So dick and Eve did some work on a survey of H computing and again analysis. This was merged in the document. So, basically, what you can see is that the draft has evolved quite a bit so starting from just listing.

E

Ok, they are interesting use cases and we actually moved forward to some gap. Analysis which should be the ultimate goal of this draft, basically do to identify white spots. Is there something that needs to be done so that H computing becomes really useful for IOT?

E

So what are the major updates for the version that we submitted shortly before this ITF?

E

One part of the work actually went into operations, so we converted everything to mark down and move to get up, because we now have actually quite a number of offers around the globe, so this smooths, hopefully a bit the way forward to work on this. The major changes that we did is one is that we moved from the edge architecture that was originally described in the document to models, and the reason is we do not want to promote or our preclude certain architectures, but it's really about okay.

E

This is what you find in the wild, and this is how edge computing is useful to solve your IOT problems and the other major change was dead. Yeah we moved from showing just okay, those are use cases. This is what you find out there more to a function analysis. So we really want to see okay. What are those functions that you need from the edge? So Carson had a very nice example that, for instance, the the smartphone became a very good device to configure new IOT devices. But what is the equivalent?

E

What is the box that we use? For instance, if you need and I would he device needs to store data, maybe needs to offload some computation? How do you do that? Other management functions and your hot topic in general is onboarding.

E

Maybe there's also some benefit if you have this, for instance on-premise- and this is what we want to do ultimately, to basically look at what are the different functions that you need and then do this gap, analysis or whites show the white spots where there's potential work for ATL, so we met at this ITF, so the offers met and we discussed basically several to do so.

E

We have quite some homework for now, so some of the things ya need to be written better out in the document to actually arrive at these goals and we set ourselves a timeline. So we want to update the draft with what we discussed by around Christmas so that we can actually gain feedback and get some reviews in early next year, so that we can get out a new version.

E

That then includes this feedback by next ITF may ask the room, who has interest in reviewing this document, and then maybe someone who can note this down see one two. Three.

E

F

Cool thanks Michael in participating, more actively, I'll, probably IETF in Vancouver as well. Okay,.

G

E

G

You put up your hands again because I would like to record names, Michael's recognition.

H

I

H

F

And and Michael McCaul thank.

E

You and I think the special was out there with the adoption foreign research group document, since we had quite some change and I also want to implement this change here. More clearly, now have we decided, let's get a few more versions out there there to be a as office, I, actually really happy with it and then post this questions again.

H

So there's an open source or a set of open source projects happening under the Linux Foundation as part of something called LF edge, so I'll since I'm working in that space, I'll take a look at you know, terminology and other things that might be able to harmonize a bit. But I had a question about the draft to the draft. That sheet has a few use cases in there are you planning on keeping those expanding them because, as far as I know, there's like gazillion use cases right exactly so.

E

Yet that was that that we, you definitely want to look at real world use cases, but then more focus more on the models that you find in there. So basically Universal patterns that can be applied, but not give you the complete list of use cases or solutions out there. Okay,.

E

Maybe one comment: we quite have quite an extensive appendix at the moment that lists projects that are out there and gives a quick introduction I think we have to see how we give of this. If you really want to have a look at this huge appendix, as you said, it's a gazillion.

J

Zoom opt with the coin co-chair hat on I think this would be interesting work to do like, maybe in collaboration with us, because it seems to be a lot of commonality in terms of the edge and the discovery of computation and data and storage. So I think we should talk about. Maybe you presenting to us at a future IETF, maybe in Vancouver, and maybe do some things together. Yeah.

E

So, in fact, I mean I presented this in proc I think also to address and make people in Cohen aware of this, and we also actually discussed yesterday that we should talk more about the network as something that could be discovered. So the what modalities are there so once we have this in there, it's definitely good to also maybe ask for reviewers in coin and yeah to keep the the two groups together, because it's yeah related to both yeah.

J

I think it is so I think yeah we should. We should move.

F

J

F

J

F

Thank you yeah and likewise that's my interest is I'm, doing work on discovery and watt and I think there's some heavy overlap. We get reading and other things very.

E

Good, the interest grows further. Okay, I'm done.

A

Excellent Thank, You Matthias, and so this ends our our first thought on the overview of activities and documents. So next we have a Michael Custer remotely presenting the IOT data model, convergence Michael a please go ahead.

A

And Michael, if you're talking, we cannot hear you right now.

K

A

K

Thanks, okay, goodnight I had to click a button here to do that. So how did the slides work.

A

If you are in the presenter mode, you could also present there or- or you just asked me to put the next slide, whatever works for you, so.

K

I'm in presenter mode and I can advance the slides, then put the button somewhere. Mm-Hm I see the slide.

A

Probably it's easier if you ask me to put the next slide on.

K

Okay, so please next slide go I want to would talk about two activities that are going on in the past. We've talked about IOT schema.org and that's what really, what we're calling them?

K

Ie extensions for, schema.org to to to make it clear what we're doing and then now the one data model that I think I've talked about, maybe one time before so slide, please so one data model to refresh people's memory where we're not an organization but but we're a sort of a Federation of organizations that are working under a liaison agreement and initially what we're working on is a common language for how we express semantic models for IOT.

K

That's that's simple enough to be usable by application domain experts, so you don't have to become a you know, a modeling expert so and also eventually, we want to use it for converging the definitions of common IOT device types so that someone wanting to create a device type using some common patterns has a model that already exists right, megabyte please.

K

So the history is, it came from the fall of 2018, so we've been working about a year and there was a good cross industry consensus that common data models were what we really needed to go after is the next key inhibitor for IOT growth. So we we work in the open. Mostly we work at least the tools are in the open and it get up repository and then, when the me, when the models are contributed, they'll be in the open as well. Next slide, please so right.

K

So what we're doing is first, creating the language as I mentioned, and then we're creating a representative set of models representative set of models, sort of a set of models from each contributing organization or or a vendor, to sort of pressure test this language, and but once we get that done, organizations are going to contribute models for sort of down selections. What we call that and then and then there's going to be a process for public public publishing these models. Next slide, please the status.

K

Okay, we we've been having weekly technical meetings and we've had four face-to-face meetings over the year.

K

I believe four, if I can count right and there's a pretty good set of models, that's being used to pressure test and and that the last face-to-face meeting is uttering mentioned we that was in Kista, we approved a version of the language to proceed with contribution, so we've said another language is stable and we're going to go forward with with the next phase of the process and we've set up an area for contributions to be uploaded called the playground and we're also setting up, as I mentioned, of some CI and some more formal contribution areas next slide.

K

Please the outcomes of this really one good outcome is: we've all agreed to publish our license models under the open-source license. The BSD three clouds license, which is a very permissive license, as already mentioned, there's some a lot of work that they've done in tools and translations already we have some SDF models for dot dot, which is like the Alliance lighting and energy we're working on. We have some st of models for ocf appliances in progress and ocf since they're sort of using swagger as an underlying language. Thank you.

K

This is an alternative having developers use swagger. This is an easier entry point for developers. Pardon me come in and create and maintain models and they're working on the similar thing, as, as was lightweight m2m, some automatic mapping between ocf and and one diem next slide, please.

K

So what we're you know we're working on practical, IOT, semantics. What we mean is how do we? What are the things we need to look at first, to get things hooked up in a way that they're, interoperable and so we're addressing. We know we need to look at the affordances of devices.

K

We also need to look at their behaviors and the context of, but we're really starting with the scope focusing on affordances first, because we have device vendors involved and then also that that's really where we need to try to normalize first, because that's where a lot of divergences today, where people are doing things in a in the similar way, but but different enough to to not be quite interoperable next slide.

K

Please so we're talking that a model I don't want to spend too much time on it, but to point out that what we're using is a fundamental concept of affordances in three categories: events, actions and properties and then we're also defining data types as a semantic category. That's reusable semantically, across the different affordance categories. We have a thing, call and object that we use to group categories into cooperative, functional units like to do things like control and like them, in control and door, locking and unlocking, and things like that.

K

And then we have some higher-level compositional concepts like a like a thing that can be just billed as almost any any bag of any of the other things together, including other things, and then we have a view that we use for virtualization of hortons. So you can have used that a lot, so we use that have the same affordance but presented somewhat differently or in different with different constraints.

K

X line, please so a quick design of review of that by there's a much deeper set of slides. This is just a sort of skipping through this present, but I want to point out that this is a JSON based language. We sort of wanted to create a domain language, but it's sort of based on JSON and use JSON, schema validation and things like that. One, the very front end, but we also wanted to be convertible to back-end. So here's an example of a definition with three affordances next slide.

K

Please, and if you can see that it's a bit of an eye chart but basically there's an information part that says: here's where it came from in its version- and you know the stuff that people like to keep track of then some namespaces, so that we can sort of partition the different submissions and contributions and sort of combine them in some more controlled ways and then there's some definitions of these different classes, object, property and actions here and there's some keywords that that say what you're defining and then there's some some terms that you're, defining and redefining switch and value, and on and off next slide.

K

Please next steps for one to M. We were updating the language, we're adding more features to the language, we're working on some of this model: convergence across vendors and stos. We think it's going to be fairly easy to to build some simple, limited models that we can all share and then work toward. You know getting there come from thermostat a common lightbulb.

K

We we basically want to start with, demonstrating, though some some immediate value, based on doing this translation and building some gateways in some ways of creating a layer of interoperability before we build the interoperability right into all of the end points a little bit more about that coming up and study eluted we're calling it the semantic proxy next slide. We've got a couple slides about that. So the idea is that we we use w3c thing description as a way to associate the metadata.

K

The meta have affordances these high levels, abstract descriptions with concrete protocol bindings, and that's really what the w3c thing description was designed to do was create and descriptions of instances of things that have high-level abstract, affordances and concrete protocol bindings and different flavors. So we want to use basically two of these one for each flavor of protocol, one from the thing we're consuming and translating from if you will and the other we're exposing and translating to- and obviously you could have a duplex version of this. But this is the basic pattern.

K

There's already a couple of pieces of software. They can do the semantic proxy part and know how to interpret w3c thing descriptions. So we think this is going to be a fairly easy thing to start prototyping in our hackathons and and some of the other code programming and demo activities next slide. Please the way we feed it is by taking some SDF definition and converting it into well. I, say RDF here, they're really.

I

All we need our URI.

K

For annotation, but but if we have RDF that we can have a graph backs, the annotation, we don't have to build the graph right into the endpoints. You have a graph, that's just described in a model through these relationships between these affordances and things and views, and what have you and then you have applications that that consume things and they interoperate at the level of the affordances. So once I know, I'm talking to a lightbulb I'd know how to gem. It next slide. Please yeah. So.

D

K

Other thing we're working on I've been working on for really a number of years now and we really kind of kicked it off at the first wishi workshop. So that's how long we've been working on this as well, and we made a lot of progress getting some some trial formats, but together in the beginning and well I'm going to go through sort of where we started and where we are and where we're going to go from here, because there's a lot of overlap with what we're doing in one data model as well.

K

So next slide, please yeah. So we started off to create an extension to schema.org that would add I semantics to schema.org and without going into too much detail. Schema.Org is a way of using basically rdf statements to annotate webpages and the idea of statements are from a model- that's pretty low constrained. So it really take a lot of reasoning to interpret what's in the webpages in terms of semantic annotation, but it was originally created for search engine optimization.

K

It has kind of grown into a thing: that's starting to drive, api's and drive interactions with webpages. More and more so what we wanted to work with the relevant vendors and SDOs familiar to architects, a common information model for IOT, so it's gonna have the same problem from a little bit different perspective.

K

We we were focusing on the process to enable free contribution from diverse organizations to really have a low bar and and very printer's of open source, royalty-free licensing and drive or non normalization to a common model, so really again a lot in common.

K

We wanted the domain and subject experts to be able to work with the tooling and not have to become experts in the Semantic Web to in order to create models, and we wanted to work on practical integration with schema.org so that existing tooling and and that can be easily adapted and expended to to work with IOT stuff. So next slide, please hello. Our status where we've come to is we have a common meta model which really we feel it's already adopted in the industry.

K

In other words, we didn't have to go evangelize a new way of modeling things, because we we looked at what people were doing. These categories are really pretty common across all the different organizations and again it comes down to events, actions and properties, and you know again, we have a lot of discussions about.

K

You know how these are similar to other ways of describing similar things and how they're different, but but essentially there we found a lot of commonality and even in how these were interpreted between the different organizations and vendors and people who were already doing some modeling. So the other thing we wanted to do in schema.org, though, is connect them to these other, the other ontologies, if you will vocabularies such as the Geneva VSS, schema work and BRIC schema that are being done in the w3c and also their soso and SSN.

K

So since we have an RDF base, we can build graphs that include you know other concepts and other types of descriptor scripted linkages. So we published a strawman definitions, a set of Strama and definitions on a on a prototype website.

K

That's at that I mean IOT schema.org, all one bird and we published some definitions from some common IOT capabilities and we've been using them in the w3c web of things and in the wishi work in the hands-on plug fests and in some of the examples and evaluations right. So next slide, please, the meta model for the IOT schema extensions is very similar to what you're going to see in the web of things meta model, as well as what we built in one DM, there's, basically, some interaction patterns that are events, actions and properties.

K

What we've done in IOT schema has rep them up in a in a very similar functional element to what we were calling an object in one DM. This is a what we call the capability and the capability is basically something like I can turn a light on and off.

K

So here's an on/off state property that represents the state, whether it's on or off, here's an action for turning the light on and the action for, turning it off, and maybe some events having to do with you know the state changing or something of that nature, and then their data schemas that describe you know how the data items looked and what the constraints are not so much.

K

The on the air package schema like schema on the air, but more like this action has two parameters: one is the target brightness and one it's the transition time and they are they're both numbers, and then we allow levels of constraint on top of that, a range of the number, the depth value of the number, whether it's an integer or a fractional number of floating point, a fixed point, etc.

K

So we want we want to be flexible with data schemas to say, be either able to constrain a thing to having to be an integer in the definition itself or to to allow that to be defined. In you know, an adaptation layer- and it is the protocol binding- is what we call them, and so we'll see more about protocol bindings with the web of things, work that and mccool will be presenting right after this.

K

So the the new concept we're adding here, though, is a linkage to a thing called feature of interest, which is a really already a common concept from the onm ontology, on which SSN and sosa and a lot of these other more recent works are derived from and feature of interest. Basically, in my reading comes down to mostly things that are either a location or some kind of equipment.

K

Some kind of physical sort of piece of things that you want to describe and, of course there are features of interest, can be properties of those things and they can be much broader than that, but for our or our sort of for describing what what they do, they, they kind of describe. You know the the the connected world nouns, if you will places and things, but but things like doors, not things like door, locks, right and and so the door lock.

K

Once you combine the door lock, which is a thing we provide interaction patterns for like lock, unlock and determine lock date and events about things being unlocked those patterns. Once we combine the idea of a door lock with the feature of interest being a door, then we have a way of saying lock the door unlock the door and we start getting closer to a real world interaction pattern, as opposed to having to think about a device.

K

That's responding to an app on your and that's really what we want to get to with the semantics or something that's both more interoperable, but also more connected to the real world right now. Next slide, please that's! That's enough on that. So our test cases we've integrated these definitions with wot thing, descriptions, weather thing, thing, descriptions and there's some semantic annotations. If there may or may not be an example here, and it's like I'm, not sure I wish I put numbers on them.

K

You know these I think we've we've been using these definitions of things like switches and light dimming and motion sensing, and it's turned out to work out pretty well, but it's been mostly a manual exercise. We haven't really we've done a little bit of discovery, but we haven't really done a whole lot of automation. Yet some other organizations are using this in the weather thing stuff as well to talk about their devices and protocols. I think we might have about 50% of the participants.

K

You know like using IOT schema or more and there's some interesting read, applications that we developed that have been developed, I'd, say we, but mostly been by demons by Darko and Aparna that have developed. These thing.

K

Description based note, read applications that that are really easy to use and kind of plug and play, and we really want to work on discovery next, as sort of a thing that we're we're looking at in terms of interfacing, interacting with the intersecting with the w3c one of the things work right next slide, please so again, IOT schema for node-red there's a github project that you can go, look at and play with, but basically we we put IOT schema into node-red such that you can do semantic connections between between things and we there are essentially from a practical sense.

K

You can connect events, actions and properties with things that trigger them and things that observes that up your own code and you can bring in some nodes that do automatic adaptation of units and ranges and and measures and things like that quantities and units right next slide, please so the schema.org integration, but what we. What we found is that there there's a little bit of an impedance mismatch and what first in the class names that we're doing, were naming things that are similar to things that are already named.

K

So we probably need to invent a bunch of new names and also we have a lot of different property types. We you know, if you think about it, if you think about properties as being advanced actions, property types and the term rdf relations as being events, actions, properties, capabilities, datatypes things- you don't have that many, but if you think about them as being temperature and humidity and acceleration and voltage and and all these other things that you can do in controls, it quickly becomes hundreds or thousands.

K

So what we're looking for is a way that we can do some layered connection to schema.org so that a schema.org application can discover that it has some basic things that it can do, but then I might need to have some extra. You know awareness in order to know how to actually do some of these things and manipulate these it'll it'll need to need to be able to go to another level, just really just like.

K

If you wanted web software using schema.org today to understand which venue you're talking about- and you know the basic pattern is there, but then you still need software. That's able to show different arrangements of seats in your baby and etc. The same thing with IOT you'll need software that'll deal with different types of cameras for execrable and doesn't have to assume all cameras are the same because you have some annotation, like the in description to tell you what affordances are there and what what you can do and what you can write so next slide. Please!

K

Ok! So we started the community group for the IOT schema. We we have a few members, but we haven't really ramped it up. Yet the purpose of the group is to have an IPR.

K

Then you, if you will for accepting contributions.

K

So what we're hoping to do is sort of combine this with the with the one data model works, so that we can use one day tomorrow as a front-end for entering schemas and we're hoping that we can all use DSD 3 clause and when the community group as a as a way to accept contributions and publish things on the IOT schema side.

K

So one data model will have each process, have down selecting things and then we'll have another process of accepting those or other types of definitions into IOT scheme up for publication there all right next slide, please we're getting close here so right.

K

This is really just more of the same. We're aligned with the the metamodel expect to be able to use the wantin data model, language and tools to make this developer friendly front-end. So we don't have to duplicate that work, but we need to work on converting from one data model to RDF and and one example that was really interesting in my exercise of doing some strawman conversions was that in RDF, enum values are you are eyes, they don't have to be integer or string or boolean, or anything like that. They can be bound to different.

K

You know different. You can have, for example, the light control that uses a true/false boolean, that community the text, phrases on and off and in English, or it can use, say 0 1 integers that represent true and false, and those can all be described by the same URI enum, but they can't be described by the same JSON schema heat source for thinking about what how to deal with conversions there, and there are a couple of issues like that.

K

That can interest me right next slide- is getting yeah so going forward, we're going to create an experimental error area for for people to sort of host these definitions and test the the hosting of them on schema.org.

K

We already have them on our own experimental site, create namespaces I, don't have some kind of CI process and then have a way so that when someone upload definitions, they can immediately dereference them in their own namespace and not have to wait until you know things have been argued about and accepted so that we have some some ways that get some traction immediately on. That seems to be the biggest barrier to people using semantics.

K

Is you really need them to be sort of globally referenceable, or at least referenceable, within the scope of all of your experiments, which key is pretty broad, so to have a place to upload them, and then reference them online is is pretty useful and valuable. So we want to try to provide that I'm early on right next slide. Please.

K

So here are some your eyes for the one data model, work and some semantic proxy proposal, and on the next slide there are some there's some resources for some of the other stuff that that I talked about. So with that I think we're four. We have a few minutes. We for questions.

G

Well, one question that came up in the jabber room was: how do you actually use these model files? So is this something like a mud, safe description? You would attach to a device, so when a device is integrated into a system, the system starts to read that model or how are these one data models being used.

K

So they're there they will there they're being used and will be used as semantic annotation for a thing description. So in that sense, yes, it is they're there they're attached to a description of a concrete thing, an instance of a thing that has Network addresses and security protocols, and things like that and they're basically used to orchestrate the connection of an application to a connected thing and it's understanding how to use it's a connected thing.

K

So in that sense, it's a sort of complementary to something like a mud file, that kind of describes for a different actor in the system.

K

What to expect from a thing a mud file described to a network after what kind of behavior to expect this describes to an application that wants to use the thing, what kind of affordances and, and- and you know, and again it's through common terminology- that it does that, so it means to have an understanding of the meaning based on terminology, and so in that sense it's also similar to the mud files.

K

There's a schema for and the set of terms and a set of concepts that are used to talk about what this device has is and does yeah.

F

So if I can comment on this, we discuss this at the workshop last time and I think one way to think about it is an SDF file. It's kind of a class definition for a set of products. They are our product line.

F

A TV file is a description of an instance of advice, so it has all that the modeling stuff, plus things like IDs and and protocol bindings of URLs and whatever for a particular device, I think mud, describes, kind of a system network configuration so I think how the routers are configured for both security and quality of service and so forth. I do think one missing piece here is: how do you configure orchestration? How do you configure the system?

F

How do you set up set in the networks of devices to do a certain task and that's something that we probably to think about it more, but one thing we looking at in TV, for example, of using links for that. But me that's kind of indirectly do a new. We need more direct, wait, a minute data for systems.

L

Hi, this is Eve Schuler from Intel. Thanks for the presentation, it's great to see how far you guys have come in the last year or since the last time you spoke about this similar to some of the other questions. It would be really great to see an example of how things come online and how it maps to the various parts of the architecture- and you know when things get called so really having grounding it in an example where these different pieces get pulled in. That would be really great to see in an upcoming talk.

L

The other thought I had was. Is it? Are you thinking about that in these name spaces, where people define their affordances, that there's room for the evolution of them? Is there that kind of flexibility, because things just continue to change over time? Oh.

K

That's that's a great topic, the the because really, what we're discovering is that the the normal mode of things is going to be. You know evolving and not so much static, especially just for the next sort of whatever time periods. So there's been a lot of discussion about how to enable innovation and things to evolve and not sort of keep them fixed, well, well, having interoperability and not breaking interoperability, and so some of the some of the versioning discussion covers that and just some of the basics. How do we build and partition models?

K

We make the pieces small enough so that if a monkey's needs to change a lot, it can be substituted with a different piece, and you know we're really just learning about that. So that's that's! Really! One of the ongoing topics I think, oh, so.

L

I think I'll amend what I just suggested earlier, which is I'd love to see an example sort of from beginning to end how somebody using these components would actually tie in with them. You know just grounding it in a use case. I would even go further to say you know, and then what happens when things get changed? Let's, let's include that part of the example as well, but anyway enough for now, but thanks thanks very much. That was great.

L

M

You this is Eliot Eve stay tuned. This is a pretty big topic, actually that you just hit on it's actually a really good one. We have a lot and this the IETF right. We like building, building blocks and actually soda soda other SES building blocks are nice and easy to build right. So the question is: how do you put them together right? This is a topic that I'm about to delve into in just a few minutes, so I just want to say, stay tuned.

A

Great, thank you Michael. Thank you. Everyone, yeah, I, think absolutely. This is a topic. We should have a closer look. We're gonna start on the last slot for for today, and we should definitely continue on their upcoming activities in particle. The upcoming we she calls is something where we could take deep dives on this. So anyone interested in topic of this and at ilt data model and interoperability at large very welcome to join the way she goes.

A

Okay, but now we need to move on. We have one more one: more update from from a double 3c whack of things coming and then we'll have the final discussion that Elliot was already referring to thanks a lot Michael.

A

Okay, so Michael McCord, please go ahead. Okay,.

F

You guys can hear me: okay, yes,.

N

F

So these slides will look familiar to some people, who are the last idea, so I'm actually updating a slide back that was done before and I've highlighted the changes. So basically what other things is progressing and I'm.

F

Given that the EMA status, the next step is parts relate to our new Charter and items that we're going to be working on over the next two years and in particular, there's some items of high relevance to this discussion and clean discovery and building so anyways are you know any standardization we're looking at enhancing interoperability and we actually have two two working groups in w3c: the interest group?

F

Basically those research- and you know priestly others, work drafts and so forth, and also you know, validation and that was renewed for another couple years in October and the the working group just finished their last charter. We just delivered our candidate recommendations that should go to PR by the end of the year.

F

We have a draft, that's been submitted and is in process right now being voted on for a new set of work items and blue rules over the next two years and I'll discuss that at the end of this talk, after giving an update of you know where we are so I'm going to go pretty quickly through the background and the current status, so you've seen some as before. So we have more time to spend on the new items next slide right.

F

So the basic glue bowls of the last charter were the things you see listed here. Thing descriptions, pretty guidelines, 50, API and buying templates, so that the main verbal here is the thing description which is already been mentioned, and basically is the metadata format that describes the interaction model, our affordances of the devices. This interaction model is just a closely aligned with IOT system in a word and actually fvf.

F

So we have a similar set of interactions and is our intention to remain line and, in fact, to improve our alignment to make sure the cavalieri is consistent. Tvs generally are also a place to use annotations they're generated by high-level models. So, as I mentioned before the way, I think of SDF is a class definition that defines vocabulary and the high-level models and the TD of the description of the actual instance of the device, which includes all that. It also includes things like here's, the URL.

F

You have to talk to to talk to get this property. Here's the security bindings, here's the location of the device here, the idea that a license or so a particular device. Now there's also I, mentioned protocol bindings. The purpose of that is to say, okay, this high level interaction model. You know I, think again read and write a property. For example. How does that map down to a specific protocol like Co app? What are the URLs or any header options and so forth?

F

So we are also a document we published the buying templates, which basically describe informatively how you would map for particular protocol a particular attraction, the scripting API. We actually decided not to publish as an enormity of document that are still discussing the discipline model, for it is a scripting API enables essentially, you know, computing and rules engines and this sort of thing, and so it's it. It depends a lot on the point of all of what it actually looks like.

F

We do have a strong draft and we do have an implantation is open source and we have used it for many projects and it is quite convenient we're just uh to work on the landing zone for it a bit more. So next slide just a summary of the status of these. So we have informative documents and notes and we have rec tracks or normative documents. I didn't mention the architecture, but the architecture is kind of like just describes the whole system and all the pieces put together. So we are taking kind of butwe blocks approach.

F

The architecture describes, you know how ability blocks fit together and we have more building blocks in the pipe like discovery as I'll mention in that. Ok next slide, so yeah this a bit more detail on this. So you know the what architecture document describes constraints about. You know what kinds of devices and protocols make sense in the context of a a lo of things, so particular weather things definitely goes beyond ATP and it arguably goes beyond restful interfaces.

F

So we've been looking at targeting pub/sub type things in GDP and we're currently looking at OPC UA and things like this, but the idea, those it Maps these protocols down to an abstracts of affordances and the way to think about these affordances is an affordance is like what do you want to do open the door and a protocol binding is how do you do that and what URLs do I send what messages to etc? What verbs do I use?

F

So you think description example over here and it's a JSON file that you know describe various things now actually want to say it's actually more specifically, it can be interpreted as of json-ld 1.1 file and Jase melty. One point one has the advantage you can import it into an RDF database and liberate it with. You know, Rd of things, however, you're careful to avoid dependency on RDF. So not everyone wants to deal with RDF and we don't want to create the expectation you have to understand.

F

Argh, you have to use thing descriptions, so you can treat it like a regular JSON file and that's totally fine. There's many use cases that just do that. However, the Act context there describes the version and the vocabulary that's used in this, and it also allows us to have pull in extensions. So, for example, if you want to use vocabulary defined by LG steam at org, you could define that IOT vocabulary and start using terms from there like IOT light.

F

If you wanted to use a vocabulary defined by the SDF file, one approach we're looking at is you know, compiling sto down to RDF and importing the vocabulary, just like you do here for IOT schema.org. So that's how you connect these two together and then, if you then import the description into a database you'd be able to interpret all the information from both SDF and the instance. Definition ah next slide right. So then the notes we have actually a pretty big document on security and privacy.

F

Its guidelines only there's also a best practices document, which is more you know aimed at you know what you actually need to do to build something that's a reasonable one thing worth saying is things ascriptions are descriptive, so they describe what's out there, including brownfield devices, but there are brownfield devices that in do a very good job of security. So to describe those things, we have to have the descriptive power to describe things that don't have good security.

F

We also want encourage people to do good security, so we we have a best practices document as well. That describe that you should be doing, and one thing we're actually looking at in our next round is profiles that are a bit more normative about what you should be doing anyways this could be API I mentioned. Is you know it's we're talking about various landings on for next life right so mention just in ld1.

F

We we also have a stream looking at various security protocols and we're looking at you know explaining that you can add mystery protocols with the Semitic extension mechanism and yes, and we currently mostly look at HCP and Co app and we're now and M, cuties and I think is partly supported. We're working on more of that and we're looking at further things like, obviously you in the future. Ok, next slide.

F

Ok, so here's a lot of candidates, been least you know five minutes my talk discussing. So this is our next two years and we got a bunch of things you want to work on now. The important most important things here are probably the interoperability profiles, which has its own normative global discovery, which has a normative deliverable and, and then things like the protocol vocabulary bindings. So we're doing a lot of work, just extending things to new protocols like OPC, UA and and obviously, and fixing up MPT and so forth, we're also about under profiles.

F

One of the issues is that thing descriptions are open. They can describe lots of things, including things in the future. That might appear right. The trouble is, if you want to implement a system and say it's compatible with the things device, a little store and buy whether things device and bring it home and have it work right?

F

You need to have a more you know finite set of requirements, for what does it mean to implement something that can read any web of Things device or talk to it, and so the idea of profiles is, we would have a finitely implementable subset. You know so, like so have a profile that says you only have to support these three protocols or whatever, and so we are working on this core profile.

F

That sort of is, you know the minimum requirements for something that that if you satisfy this court file, it will not operate out of the box. So under discovery we are basically I have a. We had. A document worked on the hackathon that you can look at it's still very early, but at a high level I want to say we don't. We would like to really avoid reinventing the wheel here.

F

So it's very very important that and we have a full intention to working closely with IETF with looking at existing standards by doing to say at a high level, the arkyn are looking at is to divide this into two phases, actually pretty to that one see we're actually looking both local and global. So by discovery, I don't mean no broadcast something. A local network can get pings back. That kind of thing, don't assume that a discover I mean how do you get get access to the TV metadata?

F

How do you find it, and that could be a global problem, like you know, on the internet, you're looking at like a smart city, and you want to like find services to handle traffic, maybe local in your home network. You know finding the light, lights and light switches, so we want to handle both those contexts in a consistent way, and we also want to highly emphasized privacy and security, so we want to have a privacy preserving architecture. So the general strategy looking at is to divide the problem into two parts: introductions and exploration introductions.

F

We first contact protocols which, basically is what the very first thing you do when you're in unknown network and then exploration is finding and getting access to detailed metadata about the available services and between those two. You have to have an authentication process so that you're only giving out that detailed metadata to people who have authorization to it and their right to use it. And so the idea is the introduction protocol should be privacy.

F

Conservative should be open, but giving you a as little as possible and in fact we want to do- is just have introductions point at a directory service. The directory service then requires authentication and authorization with the appropriate access controls, and then you can do the search. This also prevents things like the Milo service attacks, because you know maybe metadata searches can be expensive. So that's the general protocol, but we have many candidates for both introductions and for directories. We also have many different ways in which you could do queries.

F

You know from simple keyword, search or location-based search to full semantics, no Sparkle, endpoint, Mantic queries and you want to conditionally implement all those in all possible devices. So we, however, have two two years to discuss this, and you know we are currently in the process of gathering requirements and understand the use cases and surveying the landscape and figured out what makes sense we did do you know a deep dive on the core we just directory. It's certainly one of the one of the candidates where things are looking at for like directory services.

F

Likewise for introductions, you know things like DNS DNS DHCP to like that are also quite reasonable. Introductory mechanisms I also feel be more than one way to do this, especially for introductions. Many different styles introductions could point the same directory service and that's totally fine different context. We require different mechanisms for first contract for identifier management, there's a group in w3c that is looking at the whole process of decentralized enta fires, and this is also an issue that it's close to a to privacy.

F

You know how do you deal with mutable identifiers, temporary identifiers, x', non-global identifiers? You know locally scoped in a fire just a thing, and so and actually what, if you only changed in a fire land device to like break tracking? How does that happen? How do you how to mythical updates and not mentioned here, actually is onboarding which we're looking at but I would say. The primary focus in the past has been during operational phase.

F

I think when we look at discovery, obviously we're looking at discovery phase, one of the first things you want to do with the onboard device. Is you discover the places you can onboard to so I think they're, close related and obviously to do ax controls you need to have keys and so forth being provision.

O

F

We're going to be looking again at the life cycle and probably touching at least on the onboarding process and again there's a whole set of standards. We figure out be consistent with rate and I guess. One last final thing is link relation types, so I the thing description has a section: it's not an example that can link the very resources it could have. Various resources, like maybe the TV points at an SDF file, to say that the TV is an instance of that class of devices, or it has these capabilities.

F

It could also be as part of orchestration. You know a light switch might be associated with light. You might have a link for that, but we don't have any standard link relation types and, of course, is a set of regulations, types in IMA, but there is a huge number and it's not clear, what's used for which purpose. So we want to be able to clarify that and and define what, what relations to used, what purpose and complex interactions.

F

Finally, that's one more thing we're looking at currently, you can use thing descriptions for like media like controls, but it's not obvious, not how obvious what happens when you post a new resource on a device? Does it change the thing description, or does it just appear as a new thing description that is dynamically generated, so we want to clarify that out by dividing basically guidance and examples for for complex a hyper media driven controls.

F

Okay well I, think over time, but maybe we can have a Tears one. I can have some question.

A

Okay, thank you, Michael. Any quick questions. Comments reactions on this.

A

So here on the thinking, archie side, of course, we've been doing a long time. Basically, all the time was called racing with with the wave of things and we'll be continuing doing that. We have a lot of common interest when it comes to the interoperability, on the data on the hypermedia or security etc, and we are kind of looking at more research aspects here on the archie side and then seeing where it makes sense to do standardization on Doubletree, see, IETF side etc.

A

That's how it has been our pre-much mode of operation and I plan to continue continued working that way, also when the web of things is being recharter and you can see having a common activities on dande hackathons and when we see calls etc.

F

Yeah another thing in general, we are highly motivated to keep things converged here and to collaborate with people and making sure we avoid- and you know silly history, differences between things and I. Don't have been very nicely.

L

Hi Michael- this is Eve um comment on I, know: you're, there's a lot of discussion about kind of IOT, centric, convergence of things, all the different stos that are focusing specifically and I io t, but there's a lot of work inside of the ITF that could benefit from discussions around directory services. And so can you share some of what you're thinking about dns and the resource directory? How that sort of a lines or not right.

F

So I think a lot of the existing directory services, elisany vitae index of links and the thing descriptions provide more complex. You know, graphs of metadata and so I think that a lot of the distance services you know are have like basically tag links and so I think we need to expand upon that.

F

There's actually a thing called a data hub in the core that gives you access to more more data and something we're looking at is combining resource directors links to to that warming boy doing generally, those just broadcasting metadata like this is a this is an insulin pump, because I wouldn't want necessarily everyone to know that I have an insulin pump. So I think that we need to think about.

F

You know what kind of agent types you want to support in public directories versus private directory behind authentication we are looking at you know: DNS SDA, DNS SRV are looking at DHCP we're looking at core Rd, but a lot of those really are best at linking to places where more detailed metadata can be provided. As far as directories, we have prototyped directory services that can do things like semantic query: a relevant standard. There is sparkle which allows you to do.

F

You know federated graph searches, that's quite expensive though, and we think that's only for most advanced use. Cases I think there's lots of other way to do. Queries that directly support keyword, search, template, based, search and so forth. One thing we are looking at for introductions are location-based search, I really want to know the set of services available in a certain area, and that's one thing that we're discussing around DNS right now: okay, obviously, a question before yeah.

M

Hi, this is Elliott again Mike we're acting a little bit to what you said and also to what Eve said. There's a ripeness issue here for some changes into the the overall internet architecture as I see it and we've started it sort of slowly in different places.

M

One of the places that work is being done, I think, is interesting. Work and you'll laugh. Perhaps it's in the DHCP working group.

M

What they've done is they have taken tht parameters and created a yang model for them now yang, isn't usually the sort of stuff that that w3c deals with, but the nice thing about Yang is that you can serialize it lets. You realize it in various ways, once you can serialize it in a way like JSON or XML. However, you want to serialize. It do other things with it too, like sign it encrypt it.

M

These are things that are useful if for privacy, for vert preserving technologies, for instance, now, obviously you can't do that with every last DHCP object that we that we have defined if you're still in the ipv4 world. Perhaps your IP address is not something that you're going to serialize in this way. Maybe I, don't know it's worth we're thinking about.

M

I know, they've done a lot of work at categorizing, some of these things last couple weeks now that ties to the trust anchor discussion that I think we've been having quite a bit of, and we have other building blocks along those lines to leverage, one of which is est or element over secure transport, another which is EEP, believe it or not.

M

You could you can look at this in other context, the key point there is that if you want to gain parameters, if you want to exchange information about devices right now, we have very. We have a lot of challenges in establishing trust anchors, and so this is an area where the network infrastructure can play a role it's up to the day, and it also plays into another aspect that we're hearing a lot of in the industry, which is your trust, networking, the basis of which is.

M

You should declare yourself and allow for establishment of trust as a as a first class component, rather than trust being assumed and so I'm.

F

M

F

Co that I'm kind of a list of things to do for fun. Maybe you can unpack and answer a few, the questions and we can continue the discussion with the topic. Ok, so just about the yang versus whatever so one other work item I want to get off the table is: there's yang, there's seaboard, there's Jason, there's XML, there's various ways to transmit data on the wire and our encode metadata.

F

I would like to see it all in her vault interoperable and have a common data schema and a lot of people use an extension of JSON schema or various different extension to JSON schema I love to see that cleaned up. So we have one wave declare: data models for any serialization and things like yang to choice of civilization, of our information model, and we still have the information we want to export things in JSON. That's totally fine I think you know a lot of mud stuff is done around yang.

F

I would like to see that not weigh matter so much as it's just a structured information informations available regarding trust, anchors, I, completely agree. I think that you know we need to think less about on board to a system and onboarding, and thinking about you know establishing trust. What is the? What is the way we establish trust from devices, and so privacy is a lot about who do you trust, and we need to figure out ways to make that happen right? Okay,.

M

Maybe I'll stop there, because we, this is a pretty broad topic and it actually leads into the next topic.

O

I

A

So exactly I had the same thing in mind, so I think these links very nicely to our our next topic that we see in um so Mike Michael. Did you have any final conclusions? You will not share before we move on to the next. No.

F

I, don't say that we discussion with minds and I I think I get that alignment at some point to be on the same page, with margin teams as well.

A

Absolutely we should take that. You know, for example, one of the upcoming we she calls they could take a stab at that topic and see how we can find some more convergence, common tools, common ways to get get more. Interoperability I think that we very interesting topic. Let's take a note of that. Okay, okay, thank thank you, McCool and then off to our final topic. You saw something along these lines on the agenda. It's related to these discussions.

A

We have had over the past few months or so, and now we're basically talking about what they're all of these different activities we have around going on on IOT. How should we perhaps have where's the right for ahadees? What is the price structure and groups?

A

Should we have more site meetings, inter-school new working group, how we go forward on the systems and have a lot of discussions over the weekend, our IT director, etc, but now this out discussing at large, with IETF and hierarchy of community Anne, Elliot kindly volunteered to take a lead on this disgusting, okay.

M

M

Okay, so I'm Elliot I represent only myself in this discussion, I'm not trying to represent any iesg view or any other view, I'm, not a member of the isg I'm, not a charity. Bla bla bla, however I have him convening some side meetings and in one of those side meetings we had an area director show up and we've had some discussion on lists about a perennial topic at the IETF, which is how do we organize around IOT?

M

So this discussion is about that. So, as as nobody in this room will be surprised, we have a huge amount of work going on in IOT, not only in this organization but elsewhere. So, of course, we have this group I'm sure that these two gentlemen would would say that I mischaracterized the work in some way and in terms of TT TRG, it's a very broad activity, which is great by the way. That's it's fun to participate here and and I particularly enjoyed participating.

M

In the workshop on last Friday, we have the IOT Directorate, which the iesg members have in particular Ignace described as a reactive component of our system to provide review of work that goes on at the I at the IETF. We have a great many working groups that tackle issues that that affect IOT. Sometimes it's a direct intention to go into IOT.

M

Sometimes it gets backed into an example of an area where I think really IOT got backed into particularly onboarding was anima I'm sure they didn't start out thinking that they were gonna, be an IOT onboarding discussion, but that's where they ended up and then, of course, there are the plethora of SD O's that are involved in the space and, as eve mentioned, there are a great many building blocks all around which we have I think perhaps a lack of guidance at this point. That is something that Ignace pointed out in his discussions on Monday.

M

So he proposed something and I'm going to do his proposal, some injustice, I'm sure and for that I apologize to him, but it the iesg, did have a meeting in which they discussed alternate methods to organize around work. The classic method that we have in the ITF is to have a working group, but working groups usually have deliverables and they're usually tightly constrained to to certain to two very specific charters for it to accomplish those those objectives.

M

This would be a little different. This would be more of a standing group that would focus on on a broader topic for purpose for slightly different purposes, one of which is to know, and perhaps the most important of, which is to focus on how we put all these different building blocks together.

M

How do we make them a useful system, and so the idea would be okay great. We have core over here the co-op over here we have cozy over here. There's the web of things, there's I Triple, E, 802, 2.1, AR, there's six tsch, there's other I Triple E groups there so DVA and and sip, and the next generation of sip. That is coming along in the industrial space.

M

I can mention a zillion of these things and spend the entire time doing so, but putting together putting them together as a system is something that we could spend some time doing, and the key here I think, is that it can't be proprietary to IETF work.

M

Other people are doing work and other people doing really good work, but we could also do a couple of other things. So so what does that lead? To means? Maybe we're delivering some informational documents in the form of architectures I have to say. The iesg in past has not been in favor of doing architectural documents, but here I think they feel differently. But that could be me projecting a little bit and Ignace could say more if you were here, but I think this is people who are in the room on Monday.

M

Please correct me: if you think I'm wrong, we could certainly spot some gaps in a and it overlaps. I. Think, at least my feel at the moment is that there are both an example of an overlap is the plethora of onboarding mechanisms that are developing at different levels. An example of a gap would be some amount of authorization models that tie to the tie the network level onboarding into the application space.

M

A good example of that is the discussion that we just had Mike just mentioned about how we do authorization of resource directories, for instance, and how and how you bind all the way through from an onboarding perspective, which was Eve's point in terms of showing the whole flow okay. So these are. This is one approach, but.

M

The people, at least on Monday, did not really take warm to it. I think there are a couple of issues that were raised, one of which was that this was an excessively broad area and the IETF has a let's just say, a sketchy track record for handling such a broad area, and it was a little vague and the work that we could clearly see before us related to network level onboarding.

M

Well, more of that was a little. The rest of it was a little fuzzy, but so so one approach, so one approach that we could do is we could go into onboarding. So let me talk a little bit about what we did in onboarding this week and and that can give you a feel for alternatives even to having a working group.

M

So the IETF, you have a working group if you're lucky you meet for an hour or two during a week where you've flown a great distance to be here, we met the onboarding group that we had had sightings that met three times this week.

M

People essentially sacrificing sleep time, especially after the social to come, join us, and we actually have a very particular problem that we were focused on, which is the the plethora of approaches and the way I put. It is that if we can get some consolidation of approaches, maybe we can get some acceleration of implementation.

M

So we were. We were talking a lot about the COS inches in COS outers of this process for those people who are not familiar with that phrase, and there were some in the previous session that I have because inches meaning inputs into the into the process of the network process of onboarding and the goes out is meaning the weight weight.

M

You get out of that process, an example of which being DPP, which I'll discuss in a second and then we wanted to go through great many use cases to see if we could validate against a very small against one particular architecture, so fewest possible inputs. Views possible outputs, common components where possible.

M

Common components also means that probably we need four and consolidation means that people need to be able to take ideas off the table and that's hard, especially when there are a lot of vendors involved. The typical way that happens is somebody says we have too many ideas we need to take. We need to take some off the table. You take yours off the table, so we Cisco and I, and a couple of others have been looking at anima and bootstrapping remote key infrastructure.

M

One of the things we've been looking at is whether we can take that one off the table in favour of other mechanisms, but that that requires careful use case analysis and we spent a fair amount of time this week. Talking about that, we spent a lot of times walking about DPP. This is device provisioning protocol from the Wi-Fi Alliance.

M

The common input here is a public/private key pair. This is a nice architectural component because it's quite common already, if we look at Intel's SDO the secure device on boards mechanisms, one of the outputs of that mechanism is a public/private key pair, annie, annie dcs, a public/private keep here. Well that can feed right into a network level onboarding process here, that's nice, that's something we observed. The same might be true with with with some of the ocf processes, but I'm, not a I'm, not 100% clear on that. So that's an input.

M

The input could come in the form of say that SDO output or it could come in form of a QR code or it could come in the form of some other import mechanism.

M

The output is something that is also is interesting, and it has a couple of architectural implications, the first of which is a question which is who gets to decide what sort of authentication is used for network and what sort of a thing altercation is needed. I think there are a fair number of networks out there that use private shared keys as a means to use Wireless either that is in the form of sae or as an inform of it, couldn't be in the form of just a PS k.

M

That is an input to another process or in DPP's case they have this other concept of a connector DPP. What it really delivers, as the output is what what Dan harkens would call a profile and the profile can contain these various options, including the potential potentially for a certificate.

M

Another nice feature about DPP is that has a label standard associated with it? That's something that we don't want to have too many of. Otherwise, the manufacturers will just throw up their hands and we'll be right back where we started from a fragmentation standpoint, and so that's one reason to take other mechanisms off the table. Is that this here we have a labeling standard, so we looked a little bit then a teep here at the ietf, a nice linkage between DPP and teep, is so for those people don't know. Teep is an EP.

M

It has some nice features in that it has tlvs to handle a pkcs7 pkcs 10a transaction. So you can get certificates. You can reprovision certificates using tea. If you do this at the l2 layer, you don't have to worry about your interface. Having been up.

M

If you look at a lot of the onboarding mechanisms that have been defined in other fora, usually there are a bit higher layer, and so they assume, for instance, that you're able to communicate using HTTP or KO app when in fact you might not even have been assigned an IP address, because the network will not have authorized you yet for that purpose.

M

So teep allows for lockstep, often occations server, driven authentication, meaning if you need a certificate, if they're off, if the local deployment needs for you to have a certificate, you can say I need you to have a certificate. Please request one.

M

So that's a nice feature and it can say things like I need you to reprovision your new certificate, and why would you do that? It's because perhaps, for instance, the trust anchor has changed and you want to roll the certificates onto a new trust anchor right. So there's some nice features critique now. The question is: how do you link TPP to teep, and we spent three days worth of time talking a lot about that.

M

If the output of the DPP process is, for instance, a PSK, could you then link, for instance, that PSK using TLS PSK? The other side of this also is that we wanted to cover why wired onboarding? We have been going back and forth quite a bit on that and we haven't yet really landed on how how that should work.

M

But what that shows is that we have quite a number of calls still to have I see that Ignis is walked in through room, so I'm gonna give Ignace an opportunity to talk in a little while to say, because and I'll, just back up and review in a few moments on that. So we we have a list of questions that I think we've we focused around on this, which was how do we read provision what to do for Wired what sort of credentials be supported and this basically review.

M

So the next steps that we came out of today is that we know we need to write an architecture document. We know we need to sort wired. We have to handle manufacturer certs in this process, because one of the things we want to be able to do is detect counterfeit gear. This something that brewski handles quite well. It's it's right in the in the wheelhouse of brewski, in fact how to link PSK output of DPP to the next step.

M

If that's t p-- or something else, that's actually it's not a hundred percent nailed down, but it's close and we think that the profile mechanism that DPP has well that would lead to that. There's also another mechanism that was defined in a draft called eat. Mek which looks like it can. It can actually be further merged into tea, and so there's some nice things there. So what does this mean about an IT working group? So in a Monday meeting I think people were very interested in focusing on IOT onboarding.

M

So is that a starting point, or is that something that we should just create a working group on that just sort of zooms in on that topic? I think I heard from people in this room earlier that really we have other things to talk about beyond just the network level. Onboarding they're great many.

M

This is a very large elephant and they're great many places to touch it, and so there are probably other aspects that we can that we can develop. So maybe it is really a starting point. An authorization in the resource directory is another area. Think that's that's worthwhile and what I just mentioned previously at the microphone about how we authorize how we provide secured information about the network and without the device in a way that each side knows who the other is for for sharing information in a way that's more confidential than it is today.

M

It's also something that we could explore in that aspect, but it also leads to overlap with this group, for instance, as to what's research. What is what is explanation of the existing capabilities and how do we drive and I? Think one of the things that Ignis it was it'd be useful to have a place where we could drive work into other groups, such as? How do we take the output of DHCP working group and use that say in a serialization, and so that would be a good topic for such a group. I.

M

Think and of course, this needs to track across SD O's and the reason it needs to track across the studios is because not all the good work is going on here, it's going on elsewhere, and we want to leverage that work in as much as we can. There are certain limitations in doing so with that before we we have an open microphone discussion, I thought Ignace, you might want to say a few additional words.

N

Donna's right so apologists that I was not here at the very beginning of the session. I was not aware what you promised to the group that I will do I.

M

Said you go ahead and create this thing and there'd be no further discussion. You just pop up in the each other next year, right.

N

If maybe you want to put that that slide that we discussed Monday morning at the side meeting just as a context or did you did you go through that.

M

I didn't go through that exact slide, but I talked through it all.

N

Right so a very brief summary. None of the thinking there's a lot of activity of the individual work happening on a components that are relevant to the IOT in way. One or the other way doesn't appear to be the place that works on combining those components together. That's one gathering the requirements and explaining to the external entities, be it as do so, the user groups or or in general users of these technologies setting is, if we look from outside of the IETF. Is it really evident that the idea works on IOT idea of work?

N

It's evident that the idea works on multiple components, but does that work, or does it work on IOT systems or or solutions as such, whether it needs to work on that or not it's still an open question and to what level so the working thinking about that is probably we need a structure which would work on coordination and then merging of the individual working groups, outputs into something broader, and this would include mostly taking the requirements for a broader scope, work slicing that into the pieces directing that to the individual working groups and coordinating that work.

N

Now, one specific work item that I hear a lot is about the IOT, onboarding and and the things related to that. So probably that's one of the specific focused working groups that needs to happen and the feeling that I hear from a community that there is interest there appear to be people who are willing to do that work. So probably it's simpler to answer now: the IOT coordination group- it's not so evident and I- think that's that those are the comments that I have.

P

Take Taylor so I have four comments on topics that been trying to save up and not interrupt, and so let's see, if I can keep them in my head, which you have to do with this group onboarding working group website and I in IOT Directorate. Those are the four topics I'm fronted. So if I forget one, hopefully somebody can write so on the onboarding topic. I am all in favor of having a working group.

P

The only concern that I would have that the working group charter or whatever would have to address- and this may have come up in your side being I was obviously there in the Monday meeting, but not in the other ones. Is that on your one slide, that said like too many solutions, market fragmented?

P

Can we consolidate and, of course, there's the classic xkcd nine to seven which comes up in that and as long as you can convince the community that xkcd 927 will apply that I think the working group is a great idea to have something that scoped to IOT onboarding and for those of you who don't know, that's the one that says: there's 14 competing standards. What do we do? Let's create a new one and surveys 15 competing standards right so I'm, all in favor of that. Thank you. Please can you?

P

Hopefully you can do something and find a justification. That's topic, 104, okay, uh external people. Do they actually know that the IETF does IOT? This is the website topic. If you go to the WWI ETF org right now, you'll see topics of interest in the header at the top. One of those topics of interest is IOT. You scroll down to the bottom of the page.

P

You see a great big thing, they're saying Internet of Things, and so hopefully anybody who actually goes to the website would never come away with an impression that we don't do IOT, because that's how the whole point of their and Greg has been running this thing about. How do we improve the website? And so you have ideas of that. There's an initiative there that doesn't require a working group to improve that visibility thanks to Greg, and anybody else involved in that, and please continue that. That's for the external visibility point.

P

Let's see this group, so some of the topics that you mentioned are some of the discussion from Monday that you were summarizing, giving an accurate summary of was. Do we need a group that has perhaps no constrained Charter and does more broad things, including gap analysis and coordination between stos I. Think the thing to think the research group is doing a great job of that, because, especially because there's so many people in this room that are working group chairs and editors and documents, I think we have a great group for that.

P

I don't know if we need to compete with this group, because if I didn't broke, don't fix it. I like what you're doing in this room. Please continue and then my last topic. What did I say: Oh internet area director it's some of the other coordination which is different categories. Other ones is the Directorate does have some of that role too, of doing stuff across working groups. That's the four things that I came up to say: I, don't know if I'll have more given the rest of the mic line, so I'll go away now.

N

P

Have both I was referring to the IOT Directorate, but yes, we have both. They have different roles, but for the Coordination across a working group chairs, because the internet, the IOT Directorate, not only coordinates across s Geo's like this group does, but the chairs come together and are put out all that they know about what other working groups are doing on a more regular basis, and so those calls are what monthly you get bi-weekly. Something like that that we have calls will report out. ah This is what LCF is doing.

P

This is what LMA is doing and so on. So some of that is going on right now within the Directorate of sharing information across stos, but that's primarily between the working group chairs. This group think the think research group is the one that does it across the global community. Just.

A

A quick comment: let me put for a while my IOT directorate-general hat on so yeah, what Dave said we have this coordination across the groups, and maybe was we have had so far in the directory- is that those calls have been closed? It's only for director members. Maybe one thing was we could do here is have that alignment reporting calls open for for everyone. That could be one way to go forwards. You already have this activity of reporting on the frequency of those calls. It's basically once before the IETF, usually after the deadline before diet.

A

If we have had this one call where we go through all the groups and basically that chairs report, what's the main things going on, what are things that require coordination? That could be one potential way to get more of that activity or widely available yeah.

M

Let me just add one comment about coordination within the IETF and in particular where, where I think this group probably separates out a little bit, and it could be that we just want to evolve this group into into something slightly a little bit more bound to the IETF actually, which is that we have had numerous instances, I think, particularly with onboarding but I'm sure it's happened elsewhere to where different mechanisms respond in different working groups very early on director.

M

It never saw didn't see it until much very late in the game, for instance, and having a way to spot those things earlier to provide for common architecture earlier. It probably would have helped I think prevent some fragmentation. So I just add that, as comment, I think Mohit. Your next.

I

Might so I have been around IETF now for four and a half years, I've been attending all the meetings, and this is my view of thing. So, if I go to a boss, people are all excited. There is hundred people in the room and yeah hum.

I

If you want to form this working group, the working group gets formed excellent, but when it comes down to doing the things I don't see anyone like there's only maybe two people driving the things no people reviewing and and and Elliott and I have been involved in writing the blog post that that Steve writes and we have trouble getting even people to write texts for the blog.

I

Like am I living in in in some fantasy land, where we there's like a lot of people excited, but nobody sticks around to do the things so so we have experience of this on several occasions. Wherever people don't show up to do things, I mean look at t2 TRG.

I

There is plenty of time to present new things, but who are writing the drafts and bringing it to rooty tooty RG, coop right I think this provides an excellent opportunity to get feedback from from a diverse set of people, but who is making the effort to do that so before we go around forming new working groups, whether their coordination groups or new working groups on onboarding?

I

Why don't we bring those things here and try to like get feedback here and see like if, if this is not sufficient, maybe then forming a working group might help I had a couple of more things and then you.

M

I

Let me finish and then then you can address all my common comments together. I, don't.

M

Want to do that Mohit, because I won't be able to keep them in my head. Well,.

I

I have note so III you.

M

I

M

So just stop for a second, and the only comment I wanted to say was for IOT arm boarding. We've had three meetings this week with I'd, say: 20 25 people in the room for each of the meetings, so we have probably I think we're seeing a pretty consistent interest and it's not the goal there. I, don't think, is to come up with a new standard right. It's maybe a little bit here and there, but mostly to leverage the existing standard. So in that case, I think we have enough interest to move forward.

M

All right go on with your next column.

I

Disappointing anyways, so we had the idea of building blocks right and we let people to choose that. Maybe we want to change I'm, not saying we should always. This is something that's written in stone and we should never like try out new things, but, like there is lake, the working group on lightweight key exchange, there is compact TLS, there is IPSec, there is TLS, we have so many security protocols, we don't go and tell VPN providers to use IPSec and not use TLS or or one or the other.

I

We let them make the decision for them. So what I'm afraid also here is that if you start doing system architectural components documents, we are making the decisions for people where, as we should, let them make the decisions for themselves so that that's another point, I I think I wanted to make I took notes as well. So let me.

A

Okay, if you can be brief, we have only five minutes session left sure.

I

Yeah, maybe I will conclude by saying bring the documents to t2 TRG, whether we want to have a focus working group on onboarding or whether we want to have more general, broader thing on IOT and on systems. I'm not saying no to it. I just think like there's plenty of time in t2 trt to do a slow start here. I'll just point out that there.

M

Isn't cuz we're just about out of time was.

H

It not mark I mean I, think that on the EIU T, Network, onboarding and I said Network onboarding, because I think that's been the focus of the work today right. That sounds like engineering and something that you know people can put together in a focus working group. There is a question about when you talk about onboarding in more general right. What resources do I get access to? Who does this device actually belong to? Does it belong to Eric?

H

Does it get access to the video camera at the door, the thermostat, whatever in the house that might be a bit more research here, I, don't actually know right. We've.

M

Done some of that with mud, right yeah.

H

So we've already have all ready produced a standard there, but but but it's not the manufacturer that decides who can access my my camera at my front door right, that's me, but how does the device belong to me? Well, I can come up with schemes, but it's not obvious that there's one answer and it could be different for different domains as well. Different use cases right so maybe figuring out where the boundary is, is a useful thing, but starting with the network, onboarding I, don't know about the sort of general inbound.

H

Let's have a place in the IDF to discuss IOT as a working group is that you have. You have to have some motivational factor to have people show up and actually try to do something, even if that's writing some documents that describe what they think is the shape of the dot part of the world right. There has to be some motivation that that drives focus in there and I. Think is I I t's way too broad for that, but but also thanks.

Q

Michael Richardson here um so I mostly agree with Mohit. We should, we should probably make use more use of t2. Trg I would particularly like to know the Friday schedule, pre meeting schedule at least four months in advance, so that I can adjust my other Friday pre meeting scheduled people around would have been there. I would have tried harder to be there last week and I known more than it three days in advance, but so I think we actually need that big long time, as Elliott said we're running at a time.

Q

Right now, I actually think is very little value in having the t2 TRG meeting this one here now. I think that that it needs the the whole date to discuss.

Q

The second thing is that I think that t2 TRG has has been focused on particularly like wish she typed things like McCool's and and caustics presentations earlier and while I find them fascinating, I, not a participant in that I think we need to branch into other, bigger things and I think it's the way to do it, but I wanted to respond specifically to the systems question the IETF does do systems architecture, we have routers on the internet, they're stupid and we have we thought they were and we have endpoints and that's a systems.

Q

Things and the internet doesn't operate without the fact that there are routers on the that move layer, three packets around and the problem we have in all of the onboarding system proposals and the pushback we get as Eric just alluded to. How do I onboard what on board two?

Q

We have not described a system architect that says that a network owner, including a homeowner, will have a thing that you ought that on boards devices, that's a system level decision that and we're getting pushback on that, even in the enterprise space Elliott, it's hard to convince them. That they need to have a registrar or an AAA server or whatever it's like. How can I get around without that?

Q

Please redesign your protocol, so you don't need one of those right, and so we need to have us, and other groups are looking to us to describe an architecture for how that works. That's a system level description, and once we say that there will be a few where you join things together, we can argue both the engineering question of whether it's radius or diameter, or our brewski or this or that or maybe it's all of the above right.

Q

Getting the system to to host that installed is the hard part teaching it to prote learning new protocols is probably relatively.

M

Easy that I'm just gonna comment on one thing: that's that somewhat pedestrian I suppose in response to Eric and Mohit as part of this Michael, which is anytime, you want to form a new working group. Thank you any forum. There should be a couple of drafts flow. You know at least one draft floating around, probably a couple of drafts floating around, and so what just to give you an idea?

M

One of the actions we took out of the all the the meetings that we had this week, so we do need an architecture draft for for how these things can fit together. Well, he that doesn't mean that that is the only way things can fit together, but that it is at least one way that makes that that is sane. So with that.

R

Okay through comments, the one on the say, architecture idea and the other one on the t2 t, RG so I think there is a say, interesting balance between having in a systems, view and say doing all the say, architectures with vacation or a stem. That's watch activities that you mentioned in the beginning. So, although components that you mentioned I mean these are not really compliment, Henry a complementary components. This is a bag of things that you know.

R

You could pick one of the other and combine them in in different ways, and so as I may be. Example, if I'm and like I'm, say different technology field, I mean there is, there is certainly there's there are things going on outside the my ATF, as you mentioned, and so what other said groups do quite often is that they built something like reference implementation, reference architectures, quite often in what used to be called forums or these times open-source projects.

R

So that I mean, of course they are quite many already, but that could be another idea, so I'm not convinced that the IETF should really survey all those things and try to put em up as proposed architectures I think the idea would be really good in well enabling say group of companies or institutions to work on really specific things and they don't even have to fit together as well. Everything will be doing the idea of has to fit together into into one system, so that's I think not really necessary.

R

The other thing is I, think youth energy. So there seems to be some utility, and so this you know a little updating what's going on in in the different groups. On the other hand, I mean this is the IRT F. We shouldn't forget that I mean is also place for for research. So I'm not sure it's a good idea to so develop this group further to a coordination or serving activity.

I

Mohit we are already over time, so I won't make any long comments. I was reading through my notes and I got distracted because Jaime sent me a telegram. I agree with you on the lack of participation, 100% I think one final comment: we have bigger problems to solve before we go around making onboarding working group. Can somebody tell me the difference between onboarding or brueski cause a Brutes who trapping remote key infrastructure, or you mentioned EPP, which is device provisioning protocol?

I

So what's the difference between provisioning, onboarding, bootstrapping configuration initialization I think once we have that sorted out, maybe we can actually move on to onboarding.

M

Okay, I think you just subscribe for things which are roughly speaking the synonymous and that we've had that discussion, though we haven't documented it.

M

So I, don't think it's bigger I just think we we know we have a particular problem in network level onboarding, which is that we have fragmentation which is leading to confusion, the market which is leading to slow roll deployments or no deployments at all, and so that's something that we have a real problem that that's the big for me at least that's the high order bit, which is that we're slowing ourselves down and that systems level of you might actually help that this having been said, I want to thank people for their time.

M

Ignace I think you've heard the feedback here. I think it's probably worthwhile to talk about where we want to talk about this next and what what our next steps are.

N

So one thing it has worked on us. One thing that I will notice is I. I RTF group meeting here so I think I'm here on on the rights of a tourist, but what I hear from the feedback on those two topics, IOT embodying working group I think it's much more clear that clear of what to do next with that now the IOT systems think it's it's much higher of the contention and and not that obvious, at least for me at this point in time.

N

The comment about the documents and explaining the mapping between those and basically how those different things are, the this different names for the same thing and how I think that's a valid one, and maybe the proponents could try to address that basically trying to describe their view of how these things differ, work together and what is the relevance between them? Okay,.

A

Thank you guys, unfortunately running horribly over time, so we have to cut it this time. But let's, let's continue the discussion here on the remaining days and on the list and on I think clear. There's something interesting things to be done: we're very happy to host art of these discussions in the RG. One quick comment on that: we usually tend to have a lot of time on the agenda until like week before the meeting.

A

So if you are a bit ahead, send us a request that okay, here set of topics we'd like to discuss user we're able to accommodate that both goes for the Friday meetings and also for the summer in meetings. So but then, of course, if you want to go standards, documents, etc, then it's gonna need to be a different kind of group, but but with that, thank you.

A

Everyone for joining today are looking forward to see you again later on on our online meetings or our future face-to-face meetings and if you haven't signed the blue seats, yet please do so. We have them here in the front. Thank you and see you next time.

D