Internet Engineering Task Force 105, 23 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF105-CORE-20190723-1710

Description

CORE meeting session at IETF105
2019/07/23 1710

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

A

B

Jabbers dry strikes.

A

Okay good evening welcome to the core meeting so I'm Kirsten Gorman- and this is not a very because we have a standing chair this time, Francesca what a Muni, no Francesca, Bellamy and.

A

The name isn't defined yet but might be Julia.

A

Okay, so this is an ITF meeting, note well and all agenda bashing. We have only one hour today, so we took.

A

Short items and we have two hours on Thursday, and this is where we will do the complicated stuff. So today this is the call applications, resource directory pops up binding and the Cochran cluster.

A

The the yank cluster and Thursday is Oscar related work and multi class related work, and maybe an update of the group comb document a bit of cinema revisit of the phaser congestion control proposal, and then we even might have some time if we don't spend it early any comments on the agenda. Oh sorry, this is not the final agenda here. I wasn't able to upload slide, so Fraser is moving a little bit to the beginning, because there is something happening in TS v, WG that it was to go to good anything else.

A

We need to change in the agenda. Okay, this slide is not complete.

A

We had two hours nearly two hours of side meeting already in this lot preceding this lot, so we discussed mostly core applications and a little bit of hyper media. So some of the changes are in the slides already and tomorrow morning there will be a side meeting of the things you think research, group and I'm sure we can find out when that starts, I think H, 30 and yeah. What what else should I be pointing to anything else? That's interesting for this group.

A

That's this one: okay, so working group document status, we actually published our of cat6 13 a couple of weeks ago, so you can all congratulate Francesca.

A

This may have been the hardest document to finish in this group. We have other documents in isg processing right now that there is one with a discuss that we hope to clear this a week and two we just submitted to the is G. So these are going through ad review and we might either get them back, get them forwarded next week or so, and we have three documents that are in last call processing, stateless I think we still need a revised ID. Is that am I correct in that I can request tagged.

A

We need a revised ID after the working class car and compliment. We have a revised ID, but I haven't heard anything from the people who had comments so I think before we push the button on. That would be good to have some some feedback from the people who had comments and I.

A

Can hear you that the the speakers put in in a way that they are NT faced, speak about any of these documents? Okay,.

C

So I I started my review. I finished the edge I just need to write it down. Basically, two comments on. It is if there are two minor problems in the media type registration template one is the encoding field, actually is supposed to be a selection of one for choices in my instead. So let's talk about other encodings, but not it doesn't have to talk about in the same level details. The other thing missing is the ending of fragment identifier as per plus Jason, all plus he wore suffixes I think other than them.

C

You know they're fairly, simple,.

A

C

What what we learned from.

A

This is that those documents that do media type registrations probably need a special review within the working of to make sure they are really good when they leave the group I think we know how to do that, but apparently.

C

Requests and I save the message through to them anyway, so.

C

The directory the document takes a bit more effort all right down. My comments, I think it's mostly fine.

C

My general comment is that some bits are slightly under specified like secure discovery things and it's not always clear where the references are through the informative, but that you know maybe cannot be there. The whole the informative reference should stays informative, but there might be a couple of cases where I will question.

D

C

Thing, that's probably at this point.

A

Yeah, in any case, this slide is kind of we finally are moving through this move. It seems to to work so, given that we are shipping documents we actually now are making adoption calls and well this one here had a little accident. We had expired just when I was going to do a working last call, and so it will be resubmitted, and then we will do that, and these are adoption calls. So we had an option call on the two main Kuril documents.

A

We had pretty good response on that all positive it ends today, so you can still throw in your opinion. We had a call on the yang library and actually nobody responded to that, except for any payment who said this is the wrong approach. So later in the Cochran segment, we will have to discuss that and we made a an adoption call of Corrections and clarifications about 37 years ago and for some reason haven't closed that yet so I have to talk to my co-chair when you specter to find out where we are with that.

A

But if you still have an opinion on this, since it's still in limbo, you can still answer the GUP adoption call if you still find it on the mailing list.

A

Okay, that's about document said is any other questions about document status. Firstly, there are a number of documents. We are working on, I'm, not listing them.

A

So let's talk about Genesis tier.

E

