Internet Engineering Task Force IETF 114, 25 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF114-NETCONF-20220725-1400

Description

NETCONF meeting session at IETF114
2022/07/25 1400

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

A

Okay, I just passed you the control.

B

Oh, that's true,.

C

So in the room we are seeing the slides, but with a dialogue in front.

B

B

Sorry is there.

D

Meat echo in chat here.

B

Should be right there, I don't see them yet.

B

E

F

Okay, it was highlighted.

B

Presentation views okay,.

B

It's all correct.

B

No just local speakers, no.

F

Let you try unsharing the slides and reassure them and see what happens.

F

Still there, though,.

B

Somebody has a pull up, so maybe we can try canceling the pole.

C

Just give us a couple of minutes to resolve this. There's a pole window, I believe open, which is causing to overlay on the slide deck.

B

See that's the one yeah.

F

Whatever you just did, what was what would you do.

G

Yeah I just killed the poll.

C

Okay, I think that fixed it.

C

So kent I'm going to pass the presentation ball back to you.

C

All right with those few glitches away, uh this is the net count working group um meeting in itf 114.

C

Next slide, please.

C

Okay, that's a note. Well, most of you are familiar with it. If you're not do take some time to go through it. Anything you speak or discuss in within the halls of this meeting are part of the itf contributions next slide, um so a couple of additions or changes, so we of course, have the meat echo session uh you're here.

C

You know that uh you should be logged into the meat echo session, whether in person like the version that you're probably running, if you're in the room or if you're remote, then you have a full version with the house icon.

C

The meet echo session will also act as a virtual blue sheet, so if you're logged in it will record you as an attendee to the session.

C

There is a chat window, I think, for the first time we are introducing zulip so uh monitor some of the chats on that session.

C

Jabber comments, of course, will be reflected within the zoolop session. We have a two-hour slot um and we have not a completely packed agenda, so we'll probably be a little flexible with time, but we'll try to use the timer if necessary,.

C

The queue will be managed by a meat echo, so whether you're in the room or remote do try to.

C

Line up in in the queue session before you speak so to queue up, use the icon with the hand symbol on the um and then to speak, make sure that you have hit the play button. This is for the remote audience and, of course, remember to remove yourself from the queue once you're done talking.

C

There is a note session, which I believe the agenda has been pre-loaded. We welcome your comments, our contributions to that notes. Page. So may please add that add your notes or your comments to that page.

C

You can right click to make it a separate window if need be.

C

Next slide, please.

C

All right, so the status of this charted workgroup items, the https node updraft and the shepherd has written up um on the document. Thanks microphone, the we publish dash 11 and they should be a dash 12 soon that we will publish that should address the comments we received in the shepherds. Write-Up.

C

The client-server suite of drafts, all the working group last comments issues were resolved and at this time the documents are ready for write-up, which is something we I'll be working on. We are, of course, looking for volunteers to help. In writing. There are a total of nine documents and if anyone is willing and wants to do a shepherd dried up, please do approach me.

C

The udp native draft is work in progress will be discussed in this meeting and so will the distributed node draft the adaptive subscription draft was adopted as an experimental draft, so it's been marked in as work in progress, but is not being discussed in this meeting next slide. Please all right uh so on the agenda under chartered items we have uh alex who's going to discuss both the udp and the distributed native draft, and then we have chin who who will talk about the newly adapt adopted this pagination terms?

C

Next slide, please under non-chartered items we have continuation of the discussion on the transaction id and will present that, and then we have a new draft in the form of net conformer, quick.

C

And, as that will be followed by sean turner, who will give an update on netconf over tls 1.3.

C

And for the remaining time we will have a discussion around netconf and rescon next.

C

So any questions concerns anything you want to raise at this point.

C

All right, nothing in the room and I don't see anyone in the queue. So maybe we can switch to the first slide deck.

B

C

H

H

Do you listen to me.

C

B

G

Thank you, hello,.

H

um Hello to everyone, uh this is alex juan from insalion and, on behalf of the authors, I'll be presenting a little update on the udp native draft. So next slide please on the agenda today, I will present a little context on on this draft. The two changes, the two draft we did to address the last itf comments and the plan changes for the upcoming versions of this draft.

H

So next slide, please um so udp notif is, um is a udp based transport protocol for young.

I

H

The notification message is outside of the scope of this draft and uh for that we propose a shim header to uh send uh information directly from the line card without impacting the router the performance of the router.

H

F

H

H

So this protocol is designed to be deployed on on secure networks, but for unsecured networks. A dtls layer is proposed on section 6.

H

Next slide, please.

H

And, on the last day, etf 113, we we received two comments from the working group chairs. uh Thank you very much for that.

H

The first one is that uh how can we configure this uh dtls layer for for this transport protocol and the second one that uh it should be? It would be better to add some examples of these configurations. uh Files for netconf next slide. Please uh to address that uh between the 5 and the 06 globally, we updated the biggest changes, the young model and the young module to address the first request.

H

So what we see here is that we added a new flag to enable the tls or disable it and then the dtls container, to set up the dtls layer parameters.

H

This dtls container imports actually the the tls client server draft grouping and right now we we do believe that we have everything we need to to configure it, but uh we're still waiting for the implementation to check uh to check that nexus light. Please.

H

Also, reviewing the the young module, we added, two missed features, one for dtls and one for segmentation.

H

We renamed also the the global grouping name to udp receiver grouping and made the port mandatory, since there is no default jana port anymore.

H

Next slide, please.

H

We did some rephrasing on the max segment size uh leaf uh to include the options octets on on this uh on this lift and then, lastly, the the flag uh for enabling the ttls layer and the container with the dtls parameters.

H

Next slide, this.

H

uh We had one last request.

H

That it is to update the shim header version to allow at the collector, uh receive different versions of udpnotif the one uh before it became a working group document and the current one. So we addressed that by updating it next slide. Please.

H

And then, uh since we haven't still checked on this yam module, we did not address yet the examples, but it's planned on our timeline to implement these examples and test it before put it on the draft um next slide, please so! Yes, that's it for the udp native and if you had any questions we the feedback is welcome.

H

Just go ahead and.

A

Yes, um on slide, eight, you showed enable dtls boolean flag and then immediately underneath it the container can for the details, configuration, I think uh better would be to put make the container be a presence container and remove the enable dtls boolean leaf.

H

So, okay, so putting the leaf inside the a dtls container. What you are asking right.

A

And no not not putting the leaf inside uh removing the leaf and instead making the container be a presence container. So you add a descendant of note called presence.

H

ah Okay: okay: okay, let's see okay bin.

C

J

Hello alex so I'm born with less so I was tweeting your slide about secure networks, and then I was reading your security consideration and just editorially. uh You could be adding a reference to an rfc that I like, which is about limited domains and internet protocols. This rfc 8799 I'll be sending an email. That explains why we need to make a distinction between something which is a control domain and something which is over the wild.

H

Okay, we will do that.

C

All right, uh just one more.

K

uh So rob wilson, cisco. So just a quick question on the version change. Could you just explain again why that's being done so when you want this to go to rfc is the intention that you ship it with version one or you go back to version zero, but I didn't quite.

H

Know what we would like is to the rfc version would be the last the last version on the draft. Actually so it's to to allow the collector to collect the others versions of this already implemented draft.

K

Okay, um so is this an I am managed registry for these version numbers how's that managed.

H

Right now, I believe it's only on on the draft. There is no jana on there, but.

K

So I think it would be helpful to add a section on a consideration section. There isn't one that says that that there'll be registry set up to manage those version numbers. If you said, if you can have a version, that's shipped or effectively deployed already that's reserved. I think that would be pretty quite helpful.

H

C

Okay, I guess we can move to distributed nordic.

H

Yeah so also on behalf of the authors, just a quick update on the last draft. They published the next slide, there's one only um so it hasn't any change on this draft. Actually- and there are some corrected needs on the last version and the authors. They believe that it is already really stable, but that since the only reference to this draft is udp native, they would like to wait for the udp native to be last core before thus calling this one, and that would be it.

L

C

um Speaking as a contributor did you get, and probably this applies more to your previous draft. Actually, so did you get a chance to discuss with sean turner on yeah the dtls container for udp notif.

H

um Not yet he and we will do that.

B

C

H

C

Okay, following that question would be considering that this is a security feature. I guess we need to send the draft for a sector review.

C

So could you let us know when the document is ready for a sector review.

H

Okay, I will do that.

C

All right, thanks alex.

C

M

Okay yeah good morning, everyone yeah.

I

M

Good morning this is chinwu. I want to talk about this pagination magazine for netcop and resconf, so here we have three relevant jobs has just been adopted. uh Actually the name we listed here at uh the also this job that we actually from the design team. So this is another thought that was in this job, so I just want to pay so.

C

M

Update what we are doing, what is this job about next.

M

So first motivation and goal: actually what we propose is this pagination mechanism, so traditional we use uh nano uh transitional user uh net net call for protocol like uh operation like uh get or get configured to do the data retriever, but when you're facing large amount of uh data retriever actually especially applied to the list or leave list for from server side, you may take a a long time to send this kind of data and when the interface between the, uh for example, net client and then not medical server, uh they have a bandwidth uh constraint or results concentrated.

M

So this kind of latency you feel by the client will be even worse. So from the client side. Actually they may need to consume more uh uh resource to uh to integrate this kind of data. So uh our idea is, you know, uh to borrow some concept from uh circu s statement when you use to query some database, so you can actually uh integrate the back-end system in in a server, so you can use some kind of index mechanism to faster locate the data. So this is the motivation for this worker.

M

Try to you know quickly to query or locate the data using index magazine next.

M

So we have three relevant charts. Actually, these three jobs actually related to each other. Actually, the first one is the list of pagination medicine, try to provide a generic mechanism, and this can provide you to do the filtering or to do the sorting and retriever actually is the most applied to this list or leave list, and we also provide the nanocop protocol extension and the rest com product extension.

M

So this the other two actually use the the first genetic mechanism as a basis. Next, so first I want to introduce this pagination mechanism drafter. So in this job, actually we uh define uh six query parameters so, as we uh you know uh clarified. Actually we tried to borrow concept from the circu statements that are used in the you know. Database query.

M

Actually, if we download select where these kind of semantics, actually we introduce similar schematics here, for example, where this you can see this as a selection filter, it can help you to filter the your interested result set and sort by. You can see this. Actually, it's kind of index node. Actually you can use this index node to quickly. You know locate the the uh results center set entries and also we have direction to give you. You know uh when you do the search or get it without the bank.

M

You need to know what is the order. It could be dissident order or accident order and offset. Actually it allow you not from the first entry. Actually, you can skip a several entry start from there and do the further query and limit. You will tell you uh how many entries you can return.

M

In addition, actually, we introduced separatist limit this kind of parameter. These are actually you know different from the limited parameters. Actually they only apply to child list or child leave list, so they can help you to return the number of entry in the child list or leave list. So we also, you know, provide a server processing order. The first you need to process aware and then you process sort by direction, offset and limit, and uh also we actually introduce metadata attribute and we call the remaining.

M

So the idea is, you know these remaining parameters will use we together with uh the limit or seven uh sublist limit. uh Actually, it will tell you when you do the query you uh you may need to know uh how many uh engines are left left in the result. Entry without set actually so remaining will tell you that this kind of information next so here we'll give the example uh as we uh present. Actually we have six current parameter.

M

We use a combination of these six parameters in a request response to guide how list and data list can be returned. Actually uh we have a job actually yeah this uh yeah, the job that you you can see the appendix they have uh um example module. So they will tell you the schema so in the left. Actually, in the request that we actually uh we have, we actually, uh you know, focus on specific list that we call the member, so the member is kind of is defined as the list, actually it under the members container.

M

So we use where to do the selection, filter and sort by. You can see this. uh You know as an index node, so member id is the index node. Actually, so we also set direction. Actually, it's kind of dissident order and uh offset uh so you, you know, start from the second entry and then you, uh uh the limit, will tell you you know from the second entry you'll get a. You know uh two two entries so start from second and s and three so this uh two entry.

M

So you can see this kind of example. Next,.

M

So uh for remaining, actually we as we have actually applied to the dissident list or leave list. So we give example to compare. You know when we use the remaining uh when you use a sublist limit or when you not use a sublist limit with a sublist limit setup onset. Actually, you can see. Actually you can return the whole results. Actually it will return the the the total uh entry inner result set, but uh when you set a sub limit uh parameter, for example, you set a submit parameter one.

M

Actually, you only return one entry, but they also tell you, for example, you the total. You have uh five entry and you return one entry. The remaining one is four entry, so it will so this remaining will tell you how many entries are left uh in the result set next.

M

uh We also define the server list pagination constructed discovery. This is the most actually only applied to the config force list or leave list, since the inter action with their content may be limited, so you can see. Actually we organ from the system capability module which has already the rfc and we introduced two parameters. One is concentrate the second index, the country that will tell you uh uh which uh config force node uh constraint, actually uh index.

M

Actually, uh you know, is uh uh used together with concentrate when you set a constraint and you can say well, it will tell you which node can be used in the where or solved by the expression. So here we give the example.

M