Okay, I'm Peter filmstock I'm, going to tell you about our DD in SSD. The importance of the document has recently in being increased a little bit because, within the resource directory document, there was some reference. How you could discover the resource directory you've had discussions about it, groups that we have to have more experience with the resource directory to see how it can be discovered.

E

But one of the subjects there was how to discover it with DNS and the promise was to put that in the Rd dns SD draft the r DD an SSD draft that has some editions. First of all, where the Rd surface is exported to DNS that you can find it from the DNS, and certainly we have some examples where, especially, we put the st as called attribute s3 attribute on a parameter in to see how it is used, which defines the surface of the of the resource within the DNS.

E

So so the new parameter is st. It maps directly to the surface part in the dns SD surface instance, and it is pre specified so before in the door. After rd d + SSD, there was no automatic transformation from the resource type, which is defined within the core to the surface type, which was there to DNS. This has proved to be very unhappy and unlucky because of use of a character sets which were not completely equivalent.

E

So in Dowsett you have to define the SD attribute and register that in the end, appropriate transport protocol port registry. So that makes clarifies things a bit a lot, I must say and then come so it have conforms to the syntax which is defined. So I will try to get this to the example. If you can't actually define anything, just goes to the examples. So what we have is we have the Rd lookup rest.

E

You can ask for all the resources which actually should be exported, which is pensions, because the exp attribute is set in the link. So the request is here: does fortunately only one return which says that XP, which is there.

E

So it means it is one saying one of the resource which has what's needs to be exported to DNS, and it tells you the st which in this case is oh, I see the light and it should have been actually specified before and we have done the RT, the resource type, which is actually used by the resource directory for filtering. If you like, which there is also specified in the link- and it tells you what is the instance name, because within DNS you have the surface and you have the instance and domain so instance.

E

Surface domain specifies actually what you want to settle find out in the dns, and there are some other attributes which are resource directly. This specific, which is the sector and the end point. So what the idea is that, once that is defined in the resource directory like it, is here that you have an agents which goes through this data and then you're following the creates.

E

The DNS, the resource records and none of the ports would still have to be clarified more in the draft is how you find the DNS zone name, which actually corresponds with all the which devices which you find this which are registered in the resource directory. So in this case, what you see there is a surface defined and there is a pointer record which points to all the possible instances which you find for this possible surface.

E

So here there's only one instance, but you can easily imagine that you can have hundreds of instances which will make the search and be difficult.

E

So one has to be very careful about XV sated Lea, specifying both of service you want and what are the different instances of that all sink remains manageable, then got it says that the spot osg IFD light, which is this instance of this surface, has in-text record, and in that you can puts the different attributes which are not really known to DNS, but you want to actually inform to the PU people using the the devices using the the resource which had then put in the text records.

E

So in this case you will see that there is this sector is defined here and the resource type has been defined which are not known to DNS, but you can put in a txt record and then finally, then we come to the part which is important. We see that this instance mr. servers switches on the service name, which is fine example comb, which can then be fine with the host name and the host name, where you find it that it has that the IP address written finally can be found. Any comments on that.

E

Does it make sense to set, you can do it, but there is no no.

A

A

E

Have a problem because the server will not be able to actually determine what the service.

A

E

Think it's a double yeah yeah yeah.

A

E

Good trying to remark yes.

F

What the privacy implications of this so.

F

E

An account what.

G

Are the privacy implications how his authorization does information control can.

H

You also state your name, please.

E

So good remark: actually this is also true for the resource directory. You want to know if you put sinks into a source directory. How can this be authorized?

E

I want to point you to the authorization server which has been developed on by ace, and there are some hints both in the resource directory and also in the Rd draft- how this should be done, but how you want to actually do is specify the single subject of another raft. Yeah.

E

Other remarks yeah.

H

E

If you saying this is interesting, I all recommend that you read the DNS is the draft.

E

So then one of the things is that actually you want to export the resource directory also to the DNS, which makes it possible that from from DNS, you can find the resource directories in the domain that interests you, and that is slightly different, because in this case you have to do and have then you know the resource directory address. You can get and get and ask well-known core. What is the XP, which is there, which is there present?

E

And in this case we have two types of resources, which is the Artie bucco press and I do look up PP, which both serve to do the resource. Lookup and the endpoint will look up, and it tells you also, but you know it's the standard vector with the service type is etc. One of the things it is different because there, the resource record, gives you the complete the complete. You arrive that you want to look here. You only got the resource mentioned, so the agent is to be slightly different.