In addition for this uh uh construct discovery, actually we allow more uh extensibility for concentrated parameter, uh so you can add. uh Besides the concentrate and index two parameter, we can introduce some other parameters so give some example. For example, you may be not supported. 100 x pass 1.0 syntax, so you can add some other parameter here, yeah next, so second job is a net call product extension next, so in this job, actually we uh provided two extensions.

M

The first is we augment the three and net club rpc statements, uh state get and get config and get data, and also we align with the list pagination chart for query parameter. You can see all these query parameters actually has been put here actually to try to align with this paginating maximum job next, so we gave the example how it looked like when you use this pagination, then called protocol extension so similar to, uh like example, in this pagination magazine draft.

M

Actually, you use a combination of all query parameters in a request and a response, and you can uh you know to get the the the interesting entry you you really want to retrieve actually use this current parameter as some constraint or as some filter.

M

M

So second job is the rascon protocol extension next, so we introduce three protocol extensions. The first one is that we add a list and leave list as a valid resource target for get actually most of these, this pagination focus on. You know: uh data retriever, you know focus on reader information, but also we actually allow.

M

You know this can be applied to the delete operation so in the right way give example uh how to you know, uh to delete the whole entry uh in the list using the delete operation, the second we added new material type. We call the application that slash dash data plus xml list last we added six new parameters similar to the net code vertical exchange in draft.

M

That's all next, so here we give the status update of this job that we have three jobs. Actually, so we can see the history of this job, we started from last year november. Actually, in uh 100 herald, we presented these three jobs uh actually on behalf of the design team, and we uh actually introduced the motivation goal and also solution, and also we designed him discussed, found two open issue, and so we brought up for discussion and later on after ita 110.

M

We uh actually try to uh close these two open issues so raise the the discussion on the list. One is focus on cursor support, uh so this cursor related to the index uh and we come up with a solution. The second one is a remaining annotation.

M

This also gets discussed on the list and we come up with solution and we get some feedback from winning neptune from pbf and we actually reach agreement on the the change. What the solution looks like and uh uh also in uh february 10 uh in this year. Actually we confirm all the change actually and make sure we resolve these two open issue, so the chair actually uh uh helped to initiate the covert option for this work. So we got a quite a lot of review from andy chovang and.

M

And also, actually, there are two issues actually uh discussed. One is related to the edit operation extension. Actually, this is most you know applied to the delete operation, so whether this should be in the scope, so it would suggest actually say this can be addressed after working with uh adoption uh after working to adopt this job. The second one is uh uh really, you know we, uh the nanocop, actually has a lot of uh uh workload, actually client server. So this.

M

So what I'm suggesting is, uh you know, push it back a little bit for adoption and before moving forward and getting client server uh progress. Actually now, actually we see the client server job already. You know, uh adjust all the issues, and uh so we so this job get adopted. So that's our kernel status and uh we think that's all we have. We are very.

M

Actually, look for more comments and review on this worker to help her to improve this work and next so comments, questions.

N

Hello, my name is interesting and important work, but I have a few comments. One. It is not required currently that the server keeps a stable order of sorting between times so directly, every millisecond. You could change the order of your list.

N

You should address this. The second is that uh sorting is, in some cases very complicated. If you think about sorting alphabetically in some european languages, the o, with two dots, is after the simple o, sometimes it's after zed, or how do you sort the of a string where some of the names are chinese with chinese characters? Some of them are europeans.

N

The third is what how does this work if the expat filters resulted? Let's say two lists selected, not one single list, but two lists then yeah. How does that work? Thank you.

M

Yeah good comments actually yeah, I think yeah. We will uh try to come up with a solution here. I think this is a very good uh comments. Actually, we have the base base work actually, but uh the the use case you raised. Actually you have two lists that is complicated. We need to figure out how to address this yeah yeah. Thank you for the comments.

C

So before john uh you come on this mike, I just want to a quick reminder: do contribute to the notes and the meeting page, especially if you're asking a question to help improve the notes, continue.

E

Thanks, I'm john o'brien. uh Thanks for doing this work, a couple of minor comments on the choice of keywords, I would suggest preferring uh keywords that are already going to be familiar to implementers and operators, specifically instead of sort by, I would suggest order by and for the direction I would suggest defaulting to ascending and descending, and I admit that I have mixed feelings about having alternate keywords that mean the same thing.

M

Yeah, thank you for raising comments. Actually, in the design team we actually back force to discuss the water termination terminology will be appropriate. Actually, we do use you know autobio before and also and for direction actually used as a dissident, but some uh design team member- actually, I remember remember correctly- is per actually he suggests we use some other terminology, but I think it's a good comment, so we will see how do you you know reach agreement on this. Thank.

C

K

uh Robertson, cisco is a contributor, um so one thing I want to understand is the sort of performance impacts of this, where you do like a filter and then a sort, and then you return a subset of the data.

K

Then, when you get a subsequent request, is the server going to maintain any state for that or will they have to effectively re refill to resort to get the next batch of um data to return, because certain had a large list that could be quite expensive to do that calculation? Many times, yeah.

M

K

Is that I don't know, I haven't, read the draft close enough to know that's a potential issue or not and again I don't really know the databases where their cursor mechanism, whether they affect their cursors, maintain that state to avoid that issue. But I don't know.

M

Yeah we are struggling whether we should define this as a stable, stable mechanism, so I think yeah. We can think about that and see whether we need to cover this kind of case uh how you address this uh yeah. Thank you.

F

Tall people jeff has um so balaj and rob have both hit two of the points that I've talked about, which is the stability of the stored orders, especially if you're using an offset. As you know, the next entry you know if the entries are constantly changing, that offset becomes meaningless. The second time you come around to your you know display this thing.

F

The usual workaround for this sort of problem is that you keep track of the last key displayed and as long as you have a stable sort order show me the entries that are after this, as my cursor is the thing that generically works in most mechanisms, so you may wish to consider that somewhat towards rob's point a way to maybe choose to think about. This is, rather than having the queries run over and over again, an option, not a mandatory one.

F

That you should consider is the ability to request a stable snapshot to be taken for the data in question. So and then you pass in some sort of identifier to resume a specific walk on a specific set of data. This way you can actually do the work once maybe save it to a file temporarily, and you can resume your snapshot within that file.

F

Now the problem that you have with that is sometimes the data set is so large or there's not enough persistent storage available to do this sort of thing, so it can't be a mandatory thing.

M

Yeah good comments. Yes, thank you we'll consider that.

O

C

Yeah, we don't have anybody else in the queue so continue. The discussion on the mailing list. Thank.

M

C

So with that, I think we can move to the non-chartered items.

C

All right go ahead. Yen.

P

Good morning,.

P

So we can flip to the next page, so I just wanted to give a brief update about this netcom transaction id work. That's been going on here.

P

Basically, there are two additions since last technical editions, one is about last modified transaction id mechanism, something that we used to have in the in the draft works before I published it that I removed in the end.

P

But now it's I've added it back because of popular demand, and also some integration with yang push so that uh yang pushed together with transaction db both become better, and I will go through those two points on slides a little bit, but we can go to the next slide first, so most of the work in the o2 rev of this document has been to clarify and extend the text to be more clear about the concepts here. So I made a few changes of terms.

P

I've added more clarification about the candidate data store. We have discussed or introduced better diagrams for the message flow and improved the examples. We've changed from itf interfaces to active access control as an example, because some people found itf interface to be confusing in this context, uh provided a more specific list about x paths to the places where these additional attributes can be found and can be added just to make it easier and clearer next slide, please.

P

So if you remember, I will just very briefly touch on what this transaction id is about.

P

uh It's let's say one of the problems that we're trying to solve here is that when the client is getting the configuration from the server, sometimes it wants to get the full configuration, but sometimes it only wants to know if things have changed or not, so it would be convenient if we don't have to get the config and get it again and see then try to compare and see. Is this the same now or has things changed somewhere and that could be done with the transaction id next slide?

P

Another problem, especially related to young push is that if a client is pushing something to a server that it's interested in and it might also be subscribing to young push notifications, it will hear updates of the same things. It's just sent there in.

I

P

Config, so it would be sort of echo and it would be nice to be able to cancel those day because we don't want to process and treat all these updates and there's also currently quite hard to know if you get, if I send an edit config to the server and get the yank push communication back, it's hard to know if this is indeed the same as I just sent, or if it is some other client that did something that resembles my change.

P

But it's not exactly the same thing so with the transaction id. This will help too next slide. Please, and the third thing is that it's sometimes important for clients to be able to make changes and be guaranteed that nothing else has changed in between since last time. It's of course possible to take a lock, but that is not very that's a cooperative in an environment where there are many clients that one client would take a lock for extended periods of time to prevent others from making changes is kind of not nice.

P

So we don't want to prevent others from making changes, but we want to know when other other clients are making changes and transaction id can help with that too.

I

Next slide, please.

P

So I would then dive. I mean this is a the overall high level description, but now I will dive down into the one detail, which is this last modifier transaction id mechanism to show how that compares to the previous etag solution. Next slide, please!

P

So here you can see on the left. Oh colors went away. That was pretty, but okay.

P

You can see here on the left. You have a particular particular get config message reply where you can see that last modified attributes are in there. If you look closely the colors went away now, so it's kind of hard to see, but it says txid, colon last modified and some date stamp on several places in this content.

P

uh So that is, and then you can compare on with the right side where you can see how it was in the previous uh over the other mechanisms, with the transaction ide tag, it's basically a similar attribute, txid colon etag with a sort of random string or identifying string of the change. So the only thing that is really the difference between txid last modified and txide tag is that now we have a time stamp instead of some other string, but other than that it looks much the same.

I

Next slide, please.

P

One detail, though, is that in rest, conf there is already a sort of last modified mechanism, but that rest conf, that is by rc8040 the rest conf specification itself has this built in already, but the timestamp format in there is based on the date and a time with. No, we just second one second resolution.

P

So in the proposal I wrote here, I reused the same format for rest conf, which is without fractional seconds.

P

That's uh that's nice in a way because it aligns well with the the rest of rest conf, but it's not so good, because it's quite conceivable that you can have more than one edit config change within the same second and then this becomes ambiguous.

P

So I'm on the fence here how we should do this, should we keep using this existing restconf date stamp format, or should we add fractional seconds in the document the drev2 document here now it is the same as in rest conf, but I'm not sure I'm not convinced that it's that's the best choice, I'm not sure.

P

Actually, I would like to ask the room we can do that after the presentation here. But what's your opinion about this? Should we keep this low resolution and be aligned with rest conf, or should we do it with a higher resolution just like we do for netconf here.

I

Next slide, please.

P

And the other detail I want to show now: is this integration with giant push just to show you very simply what that looks like it actually is quite simple. So next slide please so here colors went away. I don't know exactly what happened with them, but on the bottom, you can see on the left side here under push subscribe.

P

You see near the bottom itf netconf transaction id yp with etag, true, that is how a yang push user would enable transaction ids for young pushes for this particular subscription. So it's just a simple leave that is added to the subscription to to get this functionality and on the right side in the updates. You can see right around middle.

P

You can see yang patch patch id 0 edit, and then it says transaction id called an e tag and then it gives a particular name for this update, and that is how transaction ids would be integrated with yang push. So it's a very unintrusive small amount of additional data that goes in there to enables us to identify all the changes where they're coming from and that we already have this information in the client and so on.

P

That was basically all I had, but I'm happy to answer any questions or comments and in particular, if people have opinions about the resolutions and time stamps for the last modified thing. I'd be interested to hear.

C

K

Robertson, cisco's contributor, um so in terms of resolution, the timestamps one thing I wanted to understand is: if you have a fractional timestamp, are you expecting every request to have a unique value? So you you wanted to guarantee uniqueness on that. That's right!

K

P

A client that is asking for uh for for a transaction id would like to be able to compare that with previous ids. That it has. Is this the same or not, and with the one second resolution, there's potentially a risk that some things have changed, but it still has the same time stamp.

N

But erickson, I think, without some allowing that two transactions in the same second have the same transaction id according to the last modified. That's not acceptable. This makes this woman is unreliable, defeats, its purpose, so either you have to do something there. One is to have a detailed timestamp and.

O

N

The order of the transactions- that's also a nice feature.

P

Yes, but in the rest conf, I think some of this functionality is already defined by rfc 8040 like how you can retrieve information. That is new since a particular timestamp, and that is not something that this particular draft that I'm working on here can change. So I think, even if we yeah I'm not sure how useful this feature would be in rest, conf, if you need that's high resolution,.

E

John hi john o'brien university of pennsylvania, um I have some uh sort of poorly formed or incompletely formed um questions having to do with um kind of what I already know from you know: sequence numbers in dns which seem relevant to this use case and things like um boot time in snmp, which also seems relevant, especially when we're talking about using a time stamp to determine whether something has changed and the device for managing and the manager might not have good knowledge of uh whether the managed device has good time or whether the the time its idea of time has changed.

E

Since the last time we asked it are. Those considerations that you feel like are have been addressed by this draft.

P

Yes, the reason I did not include some sort of timestamp in the original version was concerns of this kind. I think time is a complicated concept, but I I.

D

P

Yeah I agreed to add it, but then I only define one operation on these timestamps and that's equality. There's no other operation that is valid.

E

C

A