E

It has to get the the domain and the name and the and the scheme from this phone actually already well-known from the phone from the resource directory itself and not from the contents of the resource directory. So I think that is about oh yeah. Any of to answer your question. The instance here has been determined vary by the by the author authorization server. So whenever ask, may I actually can I be pull output to a DNS? Then? What's the authorization, certification, identifier, and that has we put them, yeah I- think that's it.

E

Oh yeah, one of the things which not clear yet or we still need some discussion- is how you actually specify the coop, which is the transport that you use or coop s, which may be different and, as you have seen in the other example, we have put it in the surface type in the service type such that you can use it there. We use the dots up there to distinguish, as we have to see how things will be used. If this adopts up can be removed later on yeah, you want to react to that Stewart.

E

No okay. So here's the same thing but then for the two ones worked out also for the for the food resource directory I.

A

A

E

This is the new I am NOT down, so if we still have to do how to derive the domain part from the inner surface within the phone, there are some drafts which already gives hints and how you could do it, but you think it may be good to spell it completely out here and so how to handle the transport Cobra coop s. That needs to be added to the servers in the DNS. So for the moment we have a solution, but I can understand that or some discussion yep.

E

You want to say something.

I

And I'm still treasure from Apple I can give you my advice on the two questions.

I

What we did in the discovery proxy code we've been working on, which is on the ITF, hackathon, github, page and open, is the default configuration if you just installed. The open wrt package is home, dot, Harper, okay, which is something you can use within your home. It's not global! You need, don't expect it to work between networks, but it gives you an out-of-the-box default. That does something reasonable.

I

You can then overwrite that manually, if you want a domain with global significance and I think the same thing would work here on the second point: if I'm understanding what you wrote there correctly you're talking about in the SRB rack or in transport protocol label, which is typically either TCP or UDP in.

E

This case it should be beaten so.

I

My advice there is I think if we could go back and do it again, we wouldn't do it that way. I think that was a mistake and the definition of SRV mm-hm, the the service name, doesn't have to encode the implementation, details and.

E

I

Have to say doc TLS if it uses TLS, it doesn't have to save dot utf-8 if it uses utf-8 X doesn't have to say doc I. Currently, if it uses floating point numbers, the service name is not in a description of the protocol. It is just a unique ID. Yes, if you look up in the table, if I could go back and do it again, I would get rid of the TCP UDP and I'll just call it underscore SRB yup fans, and then you read the RFC to find out what the detail is now.

E

And will stand.

I

Up given given where we are that established convention is that anything that runs at the TCP uses, others core TCP and anything else said on the school UDP. Yes, even it's actually not using UDP. It doesn't matter that just means other and it's just boilerplate text and don't think it has any particular okay.

E

Fine: okay, thanks very much.

E

That a teetotum end of this year is in reasonable timeline. I think maybe earlier depends on the discussions. We have ongoing, etc.

E

Yes, the Singapore seems to be a lovely time for lots of things.

J

Right, so what do I? Do you? Click here? Okay, so pub/sub. We recently just really recently on on a pre-meeting around the deadline, time and then over the last few days done a lot of work on pub/sub. I have a lot of slides. I'm gonna try to get through them in 15 minutes.

J

So if you, unless it's super, burning kind of hold off till the end, so what we're doing is addressing the remaining issues around topic handling and we tried to define you know, new response codes and a bunch of different things, and we kind of have a new design around topic handling that avoids a lot of those issues specifically how to handle empty topics, how to publish link format, documents that had name conflict, how to simplify and clarify life time and and while doing that, keeping it compatible with rest api's.

J

So what we're proposing is to create a topic configuration resource, that's separate from the topic data, so we'll use, create and delete on the configuration resource and publish and subscribe on the data resource.

J

This gives us a clear separation of the management of the topic from the transfer of data through the topic, and it gives us some more restful interaction model around topic, control than we had before with just links, also there's an opportunity to improve the security, because you may not have really this access control for managing topics that you do for publishing and subscribing through them and there's a proposal in the github repo that that describes it.

J

So the topic configuration is a Korell document, so we're beginning to include coral as that we had to pick a format. So coral is the the best one coming up, that's supported by ETF and in core apps. So that's that's what we decided to use, but also you can still use link format and the fact that we have an underlying coral document makes it easier to have some sensible defaults for just using link format to create topics.

J

So a topic creator, someone using pub/sub, has not need to know coral to use it in a simple fashion, but should use coral documents if they want to do more sophisticated control. So, basically, when you create a topic, you get a configuration resource and when you publish to a topic that creates a data resource, the topic is not discoverable and it's not subscribable until it's been created. So we're probably looking at actually returning 405 method, not allowed, which is I can't get I can I could put to it.

J

I can publish, but I can't do again, I can't or do it yet or observe and I can't subscribed yet alright and also then, when you create a topic, you have a way now with coral document to include content. So you can actually do your first publish at the same in the same operation as the creation.

J

The topic configuration resource contains topic metadata, such as location creation, time publish time, lifetimes, descriptions, content formats and the current topic state. The client can supply a hint for what it wants. The path to look like and the server could could do that, if it if it can and also representations for first publish and representations for tombstone, which is sort of a way of sending a special representation that says that the data are no longer valid.

J

Of course, that's content format specific, so there's a limited amount that we can normally specify in our document about that. More about that later, though, creating attack topic involves submitting a Korell document to an entry point in the rest api. You can accept a Korell document back that returns this stuff. That was on the previous slide, along with the location in the header. So it's typical rest pattern. You to create you get a location back.

J

Here's where you can find the thing that was created, we're going to return a document in the payload also on creation that contains some of that metadata as well, and the submitted document may, as I mentioned earlier, may, contain a link or embedded content for the first publish optionally.

J

You can just submit a link format document to create a path and there will be sorry to create a topic and there will be some sensible defaults, and then you get a link format document back that contains a link to it's a data resource that then you can publish to.

J

Discovering topics you can ask for coral or link format. If you ask for coral you'll going to get the metadata, if you ask for a link format, you're just going to get pointers, yeah topics are only discoverable after they've been published, but that has their they're really only subscribable. There's there's going to be a way for a publisher to publish.

J

We need to provide that so topic. Discovery has some built-in filters like the stuff we define in RFC, 66, 90, RTI F things like that. If you want to do more, you can use fetch and coral, and so you can provide the fields that you want to filter on in a coral document and use fetch and then filter that way so discovery you can use both quarrel or link fat format documents, thereby, and the results of discovery contains a list of links or configurate configuration represent representations, configuration resource representations.

J

If you want chloral, we've simplified the lifetime handling, because we don't have to try to fit it into query parameters or anything like that. Now we can just have them to be fields in the Kuril document and, of course, they'll be reasonable defaults for those. If you don't use coral, also, if you're going to use data lifetime, so so basically data lifetimes probably will require a tombstone document or some kind of representation to send out.

J

Otherwise there isn't really a good way, but then we thought maybe 405 might be a way to to indicate the data lifetime has expired to clients, as well saying you know, method not allowed so you're, observing and you're getting responses back and then then data times out, you might get a 405 saying. You can't really observe any more, because the data are stale same thing with the GATT. It might end up being 405 the topic timeout.

J

If the topic times out and you haven't published it a refresh yet in a certain amount of time, then that would result in the 404.

J

The configuration management of topics I think we covered most of this already, but basically that the Korell document is how you manage topics you can get to look at the current state. You can patch to update individual fields and you can observe if you want to see when the topic state or configuration state changes.

J

Publish and subscribe work this pretty much the same way they do in the current draft. That is standard, crud semantics, which get input you publish or write, using put you read using, get and subscribe using observe, so a publisher subscriber doesn't need to have anything more than the basic co-op library to work with pubs up.

J

So um a couple of additional features were still sort of in InDesign on them, and that is a topic hierarchy we've announced about, can, can cut topics still be a hierarchy, kanya parent topics and child topics and yeah, probably yes, that what we would need to do would be to allow the topic to be an entry point for creating, and then that has some advantages in that.

J

If you've already set the configuration resource for the parent topic, the child topics could inherit that data and you could then sort of set up your broker using chloral, but have your topic? Creators just use, link format and use those defaults that you like deleting the parent topic, would of course delete all the subtopics and then, if you did a read on them or subscribe or subscribe, observe on the parent topic, you would get all those subtopics. Also.

J

The other idea. That's similar to this is an aggregation topic, and the idea is that if you have a bunch of topics already created, you can create a new topic that sort of works like a like the the parent topic, but it can have any any any other topics in it.

J