um I'm so I'm thinking uh the timestamps are maybe it's okay to use second level resolution and for clients where it matters they shouldn't use less modified. Instead, they just use the etag um and that's that's what they do and also I mean keep in mind that we're I mean for things that are sub second resolution, we're talking about configuration database mostly, um you know the updates that you know the the optimistic locking. uh So it's both configuration and configuration changing at sub.

A

Second resolution can happen in some scenarios, but um it's probably uh not as common of a use case. So I think last modified has value for common use cases and for those extreme use cases they probably shouldn't use glass modified.

P

Yes, I tend to agree for for some use cases. It may be convenient to have a small and simple mechanism.

P

Rest conf is geared towards those kind of not not so complicated use cases in many in many environments, so maybe there it has the value, but I agree: e tags should be used when things are need to be strictly correct. All the time.

K

uh Robles and cisco, it's the other, any other thought just in terms of what john was mentioning is. Would it make sense to have like a logical, timestamp here so a counter rather than a timestamp, so something that's guaranteed to increment every time a configuration request comes in a sequence number or something that would then guarantee that these are unique and ordered. If that was helpful,.

P

uh We have the e-tag mechanism, which I think is a more robust and secure mechanism for doing this sort of thing and the the reason that we added timestamp is because in rest, conf, there is already in rc 80 40, there's, like half of this mechanism is already defined there. So we just added what was missing with the transaction timestamp. So then it becomes a complete mechanism, but I I agree that time may not be the best way of keeping track of when things have changed or not.

P

So I think, if you are concerned about keeping perfect track of this, you should use the e-tag mechanism instead, which is a mandatory opera, mandatory mechanism time stamp mechanism is only optional.

K

Okay, so it might be helpful if the draft was clear that the or the problems of doing the comparison of timestamps and and basically just give some advice as to what not to use them for and push especially towards the etag. If that's text isn't already in there.

P

Yeah I tried to specify quite clearly that the only operation that is valid on these timestamps is equal testing for equality. But maybe of course we can add more text about why that is, but.

C

Right um so I'm going to start a poll to say: um oh sorry, we have more.

L

Okay, hi uh charles eccles, cisco, sorry for the delay. I wanted to let the stuff on the timestamp thing uh finish, because I just had another question about um in the case of an uh two questions. Actually, the first one was the draft talks about. You know you send the the e-tag or whatever, and if, if there's been a relevant change, the server uh wouldn't return, you know would return some kind, some type of error um rather than or you know the server does something different if there's a relevant change or a change.

L

That's um of interest to the client or something like that that there was the wording like left some wiggle room, as opposed to saying if the e tags match you do this. If they don't match you do this, I was just wondering it was that just the way of describing it that left that wiggle room or is there actually more than two cases of match and not match.

I

P

It would be good if you could point out the section that was unclear to you, so I can make sure that it's clear but in essence, you're right. The only thing that we want to match here is the transaction ids or the payload that the client sends down, but it also is.

P

There is the case where there are, let's say a when condition that is changing, that that makes the server change the configuration in an area that is not related to the particular edit config request. I mean it's related to, but it's not part of the edit config request, and that is also included so that perhaps that is what I was trying to say. Okay,.

L

All right um and then the other thing was in case the the server can't um according to these new rules or the rules on this draft in case the server can't make the change. uh There could be a couple reasons. One could be that it was like a the change that was being made. Just uh really didn't make sense, so that data doesn't exist versus it's because of the e-tag, and um I didn't know if the error that the client would receive does it distinguish between those cases or do both cases.

L

Look the same to the client.

P

No there's a specific error message for that: it's you can you can find it in the in the document there it's defined exactly what it should look like.

L

Okay, great thanks.

C

Okay, if there are no more comments, uh jan I'm not sure, if you're actually asking for work group adoption at this time, I didn't see a slide.

P

I don't know how to do that, but if you think the time is wrapped, then uh please go ahead.

C

P

The time is right is what I want to say.

C

Okay, all right so uh having cleared the deck of a large number of documents from the working group. Maybe this would be a good time to ask the question: do you consider this work useful, and would you like to see this draft adopted as a work group.

F

C

So I'm going to start a poll and have you answer to that on meet echo.

C

Okay, so the trend seems to be fairly positive.

C

We will go ahead and send a formal notice on the mailing list to see if the workgroup wants to adopt. The document is about group item thanks, theon.

I

O

O

So I am okay and present for the authors, because they cannot attend the meeting next page.

O

So for lighter conf we already know so this is all the slides. I just thought so. Let the car already use uh somewhere for closer to the mic.

O

Leatherconf already used security uh transfer protocols such as a simple object, access protocol and the secure cell and the extensible to something so most of these secure transfer protocols is utv-based because of this there are some shortcomings.

O

For example, the head of nine blocking in the tcp, so these sword comments can be overcome if we use quick as a secure transport protocols.

O

So, in addition to overcome this shortcomings, the the quick as a secure transport protocol have also some other advantages.

O

For example, quick, quick, convection established is very quick and also quick, the they have uh authentication and the encryption for the header and the payload and and so on. So that's why we propose use quick as a transport secure protocol.

O

So here we just give some details about we about to use the quick as skill transfer protocols. So here we just talk about the connection management. First, we have a draft version identification.

O

So basically, this consists of a token such as noc, which is sort for net conf over quick and then plus some numbers number one versus number, two and so on.

O

When we want to set up a connection at first, we need a half of. We need negotiate the first numbers. So when both sides agreed or both sides support the common versions, then we can stop. We can continue so also.

O

Both sides should also consider the transport protocol. Maybe the version is greater than 1.3 something. So after this stage and then we can hook up, try to build the connections.

O

So basically, here the when nightcom connection is built over quick, the light conf manager will be the uh the the client of a quicker and then netcaf agent will be server. Also, the manager will initiate the connection. So this basically about the connection of light conf over quick and then we consider the result, shutdown, the connections.

O

So in this case first, we have a review the ways greek terminated their connections, the three ways for quicker to terminate the connections.

O

One way is that the idle timeout is enabled, in this case, when idol, timeout and then quick will shut down the connections. So another way is that either side of the quicker then they just in the connection close. So in this case the conversion where we're closed- and the third way is that so something wrong happened. We cannot access some state whatever, and then we just slightly reset the connections.

O

That's the stereo three way the quick connection will determine it so because netcam connection is over quick, so we in this case we will disable the idle time out in the quicker. So in this way, in normal case, the light connection were there forever and then we just uh when knight conf entity receive, was in the closed session. So in this case, netconf entity will shut down the quick connections associated gracefully.

O

So in another case, is that so when that conf entity receive or initiate the queue session, when selection is open in open state, and then this in this case, the latch entity will also gracefully shut down the quick connections.

O

So the third case is that and then, when that kind of connection detects something wrong in the quick or under, and then we shut down the connections. So that's the way more consideration about that curve over quick connection termination. So next page.