It's just a collection of topics, so it's sort of more like flat aggregation and then, if you did, the read the Kuril document would contain all of those representations of all of those things that you want to be aggregated in read, em and in notify and, of course, there's the idea there. That was notify. You could get all the data, even the ones that haven't changed, or maybe just the ones that have changed, and there seem to be some use cases for both those behaviors and we could pick one or make it configurable.

J

Anyway, these last two features are sort of under consideration and being designed. I think that's the last slide right. Where are we going and what are we doing so? What we want to do is kind of get rough consensus on this protocol now, so we can go ahead and proceed with the detail, design and updating the draft and we'll expect to have a couple of core interim meetings where we can discuss our revisions to the draft and drive it to our last call, because that people want to use this.

A

Thank you for everybody is to thinking about this. Well, the Russians movies.

F

K

L

Hi I I'm not sure, if not one.

E

Of the nice things, but in you duties and.

L

Topics don't really exist in the server they're, just they're. Just data structures take a consultant when that message comes in so you can create billions of topics. Of course, this really take up any resources, and it looks like the protocol is moving towards structure if they, where that might be impossible to do so. I was just wondering. You've considered that so.

J

J

I'm not sure what what will you say at first? What how is it that topics don't use any resources.

L

Because clients are typically subscribing with wildcards, so the server takes to set up wildcards, it's the it's, the set of all cards that exists as resources, not the topics so.

J

So we're considering some designs that did allow wildcards subscription in the in the fashion of mqtt, but I can say plus in the as a past segment. We don't have a design to propose for that, but it would be happy to collect requirements and then kind of like to have a little more discussion about what your you know. Use case is and what how you think we might might do it, maybe yeah yeah. We definitely want it to be scalable.

M

When you mentioned the two options, the hierarchy and will be flat, Lisp sort of idea- you didn't touch on the idea of lifecycle, containment or ownership. You did say that when you delete the parent topic, it deletes the children. But what about the flat list? Is that, like a view, we're deleting the view doesn't delete the members yeah.

J

That would that would probably yes.

M

J

That would be more like a view where you were. You don't expect to be able to delete everything like you would, with the hierarchy.

M

Those members, whereas the client it doesn't get to the final.

M

M

J

More like another topic creation, and so you would need to have topic creation rights on the broker and you would create a topic that then contained a link links to all of the subtopics that you wanted to aggregate.

J

You just mentioned about well what, if the lifetimes are in different places on different ones, what happens with the parent and.

M

J

Good good points right, that's why these features are in design and.

N

Those things like the flat lists could be could be extensions to the opposite broker and Nokia is a required feature there. So you could have popped the protis the supports on bottom right right.

J

Some of these things that not everything is going to be required.

E

Clarifying question: please: how do you see the relation is the work which goes on an ace for the public, the authorization of access to the program.

E

So do you think you talk to a very blue, classical means that also that's a draft testicle to be recouped Lesko? At the same time,.

J

So what are we creating a dependency on on ace where we're creating a dependency, probably on some of the choral stuff, but I'm not sure we're creating a dependency on ace.

J

But the correct solution will probably be ace four for this, because they're building the pattern that will will do this so.

A

Answer the question: how do you secure that in the document, so it suddenly would be good if we finish this together with the authorization scheme in ace, so probably the she has at some point. I.

E

Have two assistants from the draft seem to depend on each other? I would have expected that you also have to finish that the same thing you know.

G

J

Will be shorter, so we're also updating dine link and we had some similar issues with dine Lincoln questions. So we have some some similar small issue redesign that we've done pretty much. We were looking at the binding table operations and how to do the binding table and we've got a great suggestion from Christian on how to architect this. So this is what we're proposing.

J

There's. Also some question of how the observe attributes work when you have a use case that requires more data. Consistency across different.

J

Endpoints and we're probably not going to get too much in that discussion right now, but just aware that that's happening and we'll have that on the list. There's some ongoing discussion about maybe adding new attributes to satisfy those and there's a proposal in the in the repo. So basically, what we want to do is make the dining a resource instead of just a link and be a resource in a collection.

J

That's the binding table, collection of binding resources and the binding table has an entry point for creating resources like the present draft and again we're looking at using chloral to be able to do some things that are a little more sophisticated, but link format will still do the job and creating an entry in the binding table will return a location for the binding you created. The binding resource then basically has a set of links.

J