O

So here we just uh we'll talk about some more details about those connections, so in order to talk those more details- and we just give a uh the protocol layer of light curve, so basically this is described by the rfc for six two four one. So let count layers. We have four layers: content, layer, operational layer, mesh layer and skill transfer layers. So here basically we just focus on the communications between the manager and the uh agent. So this connection uh or communication is rpc based and then we have two uh one one.

O

uh One type of connection communication is a bi-directional, for example, when when manager send the configuration to agent and then agent will after something and then an agent will send a notification to manager. So this is a two-way communication or called bi-directional.

O

So another communication is, we can classify as unidirectional, for example, when agent, uh when we age in the front, found something wrong whatever they just send the notification to the manager. So in this case manager don't need to reply. So this is the one directional or unidirectional so for these two types of conventional communications and then we can use the quickest stuff or my opinion. Those two types of communications to the quickest strains very easily to the next page.

O

So basically, this gives more details about. We have a two type of communicational strains. One is bi-directional in medical, so this bi-directional communication can easily map to a quick stream string string ids, because in the string, quick string id there's the last two bits and then those last two bits identify or indicate whether this this string is unidirectional or or bi-directional.

O

So we can directly my opinion, there's light curve, communication, different type of communications, to the quick streams identified by the last two bits of quick string, ids, so next page, so about authentications using a quick handshake.

O

So basically we just reuse some kind of procedures or whatever rules already defined, for example, for the server identity.

O

We just reuse those rules already defined in the uh four to four six, four, six, four, six, uh four six four two in that one and then for the client side. Client identity is local policy determined and then we can also use third party authentication.

O

So let's look at details next page.

O

So these are basically this is the description or rules defined by rfc 4642, which is how we identify a server. So basically, so client must use the server name that the civil line is also used when we open the connections and the second rule and the third rule- and this one don't need to go repeat this one, because this one all this is already described in rfc 4642.

O

O

So if this uh proposal move forward and then we will need a some kind of uh ayana assignment so here one uh request is for the alpn uh registration.

O

This new registration will be just we have a protocol and then maybe we'll just use an oc as a product id, and then we just have this kind of a sequence there, and then we also need a udp portal number because quicker is based on utp. So next page.

O

So this is the first presentation, so we would like just to collect uh all the feedbacks or comments from all of you, but because I'm not an author, I don't have those details and I would like you to send those questions to the to the least because I'm I don't because I haven't spent much time around this one. I just put the time to digest this draft and then prevent the draft.

O

C

So before we have the first speaker come up, um are the authors in the room, even if they're, remote or virtual, and please uh step up there and help the presenter and answering some of the questions go ahead.

Q

Thanks uh anthony somerset liquid, um considering it's over quick and it's over udp and it's net conf, I've got a few reservations because of you know, udp is not like guaranteed reliable.

Q

Yes, quick is better than playing udp, but um the bit I wasn't seeing at least in the draft was how we would necessarily get that reliability of because of the conflict that we might be sending or receiving to ensure that it gets there. um I haven't seen that and I think we would need to address that.

O

Yeah, I think that's a good question whether a creek can provide the same level of reliability as tcp. I think we can do some search or research.

O

I don't know whether the water, I don't think a water, is uh in the online right now.

O

But quickly the connection rented a protocol. I think it should be reliable.

C

All right, um so speaking as a contributor, if, in summary, what I guess, I'm gathering from your presentation or the presentation that you put forward is really the change is only the inner consideration page or the other protocol considerations that we need to think about.

O

Yeah, I think so because this one, you see, we already have a click there and then we just about how we use the light. Conf of quick is just how we reuse the quicker stuff.

O

I think it looks like a pretty straightforward, pretty straightforward, and then we just request some kind of code numbers there.

G

K

So rob wilson, cisco as a country, uh I'd like to say thank you for presenting, if you're, not for the author of the draft- and I thank the authors um for bringing this work to the working works. I think is interesting and useful, and I think certainly something that's worth thinking about.

K

um I can see potentially netconf over quick could have some useful benefits, particularly in terms of the separate streams, but I'm not quite sure whether uh the way that yang push is set up today, whether you'd actually really see those benefits or not, and in terms of the separate streams for separate rpc requests again I'd.

K

Imagine today, a client would just open up separate sessions and you could coalesce those together and avoid that, but otherwise, um often with the netconf request, you'd expect them to be serialized like an edit config request and then a get request. You expect those to be processed in order and you might want to allow those to go in parallel, but there's other considerations there, which may mean that that's not the right thing to do and if you do need to do that, having a separate session sort of solves that problem quite nicely.

K

So um another aspect to this is in terms of the start-up time I can see for some people that might be a little bit helpful, but again in terms of the sort of exchange of capabilities and things, I'm not sure, you'd see that much benefit so um later on. There might be discussion about where does netconf go and where does rest conf go?

K

I wonder whether quick is more better framed in that discussion or like a future version of of the protocols, rather than necessarily adding it to the current one, whether you'd actually get any real benefits over just using tls anticipate.

O

Yeah, I think, a very available comment and then also uh I would ask author to consider your suggestions and comments yeah very good. Thank you.

O

Yeah. Thank you, everyone for the valuable comments and the suggestions. Okay,.

C

All right, in light of the fact that I think, as rob mentioned, maybe we might want to consider this as the part of yeah rescant next and net continents will skip the hum on this draft.

C

So the next presentation and the final one, actually not the final one, but the one is on tls at conference. Tls 1.3.

R

Hi, my name is sean turner. It's nice to see all of your masked faces up here, um all right, so that conf over tls 1.3 next.

R

um The motivation here really is that I deal with some very pedantic people and they read some drafts and they're like well that one says tls 1.2. What about 1.3? I'm like okay, so we can write a draft now. The thing about tls 1.3 is that you can just kind of use it, but there's some there's some differences that you need to deal with. The first is zero rtt.

R

Now what it says in the in the appendix of um a46 is that, like in absence of an application layer, proto protocol, you shouldn't use zero rtt, which is zero round trip. um I think you guys know about this. It's in the rest, conf draft.

R

It's referred the whole nine yards, um but I kind of figured it's better to be explicit about this, because people see this as the go fast button and it's actually got some problems and I'll get into that in a second, um and I also like to stand on the shoulders of giants hold on.

G

R

um And so we decided to do was just base it off uh 75.89, so we looked at the only two things that we needed to talk about to profile it which were zero rtt and the cypher suites, and everything else says do what's in that draft. So it's a very simple draft. It's very short.

R

um We purposely decided not to update 75.89, because I didn't want to get into the whole. You got to pick this one. This is the mti over the other one. It's just kind of like you can implement it. 1.2 is out there for now. I think it's going to be around for a while, but we did update the iana registries to point to this draft in case you wanted to do it so just kind of like dotting us and crossing t's. So next.