There's a source link destination link in a self link to the binding itself, just as shown here and then that the issue of what's a target attribute now is resolved because the target attributes in each link only refer to the target of that link that that's how we've got the the self link for the binding now is referring to the binding itself as the target attributes in the link referred to now the binding. So there's no ambiguity about whether the attributes refer to the source or destination or the link.

J

Right so the binding table, as I said, is a collection of binding resources. Has an entry point, returns the location and that's a little snippet of our API description that says you post to it in link format with this payload you get a created response with the location and that location then allows you to delete. If you have the coral, you can use that location to patch the binding and update it without deleting it and recreating it. Reading the binding table would return a list of links to the current bindings, so in link format.

J

That would basically just be some links, but in coral, maybe we could do some depth recursion on that and get maybe a way to return more of the information.

J

So you could do one read and inspect all of the bindings on the table: tour filter or whatever, but at least we can do this, the condition will observe a option is that different clients might have different starting conditions different, and so what what you could end up with is a different sequence of notification across the different clients, and sometimes that's okay, maybe sometimes it's not if I really expect them doing machine control or something like that, you may want to have some observe attributes that guarantee, or at least do the best under the constraints of coop, observe to deliver the same set of notifications to all of the observers.

J

So are some of the ideas were absolute, some absolute based things instead of the relative based things that we specify now and maybe some behavioral constraints that say when you notify one observer, you have to notify all of them or some set of them that that are sharing some notification regime. I see some confused looks but I try to summarize what the issue is and it's it has a few nuances.

J

So our roadmap here is to add the binding table.

J

Changes if we have consensus, if no one really objects spoke, will do those changes and then will will need to have some further discussion on this issue within conditional notification attributes and how we what we need to do with that, how we need to redesign them whether we need new attributes, whether we need to remove some of the current attributes, if we don't like them and that's and then you know, maybe reliable notification once we can to this machine control or whatever we might want to look at something like series transfer pattern to do, notifications and what we want to do is roll these.

J

In and again we review at the interim meetings- and you know, drive toward last call on this now. This is currently I believe in informational drafts. So there was some question also about whether it should be normative that right and Carsten is it information? Yes yeah some some people might want it to be. What do you call if it's not informational normative, or we have a word for s3? Sorry, oh no,.

O

J

Track: okay, yeah, so we may want to do what, since people are using it there's those attributes are being used in Oh now, for example,.

A

It's time for for general discussion which of these graphs actually standards in the traditional sense, which example.

O

Version that is.

O

Used instead of seats and something that was reported on the mailing list in connection to values that they're inside unions, this could cost some problems. If serious and that's why we in this specific case, we stated that names should be use in order to avoid this ambiguity and similarly for the unions of beats and again, we clarified how namespaces should be used. Inside instance, identifiers.

O

Yeah here should be fine, okay, so.

E

O

For the tech registry, we have a new tag that defines if someone wants to use sit directly instead of Delta. This is now possible and there is a sit tag for this and also the seat values before were not given. Now we have specific values for each seat, tag for each.

O

Terminology per tent: we are clarifying how date and deltas are used, and we will be sorry well making it a little bit less confusing for the examples where sometimes we have plus signs- and this is not exactly clear for some of the readers- how they should interpret this so we're resolving this and there's very small editorial changes.

O

So here we have a small example that seemed to be I mean the format seem to be causing some small confusion. Whether the interesting part is the one that is in flight cream. This is what is being specified in the given place, but in order for it to be properly interpreted, we need to give some context, and this is why we have the rest of the example. So if people find this confusing, please report it on the mailing list.

O

Otherwise, for us it's well explained, so we will keep it as it is, and so, okay, at the end, to ask whether it's okay for walking grouped Alaska and then for the yank Library draft.

O

It was in working group, adoption Co but as Carson said, and the Beermen had some uncertainty, whether it's the best way forward, as so, if you want maybe now we can you've got this so for us which it seemed that we are, we will be reducing significantly the size of the discovery for devices and especially in networks were there will be peer-to-peer communication. This could be rather important.

O

My understanding for the point that Andy's making is that this will happen only once and normally in the lifetime of a device, and that this s, maybe doesn't matter that much so maybe it's not worth as specifying the how to use again Clara with seats. So this is my understanding of they show. If anyone is opinion.

A

Different spin on the issue, we spend a lot of time to make the communication about yang efficient civil, so we can exchange again for the data efficiently.