R

So the next uh the big thing with zero rtt. So if you don't know about it, it's a way that allows you to send early data um to clients or to the server in the first flight. Now the way this works is you basically go back to the server the second time, but in the first exchange it's giving you a pre-shared key, and so then you can use that to basically protect the subsequent messages. It does make things faster.

R

It can be loaded via this exchange or it can be loaded out of bands.

R

There are some problems, of course, because the data is replayable, and so that can cause some problems and again the whole point is just to basically say: don't do it now on the rest, comp um draft, I think, there's also some recommendations about not supporting zero rtt. This is just making it a little stronger and then the only other thing you need to say about it in the draft is cipher suites and the cipher suites are specified slightly differently and the mandatory to implement are a little bit different um and they're all forward secure.

R

So it kind of makes sense to kind of move up to the next uh level of more modern cryptography. And that's really all that's in the draft and I'm asking for working group adoption.

C

All right, I don't see anyone.

B

C

The queue or maybe now.

K

uh Rob wilson, cisco. I think this is really helpful to do so. Thank you for taking the time to do this and to explain it because I think it's helpful for the world to sort of move more towards tls 1.3, so um so I'm definitely very supportive of.

R

This yeah and again so the way I was always thinking about this is we'd, specify it and if you were like no, we want to put in this other document or the next version or whatever great the text is there take it do it. You see what you want to do with it. If you want to move it forward with it, that's great too.

C

All right, if there are no more comments, then we're going to do a quick hum on whether we want to adopt this document. As a work group item.

B

R

Like instant gratification, I can see it on the screen.

C

All right, I just went ahead and closed the poll. I think we have an overwhelming response and we'll take it to the mailing list to confirm the adoption thanks sean. Thank you.

C

All right with that, um the final item on the agenda was discussion on rest content context.

A

Slide so we have something to look at.

C

A

During the title, the first flight of the chair, slides so there's something on the screen.

C

C

So can't you want to kick off the discussion.

A

A

Yes sure um of course, uh yes so uh neck off next and breast conf max there are issue trackers in github for each of these drives and of course the thinking is well of those issue.

A

Trackers was to collect um issues that you know, we've discovered over time and ultimately roll them into the next major versions of these protocols and the same time as this we're also tracking issues in the net mod working group on yang yang next is the issue checker there and many more issues been filed on the yang next issue tracker, and it goes without saying that an update to yang would necessitate an update to netkoff and rescoff to support that next version of yang, and so I guess the conversation is do we want to when, when does the working group think that we might have appetite for some of this work?

A

um Are there you know? Are we beginning to feel like the protocols are getting old and we need to freshen them sooner rather than later? I guess we're just curious as to what people are thinking along these lines.

C

All right any comments on whether there is interest in the work group to see whether protocols, both rescue and next and netcon, need a refresh.

K

So, um as the chairs know, I, when we discussed this before the meeting, I was quite keen to have this discussion um and see there's feedback from the working group about this sort of topic. So some of the things that I think are interesting, the quick that was just presented um is one option. Something's interesting. The other choices is in terms of netconf being xml based, whereas a lot of the world's moving towards json or binary encodings.

K

Is that something we want to consider um and potentially updating the protocols for, I think, there's other areas of where um things like we have the shared candidate data store. Do you want to be trying to move away from that and moving towards like private candidates? What's that sort of thing um and there's other places in netcoff, where I think that the specification is a bit ambiguous and could certainly be clarified or simplified in places as well?

K

So I think there is personally, I think, the scope to do something here if there's an appetite within the working group to try and actually drive this forward. The obvious question that kent raised was about um the dovetail with yang next and do we need to wait for that to do that same time, which might take quite a long time? I'm not sure the the two necessarily need to go hand in hand, but in the previous discussions there is some work about moving some of the um almost like the protocol stuff.

K

That's documented in rfc 7950, potentially moving that out. So there is some sort of cleanup work, of course, to be done at the same time. So I'm just I'm interested in other people's thoughts on this matter as anyone's willing to share them. Thank you.

C

F

Has uh the thing that I would be interested in seeing that being somebody that's strongly following the netcave work, but is sort of soaking in the streaming telemetry work in a couple. Different forms right now is again is rob saying, get away from the xmls. The you know tool that everybody likes to use get into something. That's more of a compact binary form uh the phrase I sort of sling around work these days is that printf and scanf are not your friends.

F

You know the the cost of those you know in terms of uh serializing, stuff and deserializing them wastes a huge amount of time. It wastes much space. Things like ip address is an example just work to get that in and out of that format for a large amount of data, so waste the cpu. You know it'd be nice to see something. You know as an example cbor being used where we have a compact format, uh nice canonicalizations and it's realizes into a small form.

F

I think the interesting question I'd have uh again being sort of a couple steps remove participant. Is you know what happens to yang as an example yang? Very much does its uh types right now, based off of regular expressions on the actual ascii patterns that you should print things as what happens, so you want to say well, this node is my type ip address, but you wanted to actually show up on the wire in binary format. What does that do to your validators that sort of question.

C

So and jeff since you again speaking as a contributor since you mentioned binary encoding and there is an issue open on the issues page. If you could add your comments to that, that would be helpful.

C

The quick protocol is also an issue open on the issues page. So as rob mentioned, maybe we should discuss that as part of revving. The protocol.

C

Some of the other areas that we're looking at and also documented as issues on the page, uh relate to a private candidate data store issue that I think rob just entered a couple of days ago.

C

There's some macam integration improvement requests that andy has indicated.

C

And, of course, there's the json encoding support in netcom, which we might have to think in light of the fact whether we want to move towards a more binary encoded format or whether we want to support json.

C

So the cleanup of the specification relative to yang and xml- I think this was referred to by rob again with respect to rfc 7950, where probably there are more references to netconf that probably should be taken out of that document.

C

So, overall, um quite a few issues. The question is of how much interest there is within the working group to pursue this work.

C

So can't do you think it would be helpful to try to get a poll on whether there's enough interest and then of obviously who, if anyone is interested in picking up some of the work.

A

I think a poll would be good, but before getting to that with regards to binary, I'm almost wondering if it's something that we need to do at least in terms of there's co-op and seabor already they were created as effectively binary versions of netcaf or restaurant would. Does it make sense for netconf working group to define another binary protocol, or would that be the answer? I can understand fixing many of the other issues and moving to json and things like that, but for the binary is that something that we think we should do here.

C

I think we saw a few nodding of heads as far as um sibor is concerned, but maybe rob.

K

Yes, just for clarity, I mean I think that uh co-op aims to be really concise and things in terms of its format and things. I wasn't necessarily thinking that the messages had to be necessarily defined in a binary format, but merely that the data that's been carried uh being carried in like cbor, rather than xml or json, and in particular my interest is in, like the streaming telemetry side of things, we're getting data off the device, a lot of the data there. I think there's definitely benefits to having that go in a binary format.

D

I would echo the seabor uh what we said about cyborg and if, at the same time, we can distance ourselves as much as possible from google protobuf. That would be fantastic.

A

So rob mentioned the stronger desire for um when pushing telemetry data off box and with the notif. You know the suite of notif drafts that we're planning to publish so so far, there's https notif and udp notif, and uh it was discussed at the time that we started creating these drafts that it would be ideal to create a binary notif of some sort.

A

You know for pushing um telemetry data or gang push data if, if that were the only focus if it was just the binary notif, would that resolve um like 80 or more of the primary concern for wanting to move to binary.

C

F

Jeff has so uh kent the answer to your question. Is it shouldn't matter if it's the notification case or whether it's the normal cases, you're going to want the protocols to be able to deal with the same binary format, regardless of you know, which was being used for, but for the streaming telemetry? It's absolutely one of the core use cases I think effectively. Because operations like gets for simple operational things for small tables.

F

It doesn't really matter what the encoding is. It's a small amount of data. You don't burn a lot of cpu, but any case where you have large amounts of data coming out like say doing a get for the bgp rib. You know that's a huge amount of data being able to minimize that time would be good and if you have a streaming feed of like hp, routing state as an example minimizing that's also a core use case. So I think to answer your question. It doesn't really matter which is your use case.

F

The telemetry feed will be sort of more of a motivating use case. I think, but it should apply across the board. It's common code.

A

Well, I just as respond to that. I think it might be a great simplification if we can just focus on a binary notif form because, um as mentioned there's, uh for instance, udp notice right. So it's completely different protocol, but it doesn't affect the configuration side of things.

A

um I understand that through uh netconf you know a client can you know interactively request for the bgp rib data and it would be a huge xml or json response, but if we have binary notif and there and the client is using yang push, um then then that would that's how they would resolve that issue. um So I don't know I I think it warrants more discussion. Thank you.

F

Just as a quick follow-up, if you think about printing any large xml document, how much of the overhead is just simply the tags and that's the single biggest thing that you get out of any of the binary formats. Those things just drop out.

A

Did you want to prepare a poll.

C

Right so before, actually we jump into poll and there's one other topic I briefly wanted to touch upon is so one of the issues that um we opened some time ago was around the cleanup of hello message and capability in netconf now tied to that is actually the work of yang library and I think the the versioning scheme mechanism.

C

I don't know if we have the authors here, but was there any desire to see that maybe the fellow exchange work is something that needs cleanup or the fact that we want to use yang library as a way to improve what is exchanged at hello time.

K

I'll, let jan speak to this first and.

C

Then uh yen, you might want to unmute your microphone.

C

Or we can't hear you.

C

Okay, we still have a few microphone issues. Can you try speaking again.

A

C

Okay, you might just put some comment on the key in the queue.

A

Yeah or type into the chat window.

C

K

So, while jan's doing that robots in cisco, so we certainly discussed this in the context of yang packages and the versioning work. So it's a good good thing to raise this, and um I know that yan is concerned that we seem to have lots of different mechanisms for exchanging things like yang library data and which models are being supported and and there's different other cases where you sort of exchange these lists of models, the idea with young packages, it sort of simplifies that and it stops you having to exchange this long list of young modules.

K

You can just exchange a reference to that, but it does become another mechanism.

K

So I think that, yes, if we were doing a new version of the protocol and yang patches, was completed in that time, it would make sense to try and use that as the mechanism to say this is the sport supported, schema for the device and try and simplify some of those mechanisms. So I think that would be useful and sort of cut back on the proliferation, and then that agrees with what yan thinks.

C

Okay, so before we go to the poll, any more comments or questions.

C

All right, thomas.

G

Thomas from swisscom, maybe regarding the notification message, header suggestion that we are adding also the the x-pass the young model and the versioning aspect there. So, if you're talking to make it binary, that would be very helpful.

C

C

Just make sure you add it to the notes page also.

C

So I'll go ahead and start the poll.

C

Okay: let's go ahead and I'll end. The session.

J

Thanks mahash, so benua clay's answer yes right, but actually I'm not interested in everything, so I'm interested into you know the binary encoding and the header and some of these. So I was not too sure what to answer so. I said yes.

N

I also think that these issues could be hand handled one by one, as opposed to yang, where we have big issues that need a second revision. I see this more as additions than the revamp of the system.

C

Okay, so um so just quickly going back to the poll, uh even though it was generic and applied to almost all the open issues, um we still had a fairly positive response.

C

So the question I think, which is being raised is: are there more specific, hot button issues that need to be addressed before others and that's something I think we can take as a poll also on the mailing list. We could certainly try to go through a whole process, but may not get a sense.

C

So maybe kent and I will discuss this and bring it forth in the group mailing list to see if there are any specific issues that we might want to address before others ken. What do you think.

A

um And I was actually I have to um come clean. I did not reply to that poll. I didn't know how to either um it. I guess really. I was thinking the poll is, you know, do we start to work now or you know if we know that the uh yang next is looming um and it's necessitating a change in netconf and rescoff already?

A

Do we have to block for uh the yang next work to you know complete or um you know, move forward, and I guess your proposal is: let's see if we can find some items to move forward now, which makes sense and uh of course anyone is welcome to write a draft to move any of those items forward when possible. That'd be great.

G

K

Robertson, cisco, so um so there were some poll votes against doing this work it'd be interesting for those people if they have a chance to either put a comment in the chat or come up to the mic and explain why they think we shouldn't be doing this. That would be really helpful. I think I don't know. That's aligns to bellagio's comments, maybe in terms of be able to split the work up, but if there's anyone that wants to share their thoughts as to why we shouldn't be doing that that'd be useful to hear.

C

Good point drum.

C

So for those who did not raise their hand either because they were confused about the question or um one did have specific views on why maybe the work should not be pursued? I would love to hear from you too.

C

Okay, so I see a comment from yan who says there are currently three mechanisms defined for clients to figure out which modules the server supports. Then he goes on to say. I think a couple of the next issues might be worth working on. Is that a yes or no?

C

Maybe a poll for individual proposals might be more interesting than a yes, no global answer. So he was one of the ones who posted did not raise his hands.

C

All right, unless there is um there, are any more comments. um We can go ahead and close the session. We will take this to um the mailing list, the question of whether we are in any way tied to yang next. We should be wait for it or maybe pick up some of the items uh more heartburn issues as what we want to start our work off with so right. If there's nothing else, thanks everyone for attending the session and hope to see you guys soon,.

C