A

However, occasionally we have to do introspection, so we kind of have a metal use of Yang and this introspection. We haven't optimized and, of course, here regularly. We could change yang zero to two also have an optimized introspection mechanism, but maybe it's just easier to say: okay, the kind of introspection we are going to do go on constrain. Senator is going to be a bit different anyway from what you would do on a large net current based router, or something like that. So maybe it's okay!

A

If we have our own young module for introspection, so that's essentially the the slight difference we have with Andy here. So fundamentally, there is nothing that we is speaking against using the standard introspection library, but we are going to get much larger discovery. Information from that then from this optimized may be. Any issue is kind of we wanted to use this in the whole spectrum of young usage and so for a tank.

A

It doesn't really make a big difference whether the introspection- don't you 200, oh okay, but for for temperature sensor- doesn't make a difference in particular, was fragmentation and all that, so that may be the explanation for the slight difference in view we have here.

A

So having said that, my partner, he was that we should go ahead with the working group adoption and we will be last calling these documents with a special CC to the net water in that country, working groups and I think we will collect additional input on on this from them during the working on grass court.

A

So we can still stop this if there are good arguments, why why this would destroy the young universe like that, then, of course we should I do this, but for me right now it seems this is the right way to do this and we have a.

A

P

Hello, can you hear me? Yes, yes,.

P

P

Device to be having to be implementing the standard, IETF yang, introspection module, which could be then fetched from a big server right or from a big client and then tiny implementations to use the core yang library. So in this way you know if you're a big server and then in any case you can use the standard library. And if you want very limited, very optimized version, then you can only go and get.

O

P

Also from this command, I think they're not incompatible, so I think it's the the so my personal opinion is to, of course, copy net, not- and you know dive a little bit more into this- how the two libraries coexist, but there is not no incompatibility between them and is I think that they can coexist very nice.

A

Thank you. We just point out that nobody send plus one.

A

O

I saw them for come, I came no big changes based on some reviews from the mailing list. We have changed some small things. One of the things is, we renamed commit to core confess it has been discussed.

O

Then we move I mean we used the ant models that are referenced from existing terraces instead of us redefining them in our appendix which sounded a better way of doing it. In some examples, and then there is some more information about how to do filtering and.

O

The seat definition of the young model was moved us said, oh so, for the seat draft outside of this draft.

A

O

The important parts are that we have done some clarifications on notifications, on the discovery and on the seat deltas, but otherwise some very minor readability improvements. Only editorial changes, nothing big has changed.

A

O

I think it will be available by tomorrow, but yeah no money tomorrow. It will be ready.

A

To review and then we can send.

A

Peter doesn't want us to do that.

E

It's quite a call to me, but maybe my couples to see me I'm very happy that the documents are far advanced. You were really looking forward to this publications. We want to use it as such. We have still worried. That's about the process of in disabilities are changed. It's not quite clear how the communication is yeah, that's going to help of enemy, have specific numbers, and you used to be known you test. Then it goes through our line and RFC bomb. So all the numbers changing.

O

So yeah for the changes, that's why we said that there could be pre a location, so I think that use cases could be handled. But if you want to can discuss this so fine and.

E

Standing by me asking for his ship those to be fixed, okay,.

D

Mike Richardson I think that the discussion I had with Michelle cotton yesterday and Benoit on the weekend suggests that all of them yang models that we depend upon may needs in values attached to them. So that's something that's going to have to happen. The SID files that we create. We believe that we need to pass them Ayanna. If you manage, we don't know how to do that. We passed game files Diana by putting them in our document and then the extractor is bizarre.

D

That's what we do should we do that with city files we don't know okay.

D

The second point is that there is a worried Benoit has that when we run came said, etc over the archive of all of the other modules that have already been approved, we may discover issue conflicts, something else and that it may be that we need to do that at some point, probably between last working group last call and iesg to convince the young people that everything is good, so I don't think we have a process for that, and I also know that we don't have our code up streamed into gang again, so that it will be, can trivially do this and again I contribute check it out right now.

D

So that's a mechanical thing that we need to just be aware of or need to work out, but with the exception I think we have to have text to explain to I, anna in I ana considerations and some agreement about. What's going to happen there. That's why a lot working group last call comment. Let's put it over here group black hole and that's how that happened, but we're gonna have to have a discussion with vienna about this. Okay.