Internet Engineering Task Force 101, 20 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF101-NETCONF-20180320-1330

Description

NETCONF meeting session at IETF101
2018/03/20 1330

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

A

B

Think ready to get started. This is the net Khan working group. If this is not the session you want it to be in. This is a good time to exit.

C

Okay, so this is an IETF meeting we run using the node. Well just mean essentially everything you say it. Microphone is considered as contribution. Please be aware of that.

C

The blue sheets are running around, please sign it and then pass it back. If you see others walk into the room, try to get them to them as well, somewhere in the middle or near the end, we'll move them around the room again. Holding them up in the air. Raise your hand if you need to sign it. Well, you're, not here at the moment. So how would you know I just said that we should have minute takers. Can we ask for some volunteers to help us take minutes on etherpad.

C

Volunteers for taking minutes.

C

Thank you and I guess we'll also, so we have to jabber beyond jabber I can and I. Actually, we should have a jabber scribe near a microphone. Can someone be jabber scribe.

B

C

Thanks and can you see the microphone will be able to see people's badge isn't read.

C

Okay, I'll try to speak louder, I.

B

Guess he was just wanting to make sure that you're in a position to see the nametags.

C

So we will be using the other pair for taking minutes. There's the agenda. It's been posted when you need to come to. If you want to speak and come to the microphone, please begin by saying your name and and make sure you only use the microphones. Don't try to shout from your chairs. There will be people that are joined in only using meet echo, and they have to be able to hear you.

C

So, first off I think everyone here is probably seeing the email from this morning we did get the Charter approved. This is essentially what we discussed on list about a month ago. There were minor changes to address some isg concerns and if you take a look at it and if there's any comments that you want to make bring it to list it's the status of current chartered working group items since Singapore, we did publish 6536 biz, it's now RFC 83 41. Congratulations to the authors.

C

We also have a large number of documents that are in progress just going through this quickly, so we can give some chair status for each of these. First is the net comp event notifications. The last call issues are still being discussed on the list. We'll have presentation today, the NMD and in MVA net comp and MBA rest comp drafts are both ready for Shepherd right up.

C

Then there's the notifications messages draft which will be presented today. There's the rest. Cough notification draft also presented today. 78 95 same with you and other nmda drafts, they're ready for Shepherd right up subscribe notifications. The last poll issues are still being discussed. The UDP pubs channel it's not on the agenda due to there being no discussions since it was last published and but it was updated, I think this past Monday right yeah.

D

C

When the submission cutoff was released- or you know, if there's no discussions, I was kind of wondering about that update, I. Think the constants of the update. It is.

E

C

Is a working group document right so I would expect that you know anything that would have led to an update we've been discussed within the group. If there was no discussions, then plus.

B

I think there was an update in the draft that was probably not reflected on the mailing list right right, so I'm thinking.

C

So, just as sort of a broad statement, everyone should be aware that changed these are working group documents that they are owned by the working group. It's really just editors that are performing the updates, but they're doing so at the behest of the working group. So please be sure to run ideas, proposals for updates to the work group, mailing lists and discuss in there and then based on those results, update the documents and be sure to update the documents before the cutoff. So you don't have that issue up.

C

Next is the gang push which will be discussed today and it's your touch draft, which is ready for Shepherd right up.

C

There's also the more more chartered working group item, so these are all that keystore and related drafts, none of which were updated due to the editor being busy help would be greatly appreciated here. The editor told me: if anyone is interested in working on these documents, it would be fantastic if you could help with them. We get them done faster.

C

Status of non-charter items they're, actually a number of individual documents that have been recently presented and they're all on the agenda for today and for and then now for the actual agenda. There will be 15 minutes for proposal for refactoring the keystore model, 20 minutes and maybe a little bit more I think we have some extra time at the end of the schedule.

C

So maybe a little more for discussion to discuss the update, updated comments for the yang push and related drafts and then there's a number of all the non chartered work group right of documents, 10 minutes each for those with.

C

Lastly, it's not on the slide but there's. Lastly, there's 10 minutes of spare time so maybe we'll use that.

C

Okay, hi I'm Kent I'm first.

C

So today, I'm going to present a proposal for refactoring the keystore model. As you just heard, the editors and myself has been very busy, so I haven't actually updated the whole keystore friends drafts, but there is this comment that I think uragan made quite some time ago about you know making sure that the modules, actually the names of the modules are reflecting what the r4 and that the scope is. You know, as they should be.

C

One of the things he asked for was to remove the private keys, the storage of the private keys themselves from this global container configuration container, and so that update was made in the zero for which was presented in Singapore last time and but in doing so the keys are no longer stored there, and so, when the questions becomes, why do we call it a key store module when it's not actually storing keys, and so the whole presentation here is to sort of go over?

C

How we might you know, fix that problem and by doing so doing so by introducing maybe two new modules?

C

Okay, so the keys for module was primarily modelled at for the keychain access mac, OS utility I'll, be it without any encryption to protect the private keys. In fact, the module was originally called keychain, but was later changed to deconflict from the keychain module use by the routers routers.

C

The primary goal of this module was to centralize the configuration of trust anchors. The thinking behind that was because the same set of trust anchors would be needed for authenticating NBI clients.

C

You could have the same set of trust anchors regardless the NBI clients were net off base or restaurant based or just how the same said to configure your trust anchors in one location and then refer to them where you need to so that was the primary goal. Centralizing the configuration of private keys was added primarily, was added primarily to eliminate needing to have the same gang everywhere. So if we hadn't had the centralized centralizing with private keys, then everywhere you wanted to have a private key.

C

You copy/paste the same gang into your game to your local gang module, but then notice noted that it's uncommon for implementations to centralize private keys this way, because the compa that you're made. Thus the top-level keys container, was converted to a couple groupings and all the client server modules were updated accordingly. But then this raises the question why it's called a key store.

C

So the proposal is since the remaining protocol accessible configuration is solely for trust. Anchors than renaming the module to trust anchors makes sense. However, the module also defines groupings that are used for the private keys talked about in previous slide, which is nothing to do with trust anchors and should be moved into another module.

C

Seeing how this module will define a number of crypto related identities and typedefs. This module could also be called or could be called ITF crypto types which we similar to other types modules. So we have in RFC, 69, 91, IETF, yang type and I I, think it's sexy, plural, I and I Tia inet types and then in RFC 60 to 90 for there's ITF routing types so that IETF crypto types might be making sense. It seems like the time has come. We didn't do it before or no one.

C

We didn't have the use case for it, but now we're beginning to define a number of data models which are configuring and security parameters.

C

The current contents of the ITF crypto types are, as is as follows: essentially five different things that are in there there are identities for hash hashing algorithms identity is for key algorithms.

C

These would be asymmetric, key algorithms type, deaths for asn.1 structures, groupings for private keys and their associated sort, and a notification for notifying when a certificate is about to expire, and all this is just a subset of what would be needed to support the keystore and Friends drafts or all the client-server modules that I've been working on some issues with this, though, is that I think cryptology is a big area. It seems like the current IT crypto types.

C

Might be just scratching the surface in the interest of time, it would be good to publish just the subset needed immediately, but we need to know what the endgame is now so that we can structure it correctly, um and so that kind of leads to the question should I tip crypto types be refactored further. The two groupings for configuring private keys seem like they might be better off somewhere else, because they are groupings and they're very much specific to how you create private keys.

C

But you know normally the types modules are just creating that identities and and tech toughs I do believe that in the ITF routing types they also have groupings, but their groupings are much smaller than the groupings that were I mean the groupings that are currently in IETF crypto types also have action statements on them, so they're a little bit more than just a simple grouping.

C

Secondly, the notification could be pulled out, maybe even delete it, because I mean the notification is to alert others when answer ticket is about to expire, though, where would you put that I mean it? Doesn't you wouldn't necessarily do that, just because you're having some trust anchors, you know so is it seems like that, might be a module ooh all its own or just simply delete it, and, let's not worry about it for now and then.

C

Lastly, maybe the asn.1 type types could be factored out, something like ITF, a sandal or a sn1 types, because those are all kind of the same. You take amazed in that warm structure. You say cedar encoded, you make it, you know it's a binary.

C

The base type is a binary, and then you know you see you have a name, but you can imagine, there's a lots of a s and dawan structures, so you can imagine in the fullness of time there might be 30 or 40 50 these kinds of things, so some options would be keep ice. I took east or as it is, but maybe rename it to. What is the question switch to the two drafts that are part of this agenda, with no more refactoring get advice from the security area?

C

First, to see what the end game looks like and also for the parts that we do need now, how should they look so when you start talking about identities, for crypto algorithms and hashing, algorithms, I'm sure that they have a lot to say about how they should be named and structured and I don't have any other options to share. This is my last slide, so at this point them do. Does anyone have an opinion in terms of which approach we should take? Oh.

F

Hi Frank chef Robbie and thank you to bring this draft and that discussion here I think a person I think that this work is was. It was y22 and I'm from the security area and I think I have some knowledge about it. So so, just under your very only question, yeah I'm I'm willing to contribute to things I felt it may be to continue.

E

F

But, and go back to your questions here, I think you have no justice. Just the last page. You have several options. I think my personal, my my my personal feeling is that country, because, from your current draft, I I can only sing a very simple start for for this historic technician. I, don't know whether you want to more include more crypto of operation or configuration information for into this mode. So so so because those those lost edition we are, we are resulting the last.

F

The later hallway defined a how it defined from the security aspect, how many classes we need or how many organize these modules. So it's a little bit only to do to decide to just to keep the keystore draft or splitting to draft so I think the option. 3 is more reasonable right now and we can discuss more based on this first, the draft and what is the other we need and how to organize them. Then we can decide.

F

You know how to push it a further work, and so so I think I need to have more discussion with you of life about what is your current idea of of of what should be included in this crystal motor, in addition to the already existing content right, because I can see that if we, if you want to a country, you only have so certificate information and the private key information.

F

But if you, if you are, you need more information such as a symmetrical cryptography, the and the hash function and the random number generator or something I, don't know if it's in your plan, so so we can discuss and decided how to process later. So that's my person idea, yeah I, won't help on this work. First.

C

Thank you for offering to help, and, secondly, with regards to trying to understand how much more we need to do, we did try to get an early review from sector from security experts. We're hoping for them to be in the room, unfortunately had conflicts with another meeting, but I think Inglis is going to give this presentation in a SAG working group on Thursday year.

F

Second year, you are right: yeah, we, we I'm the author of a I, just forget that part, and also of the second ascent several drafts in second working group, which is also talking about the the security security baseline, configuration and operation stages for piece line of the security part of the network devices. I think there are some overlapping. Oh there are some similarity goes like that, yours, so I think we we need to.

F

We need to work together or which part should be here and which should be there and how to work in a consistent way. So yeah yeah that you're right yeah.

C

Absolutely yeah.

B

Can I give you have people behind you or also ready? Okay, so.

G

Rob Wilson Cisco, so my perfect choice, I called like option two here: I mean I I, think it's okay to change things in a simple way, but don't do too much I!

G

Think in terms the discussion that's happening there I'm concerned about us spending a long time trying to get to a perfect solution and I would rather try and get some of this stuff out and published now as models and then revise it and and otherwise we'll never actually get these things published so I'm more keen to actually try and get stuff finished quicker and then revise it with extra stuff. Later.

H

Very great Cisco I, like option 2 as well I support this work going forward, one of the things to consider in looking at your draft. It doesn't refer to the trusted computing groups, definitions of trust or anchors and integrating with what the definitions are. Chris Cooper group might be a good addition and it might impact how you actually define the anchor in the trust. Okay,.

C

That's good comment. Thank you.

I

Tom batch echoing what will Milton get on with it in your introduction, you mentioned some drafts that not much it's happened to lately in particularly Lissa. Don't answer the ones I'm struck by how well those were progressing, and then we refactor them all and since weary fact, the more they seem to grind to a halt, so I'm against refactoring I'm against I'm chairing just get it out, publish it. We can always have a nice batch of the charioteers. To this time. We've got some experience.

I

J

Tim Carrey, Nokia I think I concur with the fact that we'd like to move this thing along, but, more importantly, when we talk about an option to and you switch to these crypto types. What I didn't understand when I when I looked at it was particularly for the for the SSH keys. I didn't see how the referencing would happen with the with crypto towards the the pinned anchor sites. I wasn't quite sure if I've got an SSH key, how that related to the crypto modules, because I think they kept that in the trust anchor modules.

J

But the actual key realization was in the was in the trust, anchor okay.

C

We made a mistake: the trust anchor module does not currently have the it's not importing the crypto types module, but it should for, for instance, the typed F for the CMS structure and the ex-59 structure, which are being used inside the trusting trust anchors module. So.

J

I didn't see how the referencing happened between for the SSH keys between the between the types and the in the pinned keys at all. I didn't see a reference between the two modules. That's what.

C

I missed something: that's why just saying I left it out by accident, I'm.

J

C

Left out the reference from a trust anchor module to the crypto types Molly's.

J

Gonna go Trust Bank or to crypto. We just missed the reference right: okay, cool thanks. Okay,.

C

C

Hey Eric, I think Europe.

H

Well, you just did slides.

C

It's not communal.

B

Okay, so you're having a little bit of technical difficulty with bringing this presentation.

B

A

Different presentation.

B

A

From the prism tapes.

I

B

K

H

Thank you very much. I am Eric Voigt behalf of myself, Alex Clem who's right here and and many other people who have been involved over the last few years. On the subscription drafts we've been trying to progress. Three of the dress towards were last call. You see a lot of emails on the list with a lot of great comments and I want to thank quite a few people. The room, I gonna, throw a few names out. I'm gonna miss a lot of them.

H

People like Kent and Bala's and Martin and Andy is part of the yang doctors and Keegan and again I'm gonna miss a lot of people, but we've got a lot of great comments on on the last call. At this point, I, don't think, there's anything that seems insurmountable. We're gonna be talking about where these first three drafts are in last call and we're going to hit a couple of the issues that we see on the list.

H

We might even be able to resolve a few of them, pretty validation on the list, but again I'm speaking on behalf of myself Alex and the others trying to get these to last through last call.

H

So first thing we're to do is address the first three drafts with event streams, young data stores and then the net comp transport.

H

Now on the net Kampf subscribe, unifications working group last call: we've done a number of changes such as requests to make it work like fifty to seventy seven with the filtering event records within streams based on permissions, and that actually has some interesting implications for some people over the core working group who who have a different construct that they're looking at, but we're going to go ahead and follow fifty to seventy seven we've had security and considerations update based on trying to match the templates, putting together by net mod, obviously some stuff.

H

Like treaty, I a-- grams referenced reference numbers used for the state machine figures breaking out configuration replay and its own sections. There's been a lot of things which which have been proposed on the list. None of these are actually going to be considered closed until we have a chance for people who made the comments and or when the comment on the on the proposals have a chance to get through. Those, as part of last call there's still some unresolved issues.

H

We have some slides coming up that go over several, these that came up from people in the room and, of course, there's more things that could evolve a p-- existing discussions. For example, the yang dr comments are almost complete there again, not huge items coming out of there, but they could drive some more great items as well in terms of review question one, and this is one that that martin identified and I think it's a good point. The question was: do we you want to use integer? So I do we say integer.

H

Do we want to use a string object? Sorry as an index for a receiver instead of using address + port, the current draft has address in port, but that makes it difficult to go ahead and augment or add new things such as leaf rests to other drafts where you might want to identify other receivers. So I don't think that anybody right now is going to say they want to continue with address port. The real question to open to the group is: do we want to have the name as a string under receipt? For?

H

Probably yes, and do we want to have a dress import as an option to be populated into the into the receiver, or do we want to just allow people with their own augmentations to define what receivers are so in talking about this? With some people offline and online? The proposal is a preference for option two which would use names a string but but we're certainly open to whatever gets the the working groups- preference we're just trying to record what the working group wants to do here. Martin yeah.

L

More conducting so should we discuss them less, you go yes, he says you want to discuss the issues now.

H

We can I mean this is trying to give a an overview, but go go into the details. If you want to some early consensus.

L

I would prefer option three, and the reason is that NAT, Kampf, botnet, cough and rest comfortable home has another way of doing this. The sorry that is the net, confer risk of client and server documents that can work.

L

So if we also had Addison port down in the receiver list, it would be redundant at the best or otherwise. What would it actually mean? How would you use that as important the receiver? The question.

H

Is you always need something.

L

Something more right, like authentication.

H

Information and stuff like that, it certainly can be a leaf ref to other receivers, as defined in those other working groups is I. Think that's makes sense.

H

I do know some people who do not want to reference the external groups and just want to go ahead and configure address and ports, so I see it as an end rather than an or that people can address with address and port other people can have leaf rifts and that there's no reason why receivers cannot have multiple things and what I'm, hoping and against it's a strong preference is that we allow augmentations, so that receivers can be defined in many ways you just take the set of them and they at least two receivers right.

L

I mean option: three isn't isn't complete on its own. Obviously it's just a name, so it can relies on augmentations in the future. And yes, if we actually had those other documents published, I would suggest that we had references here to those other documents, but.

M

L

That so that's why the option three is just right, open, but I still.

M

H

L

How the address import would actually be used.

H

Yes, but the question is you can still argument option two to also allow leaf refs there so yeah, but then.

L

You would have both.

H

L

So you could, you could specify a name- and you know possibly not called home information and their reference to that, and also a dis importand. What what does that mean? I think even address import. You can augment for those transports that just need a tourism port whatever. That would be. That's no transports that we have here right again.

L

H

Can close either way I'm happy with whether whatever the working group says it seems easier, but again if people just want to have one or both yeah, whatever that working group thinks, but any others all right so again, we'll resolve it. But again there's just a premise: it's just a preference.

N

This is Alex Klem. So what is the problem I'm creating with you? What is the process for us to get closure on this, but I feel similarly by preference format. That is an option tool, I think actually having address and port I think many many users will need it and I don't see an issue with over specifying specifically with that. But that being said, if option three is a preferred one. That's right! Oh, but we shouldn't, but we need to get to closure so.

H

I think just start a thread on the list and see how many people like one or the other or other questions, but.

C

This has already been discussed in one thread right: okay, well, I mean, ideally we take each of these threads and run them individually to ground. So if you can keep the comments within the existing thread and I know that a lot of people did reply, all all on my original, you know last call thread, but if we could spin them out into each of their own threads and then dry them each to ground that'd be great. I will.

H

Be happy to spin this. A second issue is the question of subscription state notification extension. Currently, there is a subscription state notification which makes sure that the the state notifications do not get picked up by things like the net. Cop stream and state notifications really only go to the impacted receivers. Now, with that extension, you go ahead and allow the notifications any marks. They get extracted the option.

H

If you don't have that stigma, fication is to to actually put text in or some mechanism to identify each notification as being excluded from the net cop street I. Think the current solution makes the most sense. I, don't know. If there's anybody who who wants to propose that we get rid of the the extension.

H

Arguments right so we'll continue. Their third question is dscp the dscp, which is identifying the the transport coding the which would be going across the transport. Should it be it's an optional feature on its own or should be mainline right now. The current is that all the QoS features are in their own optional feature. The question is: should the SCP be its own individual feature, or is it so simple that that we just move it back into into the mainline as an optional feature? I have no preference on to how this is done.

H

I don't know if anybody has a strong preference I think it makes the most sense to either tection one or three just for reducing the number of features, but again I'm just opening to the working group. If they have any strong opinions now, all right, we can take it on the list again salute whatever people want last one for at least back to a previous one. Sorry.

M

Jason stern, just more general question about the dependency functionality. Am I right, if I understand that it really only kicks in? If you have something queued on the output of the publisher, correct and then you would like kind of artificially delay sending an update while you're waiting for something else correct, and how do you know that you have to wait? How do you know something might be pending? It's only if something actually is pending that? Yes, it's.

H

A D queuing thing: it actually matches directly to hell HTTP to DQ's multiple streams and that, if there's a dependency one stream to the other a will, it will go ahead and send that other stuff. First, this is really for people who have very large set of objects which are being sent, but you also have a very short events which have priority we've.

H

The real goal is just to be able to provide an indication for the transport layer should it be capable of it of pre-empting one flow in order to insert a more important subscription flow with them. Okay,.

M

So so you see it almost as like a a strict priority mechanism that if you have a whole bunch of things queued, you want to let some that.

H

M

Events go first, yes,.

H

And the text has been tweaked to pull away a normative reference to the HTTP to QoS and now at the latest version. Based in the comments is a better text description again, we can nail nail that down.

H

Okay last one for gang push is: what is the write names to use within the yang data containers right now, what we have is.

H

Established subscription yang data error stream proposal was there that we should actually rename it to something like stream. Establish, subscription error info again well salute either way. The question is: do you want to have info at the end or or not? It doesn't matter to me I think some people have stated a preference for option two. If there's no disagreement, you know we can just rename it to option two there's. No, no reason why we can't do that kang-cook.

H

So that's! That's it the result quickly! Now and yang. Oh another question. Sorry.

M

Distance turn I question back and one of your earlier slides, you're talking about some changes to authorization so kind of two questions around that one is what what what direction you're moving as far as granularity of dealing with authorization, because in the current draft you mentioned that you kind of don't dig it within an event and filter kind of sub parts of a notification out. Yes,.

H

With with events, basically, you can either do a pass/fail test and the text has been improved. You do a pass/fail test on whether that event goes on. That stream goes to that receiver. So.

M

If the event contains multiple Leafs from around the data model and that receiver is allowed is not allowed to access, you know leaf three out of five. The idea is that you would filter out the entire exactly.

H

Update okay, we.

M

H

That there is some clarifying text and the text that makes it a very different mechanism than for yang push. One of the reasons to differentiate from yang push basically either get the event or you don't versus the Ankush. Where you do a filtering.

M

At a granular level- yes, okay and then the the second part. My question is: there's a there's been some discussion of mentions about if, if authorization rules change during life of a subscription you're supposed to kind of go in and take those into effect immediately so- and it talks about in the draft, for example, that when the authorization rules change, you may have to notify the subscription subsystem with that update.

M

So it can take the new rules, a new effect, but I'm kind of wondering how that would work if you are using some sort of remote authorization like tacacs or radius, or something for this type of thing, because you're not going to get notified. That rules have changed.

H

Correct you have to understand who is using what rules, and there are several ways you can approach this talking to Andy Berman in the beginning there, certainly you were allowed to go ahead and install new rules. If you have them, if you don't have the ability to do that, you can kill a subscription and force it to restart, so the rules load. The first time both are acceptable mechanisms for accomplishing this I'm.

M

Not sure if that addresses my question, it's more it in the middle of a subscription, the middle, the life of a subscription. If your rules are up on a remote server, I know I, don't know if there's I know, there's no standard right now for nak, um you know rules being provided by TAC acts or Reyes, but presumably we're probably moving in that direction. At some point or operational, one have centralized management of the other authorization rules and it will apply subscriptions. So how is the the publisher?

M

The publisher is not going to know about a change to those rules halfway through a subscription correct.

H

There's no nothing new in this document which gets into remote acquisition of the rules. It assumes that the rules are known by the publisher, and/or GAC to them. So the and.

M

Is sonice raishin.

H

Is out of scope, it.

M

Assumes that the publisher can learn about a change to the rules? Yes, because it says in here that you're supposed to take into account any changes of rules. Yes,.

H

M

I, don't see how that's ever gonna work with remote rules. We we can start.

H

A thread all offline, but the goal is there, has to be a remote rule thing whether it's subscriptions or non subscription, so so I think the mechanism for remote rule management should be common across whatever set of things we have beyond subscriptions. Okay,.

M

So you're leaving it outside the scope of this, but you think there's a general problem where we have to somehow notify publishers about changes to authorization rules if they're remote, yeah.

H

And not just a publisher any any that call for a rescue, F, datastore, okay,.

K

H

Alright, so I think we addressed for going to a working group. Last call I didn't mention Rob Wilson before, but he also had some good comments. We've made from version 15 version 16 so far unchanged, amp ting period, there's other minor items being worked and Alex's is the process of spearheading their reply.

H

Comments on that also one thing that's highlight is the unchanged capability marking has been deferred to a future draft ballast is talking later in the session about alternatives for this needed capability beyond that, going to neck, confident, confident medications working to the last call I think the numbering is off, it's actually nine to ten, and we have tricks to non-normative a script uploaded to validate the examples and get a biggest unresolved issue is that there is a question of what's in the abstract and info. Multiple proposals are out there.

H

What's their will salute whatever people think is the appropriate way to include it.

E

It's it's fine with us, however, that gets.

H

Broken out last things net comp rest come from note if there's been minor tweaks and many updates are needed. We're waiting to focus on this after the the complete last call. People, of course, are willing well welcome to make any comments any time, but I think that once these first set of drafts complete work last call we can start to get an arrest combination to you to transport I.

C

Ask a question about that: I on the previous slide, when you're talking about to the script to subscribe notifications. No, you don't actually go to the previous slide, but you were saying that um the DS dscp option was effectively identical to H, to be two mechanisms or very similar writers, modeled after kind of actually.

H

That the D of CP, the waiting okay.

C

But my thinking is that I'd, you know because of that, maybe it would make sense for us to look at this rest cough no notice trapped. We don't know so we have to take it to last call, but at least understand that you know I have, for instance, two-week review of it or something like that before we complete the last call of the existing drafts, or does it make sense and could I just worry that we might be missing out on I mean? How sure are you that this is implementable?

C

Is the question that oh I'm.

H

Sure that the the waiting and the and the dependency are implementable, because it's a direct mapping to what's an HTP to so I'm, not at all worried that that is going to be an issue. We have early code that doesn't it's just a straight mapping into existing constructs. Okay and.

C

Then the second question would be: how long do you think it would take to complete this work when might not be ready for less cool yeah.

H

The hardest part- and it's been a hard part for a couple of years now- is that we've been trying to enable that seamless transport of G RPC across this, and we've done some tweaks a couple years ago to allow G RPC to be transported over this draft, for example, moving from a get to a to a post model and we've never really gotten the validation from others that we can make sure it's seamless with with chair PCOR blocker really has been.

H

If we want to make sure GSEP, G RPC gets transported seamlessly, we don't have anybody who's willing to validate that. This is a her and that's been a blocker for a couple of years now, so that's not the problem. It's it's not! We got slowed down because we couldn't validate that firm requirement.

F

H

Net cough notification, messages, there's been an update and two big changes is there's a reduction of two header message formats to one we could always break back to a two later, but working with one seems to make sense until we we find that people want to split back to two. That's for the biggest part. The other part is that we've been having discussions with people over in core and Komi and with signatures, and there was a desire to go ahead and make signatures a footer, rather than be something in the header.

H

The reason is that when you sign something you want to explicitly sign the header and the body as defined in the footer, so people have asked to go ahead and move the signatures as a separate footer in order to make it explicit what is being signed. We expect additional updates on this based on stuff going on in comience Ybor, but this is, is the probably the biggest change other upcoming dialogues beyond. That is that there has to be something on the capability of receivers.

H

People like mahesh, have seen this with some of his work in history. Is that we starting to get to know, have to know what is the capability, the receiver, when we're trying to push stuff to it? So that's one other thing: I expect to be in the dialogues in the coming weeks, and so, okay.

C

Sorry a couple comments, so this edition of the footer I think I'm. It's a good idea, but I think this is an example of something that's been added. Without mrs. Flay going for the working group, a proposal that was brought to that list say: I looked for it on the mailing list. I couldn't find it all right. So.

H

C

Be cautious going forward all.

H

Right, that's a good comment. I thought Hank and put it out there on the list. If he hasn't, then then I will work with him to to do that. He's gonna be pretty the next draft, but I certainly don't want to do anything. That's not in the list and Hank is about to do this. Update. Okay,.

C

And my second comment is: it was a contributor I think you need to change your import from being the rest, cough yang data to yang data extension, the new draft that was just adopted by the net mod working group.

H

G

So, just one quick question: have you looked at the size, the data for these sort of telemetry notifications relative to say what gr PC would generate so I know that I'm Rob's going to be late, I think and he was talking to router work Europe. How they've tried to optimize the size of the messages to be as small as possible to get the most States rough. So just wondering if there's any competitors I just see, there's a lot of fields up there.

G

I just wonder, is that remiel off to overhead in terms and size semester's, absolutely.

H

The question is: what is the overhead this implies? Most of the objects in here are optional and again the people who have been pushing this again are in the sea bore side of things, so the the question of efficiency is is going to be one that is mostly relevant based on what Hank and seaboard and Coby people have been looking at.

H

I am believing that the proper way to at least spec it is to get the fields identified and later we can go ahead and say: do we need a single, bundled message and look at efficiency that way and identify the standard headers that are there so so there has been some work a while trying to get down to the standard fields that are identified before doing a detailed analysis, and that detailed analysis would probably be for specific transports rather than general yeah.

G

I think it's just be interesting to see what that size difference is absolutely.

O

Great yeah, so Rob Shakir, Google I think it's fundamental to how to do that. Analysis. That was like.

E

O

Sorry, maybe I'm not tall enough for this microphone and I. Think it's fundamental to do that analysis. What we've found with designing alternate solutions to this is that we've refracted a few times due to getting that efficiency. Actually, the deployability of it depends on having efficient, efficient encoding and even it's also probably not really technically correct, to say what GRP sees as a general thing.

O

Encoding is because the that you can design in different ways that we've gone round analysis of self-describing formats, we've done mouth value, with compression and kind of got to a few different approaches that give you could be better scalability, so I we I can probably share some of that analysis of interest just.

H

One last comment: the version three really was not intended to be a separate version. Three was supposed to go into Hank so shortly we should be having a lot of the discussion, so apologize for uploading it before the discussions and completed great.

C

Thank you, Thank You, Igor,.

K

K

Thank you. Thank you. My name is Inigo Riskin I'm from Hawaii, and this is basically effort of young, whose design team one of the things that we are. We were discussing on our bi-weekly medians and.

K

There are my co-authors on the screen and we basically also discuss this idea with other folks like Joe, Harper and Angie Biermann and Rob Wilson. Basically, basically many people were involved, so I just want to warn you that this might sound a little bit strange okay, so we present it for the first time. Please be open-minded.

K

Okay, so basically the whole thing: what is all about that proved to be very successful and useful tool for use cases when a client can control network in interactive way. Basically, the client asked for certain configurations then basically pick up certain data. States analyzes data States cause on our pcs. Whatever then ask for more reconfiguration so forth right so, but the client cannot micromanage the network every single behavior right, so there are always things that network has to perform while client is not looking.

K

So what we are trying to do is: is there any way to control the behavior of the network when it works autonomously, but still provide a way for a client to say something about how this behavior has to be done?

K

Okay, so and that's the objective basically is to control closed loop automation by configuring, standard, hicieron, condition, actions and pushing them to the server hook them to define and specify two ends and basically pick all this request for reconfiguration : RPC, getting data into these little scripts hukum to the events and condition their execution based on current or historical data states.

K

Okay and basically, what we are not trying to do is to you know, invent a new scripting language or scripting environment. Our goal is just to standardize a simple way to configure this given condition actions statements and, let's Sarah whatever he can do- proprietor lots of proprietary in order to trigger this executive execution at proper time. So, for example, if the server supports a Python or particular junior script out a script environment, it is possible that the server will take the configure, TCA and generate out of this.

K

You see this little script and to look at them at proper times, but basically this is how this is done. It's outside of what we're trying to suggest.

K

Okay. So the good question is: do we actually need such a serious at all and what we think is that there are use cases where it is actually quite useful, but to do like, for example, that could be events in the network. The responses which could be very well understand before those events happen and the client may simply say you know what in case you see this event, please check space, ABCD and all of this. If this please do those other configurations for me. Let me know if something happens, but otherwise don't bother me.

K

So this would be one thing right. The other interesting use case is that sometimes there are simply no time to waste on network or client communications right. My favorite technology is that say if you have, if a battleship is torpedoed, you know the crew is not expected just to report this little telemetry to the central control and wait for instructions when things will come there, but the ship goes down right.

K

So the same logic may apply to the network say whether the connectivity is restored within, say, 40 milliseconds or we don't say 30 milliseconds may mean 10 millisecond difference and for a client like a high-frequency 3 there, it's literally may mean like millions of dollars.

K

The other thing is that are what we think, that the controller could be more scalable and take care of much more details, and you know things on the network. If the controller can delegate certain, you know decisions to subordinates right so, for example, say me, I'm, human right and if I have to control my blinking, breathing and digestion, I would probably would not be able to give this presentation and listen to your commands right.

K

So so it's just like whether you want to have SEO and which controls every single member of staff or you have you and it has his lieutenants and whom it can delegate certain. You know, logic to and certain decisions to make, while taking care of like a high-level decision. Now and finally, there are many interesting application that can simply form like a free program, all logic and push it to the server and have executed to see what all kind of what-ifs, for example, within the ECA.

K

You can configure some little skill, basically saying if these things go down, what happens right if any link on the network goes down? What happens which services will be protected? Which will be recovered, which will be not protected or whether maybe it's too fearless emergency, so things like that could be done if the client has a way of you know, form some program or logic. The logic push it to the server and sharor just supporting the model and me making it possible to interpret this volchok and knowing nothing else could actually readily provide such goals.

K

K

Ok, so basically he sees have like several components. One important component would recall policy variable. It's, maybe not a good name, but this is something that we want to call the ECA State CST. It is some result of condition, evaluation or action execution, or tell that you can remember and use in condition immediately within the same ECA or maybe it between essays right.

K

So, for example, if you want to condition a certain action like reconfiguration based on not a current data state pass a median data state or certain period of time or the rate of change or velocity the change happening right, then the PV would be the place where you keep evaluating and keep modifying this video. And then you can use in the condition, expression and policy variables are we defined?

K

They could be just like C variables that could be global or local and local could be dynamic or static, say the local pee-wee's, their only scope to a particular CA and they are not accessible from other, particularly CA, and they cannot be accessible from outside of this ECA and the global views are those states that could be shared between ECA. So one is hit me. For example, computer update this state and others can use in condition. Expressions to make decisions eager can speed uploaded.

P

Rick Tyler Evers. A lot of this are really support. This work, we I some works going on in the DTN working group, which has been brought in by some of the space guys because, although they're not using net comp and net mod for this they're, already doing this with existing spacecraft, you can imagine you launch something out of Pluto.

P

You need it to react to events and manage it itself, because your round trip delay is quite long, so there's a whole body of work that is already at the IETF on this I'd really like to get together with you, because we're doing it without that net Kampf, richness, I'm, really wheel and I've mentioned it to Kent and various other people. Rob, for example, we'd really like to take the work we're doing on ECAs and make it fit well with the Netcom from the young models. So I think there's some real crossover.

P

It is a very complex environment. There's lots of rabbit holes to shoot down, but I think if we can scope the use cases down to something manageable, I think there is something worth doing here. So if you want to grab me afterwards, I can point.

E

K

P

The work we've got already and try and get some alignment so I just I.

K

Would like to finish that, because what we're trying to do is to actually to scope to not so much thing, they're called but too young and all the conditions and actions that we allow in DCs they're, strictly exactly the same that the client has an access to. If the client would do it interactively.

K

Okay, there is no it's just like your usual get data edit config all RPC make a subscription remove, subscription, Center, difficult stuff like that, and nothing more than that, so it's just basically taking whatever client can do interactively and just by them in this little script. So that's why I hate the policy award, because, as soon as it is pronounced, it seems like to be a course on ITF everything to those policies. It inevitably feels so so far. That's why it's maybe a proper call.

K

It's like a easy escape, but but that's another story right so so again, you see is is has like three components except for PBS its event. Condition and actions event could be anything that, basically, it's either explicitly defined by one of the models that server supports right or it could be a subscription as a young to subscription or smart filter subscription.

K

Basically, what we're interested in is that just the trigger the spot recur and in basically that's why we think it's a general generalization of and push that this trigger does not trigger a notification in, like in case of young push for a smart filter. Instead it it does something else. What like, for example, network the configuration, but otherwise it's basically the same as the trigger or explicitly find the web. Now condition. Is it's a logical expression.

E

B

K

Minute so condition is a logical expression which is either a really related to true or false, and it could be either express as an XPath expression on assumption. The server supports, XPath expression or you can build up from. You, know, simple comparisons, and here are upto a logical expression and last.

Q

K

Again, the actions are limited, so it's not anything. You can do it's only limited to your traditional, like napkin style. It config get data, call RPC things, but, for example, unlike Smart Filters in the notification you can set not just a current data state but, for example, historical data, a state or any derivative of that.

K

So because we have this a luxury of peas to provide right and- and you can obviously, you can share conditions and actions between yes and you can actually change yes, one after another and call one is a is from the other. That's all yeah thanks a.

F

Question Tim.

J

Kari Nokia just a couple comments. One is I, don't know as Juergen seen that seeing what you're doing with respect to that is he weighed in at all? Do you know your control order he's online, but.

C

J

The reason why I asked that was because an L map they created a gang model already that did similar types of things and so I'm just wondering if there's a duplication here that that can be reused. The other question I would have is I know that in the net mod group, there's the finite state machine model and I'm questioning whether this is the duplication of what they're doing there I'm not saying I agree with brick that you know this is important.

J

Work I'm, just wondering if it either hasn't already been done or hasn't already been being done somewhere else in the net mod on one of those two things right.

K

So I I didn't talk to you organ yet, but I did talk a lot to ng, beardman and and basically his opinion. That's exactly how she sees policies based on that wolf, young, okay, so and say he in his opinion. This is like a simple way to actually push policies, whether we call it e CS or not, and it's just taken all the riches of then that conn-young modeling that already is in place and just them in a programmatic way right.

J

So I, like I, guess my my statement or my comment. It is is that before you get too far along there, I go look and see what the L map guys did and also what this.

E

Sort of the the.

J

L mile they've already done it as part in RFC. It's the information model that includes same type of a same type of approach. To do it and it's been tied into the I ppm work for performance monitoring, and you know Diagnostics and stuff like that, that you need to do these actions all.

K

J

And it's got the workflow engine in there, as well as the work that's happening on a net mod for the finite state machine. Sure.

C

And I was gonna mention the same thing that you really need to take a look what's going on in that mud, I'm working with the finite state machine draft, that's there that's been presented in the very next session, so you may want to go to this. This work may go there, I'm, not sure if it fits the Charter in its working group.

P

Just a quick, Rick, Taylor, quick point to the chairs I think that this the fact that this work is sort of cropping up in other working groups who sort of have a need for it I think either Netcom for net more time. Probably net mod I think need to own this to stop us all, inventing it in our own working groups again slightly differently, because you you look at their conference. A oh well hold on I can automate some of this and then we're here again.

P

So I think somebody needs to grasp this and own this properly. So.

C

B

All right, I will be talking about binary encoding.

B

Really, although the title says binary encoding, the idea is that it we want to introduce the concept of being able to negotiate an alternate form of encoding.

B

So one of the proposed parameters.

E

B

Say that the URI would allow you to specify a comma-separated list of encoding, so one of the suggestions coming mainly from Martin was, and that this is something Andy had also proposed- is instead of having a separate activate that both the client and the server advertised the list of encoding the client does it in a its preferred order, where the server does it in a random order and the client just picks whatever the next encoding is, that it likes and it's sensitive in that format, and we are willing to adopt that and drop the idea of activate.

B

So what is being encoded? So there was a bit of a discussion around whether it makes sense to do encoding above the messaging layer or including the messaging here. So this is relating to figure one in RFC 6241.

B

There are, of course, pros and cons of each if we go everything above the messaging layer, which means keeping the RPC in the XML format, you don't quite get all the benefit of encoding, say in a binary format, because you have to do base64 encoding.

B

The disadvantage is that now the messaging layer has to be defined for every encoding mechanism, so this is something we we can take it to the thread, but then in comments on what would be the preferred method.

B

Next are these suggestions on encoding formats? There are several that are be that people have suggested I just listed a few of them. The question the first question is I think that Robert Wilton asked us how to track her visions of an encoding format. I think the answer coming from Martin was well. It will be just another string specifying the version number. The second question related to do.

B

We need an identity definition for each one of these encoding formats, I think again, Martin responded and said that we don't necessarily need it if it's registered in IANA, it's an encoding format.

B

Next restaurant support for encoding we currently list yet the capability and- and maybe it's my impression but I could get it wrong- is that the content header in restaurant would allow you to specify the encoding that is being used now, if there are other implications as a result of it that we need to be aware of I would love to do if we need to know or if there's anything else, that from an importing, we need to specify in the draft itself.

B

Question on notifications support for it certainly talking to Eric about what the impact of the change in encoding format is. The idea is that the time we change it for net in the net concession would also impact the publisher, and the idea is that, within the subscribe notification we a the publisher, specifies the encoding that they are going to use right did I, get that wrong. Correct, okay,.

C

As a contributor I think that depends if it's a dynamics, description versus a configure description with a dynamics description. You pass the encoding as a parameter of the configured description, both encoding and protocol.

H

The the bigger question when we were talking we'll get back to that was it's not just for subscribed notifications. It also impacts fifty to seventy seven as well, because it's not used to being able to handle changes to notifications underway, so the breadth of what's impact. It includes dynamic. If there is a change after the subscription has started.

B

Alright, so I picked on the fifty to seventy seven. Maybe the agreement is that we won't be able to support fifty to seventy seventh group, all right from next steps perspective. It's to update the draft reflecting some of the comments that we have already received on the mailing list and then ask for adoption. Once we have updated the.

L

Draft questions you have a comment on the on the net called drafts about the encoding. Can you speak up.

L

Okay, so can you go to the next smile, maybe yeah?

L

So if you just encode this stuff within the RPC, so, first of all, if it's a binary encoding, you would have to somehow base base encoded, base64, encoded or something that's correct right. So then you would have the open RPC tag and then a blob of base64 data on them and the tag so that doesn't match the XML schema defined in 72 forty-one.

L

So you would have to have a weird XML or your XML parser would have to be prepared for getting data that doesn't match the schema and decode it and then do something about it. Okay, all right, so I think that the only way that would work what would be to actually put the entire session in you know binary coding and do that including the message there.

L

Okay, and that goes with I mean you have the same issue with notifications and so on it. You just change the encoding of the notification body. You know within the XML or JSON it's gonna, be it's gonna, be tricky. Okay, right.

B

I'd be I, guess what was influencing us was the fact that she bore, for example, doesn't necessarily talk about the messaging Claire so we'll have to, in addition, now define the messaging layer for say, see more as an encoding format.

P

Rick Tyler, this might be a naive question, but if you're changing the coding, including the message layer and I, take your point about if your base 64 encoding binary within your XML fragment and you haven't, got something that validates until you post process the internals and then run it again, it's no longer net conf, it's another yang supporting configuration protocol like restaurants or Siebel comp for whatever. So why have different encodings for net comp? Why not just say we'll? Do a binary pump.

B

Probably has to do with the adoption of Netcom protocol itself and the need for a more compressed form to transmit the data. Okay, I.

C

Think you said it, but I mean rather than switching the encoding switching the protocol yeah.

H

M

I was actually gonna respond to that Jason.

D

Turner, because.

M

I think I think the intention there is that you're still encoding the OP, our pcs and all the operations they are neck off so still net comp is just in a different binary, encoding, yeah.

P

Sorry, just responding Rick again, the rest confer is pretty much worked. Example of that it does pretty much everything net golf does it's just got a different name and a different encoding, but it's it's still. The same old are pcs and it's the same shape protocol. You know we do the same things I. Perhaps it's just semantics, but I don't see the point of just encoding the content and leaving the messaging in the original encoding, but I'm all in favor of keep the shape, because we all know how this works.

P

Let's not invent something wildly different, but I think we're having the problem in the wrong place.

O

She can and be interesting to see for the for the binary encoded approach, however, and I'm having to do some unmarshal in of basics for Oh ever ends have been what the performance of the underlying transport is at the same time right. So this is kind of oh well, we'll make the message pay the mortgage. If we're in single stream SSH lend it like I'm, pretty sure that you're not with the throughput limit is not going, is not you're gonna run into the throughput limit of the transport any large data set anyway.

O

So that point in debating about exactly how we encode this thing. It's all them the point. We should maybe just design a protocol that works.

C

Okay, so couple commas: first, as a contributor I think that the desire for wanting to binary encode the data is primarily for high throughput or metabolic messages, mostly telemetry, analytic type data which makes me think about the.

C

Q

Any change clarify the relationship with a young coach Maxim chart actually in young coach athlete, defines a push change, update education. This is a actually application, specific notification, so we compared this application specific and education with the non-repeating with defining our child. Actually, we can see the three main difference. The first days. Well, push change updated. They focus on that pot. Separate is a subscription basis.

Q

That means that they only can be used to send a post subscription based or contents, and you go by the client and for the the notification we defined in our child. Actually, they can report the data change event associated with the market subscription of the receivers. The second change here is the push change operator, actually application, specific girl and but the napkin paper change actually is the general general hovers notification so no need to tie to any submission ID.

Q

The last change actually is for push the change, update, early focus on pushy, entire or poaching, with the datastore condoms at their for the networking we defined in this job. Actually, they can report data store metadata like who make the data store chain. You are at the name, a specific location or face other configuration changes. That's.

H

Errand-Boy, just to another thing worth adding in the differences is that the the push change update is a gang patch operation as well, so if they finds a delta to the data store rather than the objects yeah.

Q

Okay, I think for next ever I, just wanna cater to feel the sense of the this idea from the room.

J

Q

Could decide where whether they fit into this we'll help whether we need to extend out this kinda medicine yeah? That's all.

J

So Tim Carrey Nokia, well, I! Guess you guess you got one thing for sure that we kind of missed when we did the nmda. You missed the data stores in 60s. So my question is: is that why wouldn't this just be a biz to that RFC instead of a new RFC? Since that's the approach that we're taking with other pieces as we're correcting for nmda, we just busy I'm asking.

C

It's a good question: I, don't think we need to answer that right now, though, in terms of like bringing this into a working group, we first need to discuss it on the list. Some I mean there's this draft just got posted near the end of February and there's been no discussion on it. Yet so I know we're presenting it here, but we need to take it to the list and discuss it more there. But if we were to move forward with it, then that could be something that we dismiss.

E

C

It's an option.

G

Rob Wilson Cisco, so I think I'm. Looking this I'm just wondering whether actually the yang pushes a better generalized mechanism to doing this so I question whether this is required. I think is my thought.

C

So Robert Robert, it is a notification and notifications- are pushed three and push.

G

Okay, to clarify and I think that I wonder whether you want a single notification to say that the configuration is changing, the operational State datastore or whether it's better just to have a generalized subscription on that date, sort of configuration nodes and then you get told whenever any conflict change happens, you get given the diff the patch anyway, so I. This feels like this was before you had things like yank push. This is summary card coding.

G

A particular notification I feel that subscriptions and yank push is like a generalized mechanism that you can just choose to subscribe to. Whatever you want to, and should this be just one of those things does it need to be special cased.

J

So to answer Rob's question a little bit is: is that I see this as two problems right, one is broken RFC right, because you got you missing the data stores that are explicit in it so fix the RFC. The second is that you get a new notification right, and the question is: is that new notification do you need to do you want to tie that to a push mechanism, or do you want it to use the generalized notification mechanism? That would be?

J

You know, fifty to seventy seven or something like that and I think that can go on the list but fix your RFC and then ask if you, if you need to have a new notification mechanism to be part of a stream and I think you know, then that could be its own own draft or maybe in part of the biz, but you know certainly fix your RFC.

N

By Ericsson I see value in this that you are trying to transfer the who changed it and also say some other meta data, for example. Origin could be changed. These are not present in yank push. On the other hand, you are, you are missing the subscription. You are missing the filters, you're missing, store configurations. You are missing a lot of things and if you start pushing all this data with additional metadata, that will be a lot and I. Don't I, don't see it worth duplicating really the functionality I.

Q

Think the narrative out here actually is focused.

J

On the more internal but.

Q

Therefore, she defined a young boy.

J

Q

After they pushed the biggest all contents out, yet they didn't include many parameter, but III think here we try to generate.

J

Q

Panel application so.

B

These are different powers actually.

Q

Cuz I mention okay,.

C

So Thank You Jen- if you could please take some of these questions, let's start thread so on them and and then we'll close them. They're great.

C

And now Rob, thank you.

O

So I'm going to talk about GMA, which is a an alternative to the Netcom I, was asked to come and present here after submitting some wider after we submitted this draft and have subs talking in RTG WG, and the motivation for talking here is what to form the ITF about the development that we're doing and and the implementations of it, particularly as this alternative feed some of our development and deployment experience back.

O

We have this introduction some scale, so we've kind of been through a bunch of iteration of making it work and it kind of feeds back to some of the binary encoding discussions and comments. I was making and invite.

E

Anyone who's interested to contribute.

O

To open source projects in terms of specification and code and when not asking for adoption here so I'm sure it would be controversial if we were so, we we've maintaining this outside of the ATF and we would we'd like to keep it that way. Right now, so GMA is a protocol. That's used for both configuration, manipulation and state retrieval from a device. It's all the data, that's handled, then it must be described using a path that consists of a name and map of strings of attributes and there's no requirement for that to be yang modeled.

O

It just has to conform to a tree. That looks that has those attributes and we wanted to do that, to make sure that there was some flexibility in the modeling language that we could be used for payloads and it's built on top of G RPC, which is a framework that the Google open source and it's managed in the CN CF. It's an RPC framework that uses HTTP to is the transport. So it's it's coefficient streaming involved in it.

O

There's the the RPCs that you can describe in the upper co-writer user request, response or service dreaming, client streaming or bi-directional streaming so where both sites can can send their multitude of messages. The multiplexing of those are pcs is over a single IP Channel and the the kind of implementation looks after a lot of the channel management. For you and and so as the producer of data you send on to multiple channels and HP to transport. Certain delaying multiplexing in our management is looked after.

O

Service definitions are in Java, C written in in products bar, so the genome is specification is, and the encoding that's used on the wire is is proto inside of that indiana. My then we have a bit like the encoding. You know that we've been talking about earlier, the same thing and can encode into binary values which are part of a binary, serialization or JSON or ascii text, etc.

O

So jenamae has for our pcs, it's relatively simple, and it's got a set, obviously, which does the manipulation of the writable state of the target. So this is that this is has a simplified transaction model. On top of the the the way that the one in it compacts, so we assume that the we require that the client pre stages, the Save Changes they're, going to be made in a single transaction and then sends that set message as part of the unary set RPC to the device. The device then applies.

O

The entire set of transit set of changes there within that that message or rolls them back, and we found that this gives us a bunch of simplification. On the client side, we don't have to keep track of multiple candidates there happening or long-lived candidates and in in our change workflow and in the change workflows of those that we've worked with on this project.

O

It's it's as soon as the machine is making this configuration, changes and really get bored and walk off in the middle of changes, so it can be trusted to have compiled the set of changes that it wants you to a single transaction. The SUBSCRIBE RPC is, then, is a streaming RPC from the target, which will call that the network element the device to send state to the client. We have immutable subscriptions, so they're created with a particular mode in this particular set of paths.

O

They can't be changed during flight and they there's three different modes of those: those of those subscriptions to have a stream which is a long-lived push from the device. So the client, the client, opens a connection subscribes to a set of paths, and for these things, then the target continues to update those paths according to either events or okay, news based sampling.

O

We have a poll so we're in for the paradigm where we would like a client or to still be able to request when it gets sent data, and then we have a once, which is an efficient way to do a get without requiring the target to be able to marshal all data on. So since you start an iterator and you walk through the tree and use you advertise everything that matched the paths that you're specified streaming.

O

Data as I mentioned can be sampled, so where the device takes a sample, every n-no seconds or whatever frequency is specified in the in the IPC and then sends a value or it can be unchanged. That's when the value changes, a notification sent it sent or a mix of those. So we have this mode called target defined where basically the either the data model or the type of the that the server implementation determines how best to send a certain leave.

O

So in that kind of case, if you have a counter, then it sent us a sample version. If it's, if it's something that's an event base, then it the Target Center as an event, and that gives us the most efficient way to be able to to choose how to to allow the target to choose how to to optimize for the the tree that it knows about and Indiana my and particularly for subscriptions. Then the target always time stamps the the packet.

O

So this gives us the ability to rather than SNMP, where you have oh I pole at time, X and then I, don't know where I get a response at time. Y by have to assume that the the sample came from time. X the the timestamp at the device tells you exactly when it was taken. So you know you can continue to build a more accurate graph and some of our telemetry.

O

It's particularly noticeable when, when you compare their telemetry data to the P date since.

G

It's just a quick clarifying question. You said time stamp to target your reading counters from the hardware. Is it the time stamp? You want the counters read from the hardware you expect always when they get put into a message and sent know.

O

When it was taken from the hard way, so it's when.

G

The value changes is is effectively when you're looking for so.

R

G

It when the value changes or is read from somewhere is the quote: it's close to what actually changes. What you're after right, so.

O

If you that way, if you have more, you know caches inside of it device, you can still maintain their cache. You know, okay, it was taking at time X and the client, even whenever the client comes to retrieve it, it's able to determine what the when that sample was from equally, if you've got leaves that are populated with you know, likely bgp session that went up or down if the timestamp is when that happens.

O

So when a new client comes along its able to say oh, it does happen time X, you know many many moons ago, rather than it was a new event occurring right. Then.

O

We then have to to other our pcs a get our PC, which is designed to be a snapshot of state at a particular time.

O

It's particularly using the configuration scape retrieval where you know you want to serialize the configuration into a message and send it to the to the client and but we've we've kind of debated and there's some talk in the specification around the scaling implications of this.

O

If you have a large set of data to be able to just a realize there can be some, it's not sufficient, just putting them into these individual notifications, where the targets able to choose how to serialize for performance, and then we have a capabilities RPC, which is just used to understand the both of encoding. So we support post buff and an ASCII and JSON as I said and then the models that the device supports. So this allows you to know what schemas you need to to understand.

A

Why you mentioned that he yang is not required, so do you have any other means how to communicate the model supported by the target yeah.

O

So we have, we have models that we've written in prose. Above so we have for further the encoding efficiency we actually take a young module and we can machine translated to protopathic gives us a way to build serialize directly into binary protocol on the wire but yeah. Then we have parts of the schema that are written just in proto, for particular things, Jim.

J

Carrey Nokia I'm curious. When you say you do the civilization from the from the yang into into the protobuf. How do you deal with all the semantic elements? Is that take into account? Because you can't do that and protobuf right? It's all syntactic right! So.

O

The the schema is, if we have this debate in nazi of UT's. Well, it's if the for schema validation and for compiling the data tree and validating it, then we do it in data structures that are aware of the yang. It's an item proto and then they have proto. That's then the proteins just is used in those cases just on the wire or so.

J

It's all syntactic, you lose all the you know all the semantics that go into the richness of the yang right. Yes,.

O

So you can that we have libraries that serialize and deserialize from proto back in to data structures that are able to do to do theater.

J

At point, you lose the rich rich, so the module- or you just reconstitute- you assume that said the definition of the modules right like if you're dealing with the winds and ifs and stuff so you're, trying to reconstitute it at the back end. It's not on the wire you get as.

O

Both ends have to.

J

Have the end so.

O

I think it was separating the use of approach versus schema language, and the proton yang is a schema language from a serialization. So we have. If we write to schemer in prototype, then yes, of course, we don't get those things, because proto doesn't support that. If we write the schema module in yang then as long as there's some code RT.

J

You need both ends have in the yang, so you can reconstitute that semantics. Okay, but.

O

But we I mean, particularly for telemetry. We haven't really seen that there's a huge value in having the collector layer have any awareness of the schema, because it can't really do anything right. It's like a value gets sent to you and it doesn't comply with the schema. It's not really like you. Can you you're not going to say? Oh, no, that's bad telemetry!

O

Please send me something something different so having that split of not having time having data structures that are not schemer aware in the right places has given us quite a lot of ways to optimize for those high-volume cases without having to carry a bunch of metadata around okay, and one of the things that we've tried to do is make the the genome I suspect, as minimal as possible, in terms of having only the things that we think are common common across multiple use cases in the spec and then have this way to to extend the protocol.

O

So it's something that can be extended by you know both the core team, as well as just opening a github issue and adding to it. The extensions are a carried per message and we've using them for things like proxying, so where you actually talk to a target through another another proxy, because it's outside of the same trust domain or in some cases we have master arbitration between different writers. So two writers do a master election and they want to know which was the latest.

O

Only the one with the latest election ID should be allowed to write in a splits brain scenario, and so these these extensions are carried from message. So some of them are relevant, obviously to only set RPC, but it they can be carried in any message so that the protocol can be extended. We have both well-known and extensions that are which, which are defined within the within the spec, as well as registered extensions whereby an ID assigned to them and the contents are opaque for for arbitrary extension.

O

We we've tried to keep it such that these are only used where the existing our pcs function is really being extended. It's not new functionality or fundamental change to the RPC, because in that case, it's better to run multiple services so that we have to find expectation as of this two, so you can run multiple GRC services on the same port and and have these extension, our pcs being listed this separate service, it's something to speed up, may be good I. Think.

E

Sometimes something.

O

I've kind of mentioned this is this is something that's critical for the for the fidelity of the flama tree, which is important to us. We've been through a few iterations on encoding of values, so we started out with Jason encoding values and found that this was this introduced unnecessary complexity, because things like integers becoming strings meant we had to it then unmarshal them back into what they should be.

O

So we've now adopted using native native protobufs types for encoding and mapping, things like decimal 64, which don't have a have approach, both native type and on into specific messages. This was the point that I was making earlier about on the wire efficiency. The volume of data is is pretty huge on on scale systems, cures and interfaces, even to just that set of counters is a large amount of data and things like the BGP ribbond device rip end up being large as well.

O

So we've had a couple of approaches, both through prefixing of data, so being able to build a notification that has a common prefix across all the paths in it and then use of the generated prototypes on the wire. As the to be able to aggregate sets of data, gives you a significant significant advantage on the wire and that that's turned out to be one of the the scaling limits that we found in the system is, is how is the amount of data that can be transmitted through through their job?

O

We see on running on the network devices a development approach, I've kind of talk to this we've got specification. That's in github, then there's reference tool, implementations which we've open-sourced so there's a CLI tool that we that we use for interacting for device. There's a target, there's a fake to be able to. You know, test implicit implementations against it for that for the device and telemetry collector implementation. It's mostly open-source.

O

It's almost we're still in the process of getting the last few parts of it out, and we have a reference server implementation as well, and we're thinking we're starting to also develop myself, combines tests that will be run written. There will be open source and published such that try and build an ecosystem so that people can actually just download this and run it rather than half the kind of overhead of directly trying to develop. I think a bunch of things themselves and his for future posterity.

O

A bunch of links to some of the things that I've talked about. Alright.

C

Thanks for uh we don't have any time for questions in else.

N

Thank you, so yeah I'm I'm Alex came from Huawei I'm, presenting the update on a smaller graph comparison of nmda data stores updates from the last ITF 100, if not run, on a run, basically again, just to recap, this draft defines basically just one RPC allow us to compare and in the a data stores. Basically, the issue is that, given that there are multiple data sources, data source with data values propagating between them there's the issue and what happens? Maybe when, when finds data values, don't propagate correctly or take longer time to propagate?

N

How would you? How would you be able to troubleshoot those other things so really for those items believe it's convenient to have a comparison or discrepancy, detection or differing basically type of operation? So a couple of discussion on this son on the mailer and based on this basically posited just yesterday, actually in Eurovision with a number of changes, one thing: basically what has changed and since Singapore is we added examples into the draft? Also there was the discussion concerning.

N

Should this be called discrepancy detected or something else so baby be removed, the discrepancy, detection comparison and dipping to make it actually clear in simpler.

N

If you will and then there is one feature within this, which was an option feature before concerning a dampening feature which basically and was intended to to report differences only when they persist for a certain amount of time, so it could basically specify the only bit, even when you see a difference done true, probably immediately only when you see this persisting for some period of time, feedback was from the was on the mailer to rather busy move this out. So this, basically, what we have done actually right still consider.

N

This personally actually is an interesting feature, but believe this is not put into the into potential futures.

N

Another feedback was to also mention the possibility of applying, in addition, pre-filtering step to exclude data from the comparison which is not within the scope of both data sources now, basically also added into the draft, and that it's basically pretty much all so. Basically, I guess the things where we are now. Basically, we need to confirm the removal of the dampening as a feature I think from the mailing list discussion. It seems that there's basically the consensus of the working group to do that. One other item that should be added.

N

This was based on a poet actually who made that comment was busy that we need to add a reporting of the original discrepancies. Okay, when there is it this, when there is a difference and that is detected, it is useful to include, for instance, in the operational data store. What was the origin of that which can again help bizzy's explain what is going on, so that is something that will be added and and finally making this still in the individual draft. What we're hoping you want.

L

N

Ask us if this should be adopted by the working group, all.

B

Right, ed and I see Lou getting out so I'm the question of what coop adoption, maybe Lou. You want to say sure.

S

So what new protocol mechanisms are being defined in this document? So it's again what new protocol mechanisms are being defined here? Oh.

N

This is actually go to the backup slide. Basically, this is a this is defined as an arc. We see inside a yang module. Okay, they finds in obviously just to just to compare solid applies to anything that you would run yang. I'll proceed with all.

S

Right, yeah I think it's great function very interested in it, but it's not clear to me why it's in this group versus that mod, since there's no protocol I.

S

Guess I'll be more example said as the burger again I suggest we bring this into net mod and present it there and ask for adoption there.

C

Okay, I guess the question is which workgroup should go to I? Think you have a preference for this working group cause of all the yang push and related drafts, but to lose point it may be better suited for that working group is.

N

Fine I mean I, don't think might call. We don't feel strongly either way. So if this moved from that not sure well, what is the problem.

T

There I guess is, then the isn't.

B

The question for.

T

One it won't be, then we won't make the adoption okay. Well, that's.

C

The room then just a show of hands who's read the drafts, okay, a fair number and of that group of people who believes it should be in this working group versus or like raise your hand if it should be in this working group.

C

Okay, raise your hand if it should be in the net mod working group. All right should go to the net, not working group. Okay,.

L

C

S

Kent or chairs can I ask a question about the last one. You know one minute.

C

S

I'll note that we have time on the agenda in net Maude, shall we take this up in this meeting? Think about it.

N

I'm bothered anger from Erickson and I'm, bringing you a little problem that was pushed out of yank push to make the main drafts progress faster, but is actually part of that problem space.

N

So we have the unchanged capability in the ank push, but we, which means that in changes, will be immediately notified whenever they happen, but we know that implementations will not be capable of sending on change notification for everything. There are a number of reasons for this. Some objects like counter can change very frequently.

N

Maybe the changes are not meaningful, like a small temperature change, but I think the most important is that maybe it's not always implemented for every object that we monitor it and we immediately notify changes about them and, in some cases, hardware limitations might also they are also. If I am on a bigger author than I can send notification about any change.

N

If I'm on a smaller out there with limited resources, maybe say models, I can't do that, but practically this means that, although I say I support unchanged notifications, specifically I'm allowed not to send notifications for anything.

N

That means that client and network management system cannot really depend on it because yeah, maybe this one interesting object, was not implemented for own change notifications, then how can I use it really and and I'm a so metric want to depend on these, so they won't need to know, will I or will I not get not. We unchanged notifications for specific objects, relief or whatever.

N

So, let's document it and there was a proposal based on yang expansion. Statements in the yang push draft that didn't meet with everybody is liking.

N

So the alternative based on some of these requirements is to reviews a yang module, and the main point here from the requirement is that this information, which specific data nodes will send only change. Notifications is both needed both in implementation time and run time. Most of the time, evander already knows that yeah I won't send unchanged notification for counters, but I won't change. Notifications for I, don't know configuration or, let's say BGP peers or changed yang modules are changed.

N

There's some other big changes. Also, some of these items, let's say, can be changed also in run time. Let's a new yang feature can be switched on in run time, so now I need to know, and, and that would might mean that I sales and not unchanged notifications for different objects. So there is separate need for implementation time and runtime information about this.

N

So that's why I propose that we use a yank module to document which objects will send notifications and with the coming draft that I'll present in another hour about yank instance data and how to document yank instance, data that will allow us to have design or implementation time documentation about the same thing.

N

So what I am really proposing is a yang module or that would extend the angle ITF yang library that contains the these Netcom are not vacation capabilities. It will have a set of data, so default capabilities for each module. Do I send notification on change notifications about that module? Yes or no, and if there are some specific object, specific data nodes that behave differently than the yang module default.

N

Then I have a possibility to to mark those ones as well in the notification capability list with no selector and the change notifications, and this last one is just an example of how this would be documented in design time using instance data. So what I am asking is that we need we have a problem that needs solution. That's already documented in the yang push draft and defining a yang data module for this small yang data module, for this would be a simple solution that supports all the requirements that I see it.

N

So I would like to ask for a work group adaption for this draft.

C

So I don't think it's appropriate to like pull for I. Think it's important work like to say it was pushed out of getting push, but this draft was just submitted into February and there hasn't been any discussion on it yet and also I believe the set of authors are currently very busy on a number of working groups are documents that we really should probably see the completion before we bring on any more work to that group of authors.

C

So perhaps we should take this to the list just more discussion and then see a little bit further down the road if we should adopt it actually,.

N

We have offline meetings with those outdoors and most of them self supported it's actually, all of them, I'm sure.

B

They did the question is: do they have the bandwidth to actually work on the document? I.

N

Expect that I will do the major 80 of the work, but that's a question: okay,.

E

This is chaiienging.

J

E

Huawei, though, I have read a job, so this job to address the problem of identifying which objects unchangeable, sketching a sport or not, so you set a small object. Changes are frequent and meaningless. I think a weather set change is mean for an order. It's dependent on with your application and a user needs. So during the your time, the value.

J

E

Object changes frequently might be incurred in interest to some users. So what what I mean is that for running system, then I need a switch? Is that I'm, changing notifications, auto or not can be switched really? I.

N

Think if it's based on the user, then the user can use the subscription parameters to define it. This is more about. Is the note capable at all to send let's say octor in octet Scouter notifications, so it's really server capabilities.

N

Just briefly comment regarding when we like I, think this work is because it was pushed out of the yang push I. Consider this celebrating part of that overall body. Therefore, responding to the question: do we have the bandwidth yeah I think will will will will make the bandwidth.

A

Yogananda on jabber has a comment. The question is whether this is the right solution for the problem.

N

There was a small, simple solution with yang expansions that was not supported. I think this is a good solution for the problem.

T

They're not clear the contributor I believe is a key problem. Right. I would like to have unchanged for every single variable I have in in a router even counters right, because some of the counters are important here. Is the counters number the reset on a bgp session? I care about that right. So I think this is a very important work.

O

We've also have the same problem in jena, my and and the the solution we've taken is a little different. The so we've got a way of annotating in the schema, whether the expectations to say. Okay, this this should be sent unchanged, like the in objects counter yeah. Probably this is true permissions and unchanged, but each beep si should stay. This should be sent on change, but we in we haven't got the sort, the the proposal you have here, of open the RPC and but just don't conform to some of the the request of the client.

O

We don't take. Basically, if you try and have an unchanged subscription to a leaf that or to a set of leaves where it doesn't cut, it's not possible for the device to do it. It just fails the subscription and we have this target defined mode. That says, the client actually doesn't mind how it's set and that the the problem here is that you ain't enter a whole world of complexity.

O

If you accept a subscription whereby where you can't actually meet the request, so it leaves a whole load of compliance and and functionality to solve undefined in the implementation, so I kind of preferred the approach of failing. If you asked for a subscription that the noda isn't able to honor just failing and not opening the RPC at all and not starting streaming.

N

Originally this was information was in the schema, but not everyone liked that. Then some people said that spec change drying time which objects, I support or don't support absolutely.

O

So the the the annotation in the schema is really to say: what's: what's the practical like there was the recommendation or what's the the way that the scheming that knows about this data should send it? The bigger question I have is whether you want to go to this complexity of having of accepting an RPC that you can't actually honor the the parameters of, because that's what you're talking about here, you're saying and someone asks you unchanging. You can actually do it not.

N

Really because what I'm saying is that I accept I say the subscription request for everything, but you have to understand that I say everything. Then I mean everything with these exceptions, so I'm limiting already what I'm.

O

Promising you, but then the the actively our PC is not so the way that we've solved this is they have this targeted, find mode which says actually, as the client I'm gonna, let you choose how to do it and then you you, based on the knowledge Lee implantation which doesn't have to be communicated and in band to the protocol, say what you're expecting if I specifically asked for an unchanged subscription to a leave. So let's say I'm trying to subscribe to this in octet counter just on change.

O

You're going to I'm going to subscribe, you're, never going to send me anything. You probably was better to just not accept the subscription, so it's very clear to the consuming system that it wasn't able to the device wasn't able to honor the contract.

B

Last question so.

G

Ruggles and Cisco: that's actually a question for Rob. So what happens if you can generate Liana change, subscription the notifications, but you've got some quantum quantizing halflings. You might have to change generated notification, say every 50 milliseconds. So how do you get that information to the client that you can do or Chum change? But you can't don't.

O

Change them every.

G

Event is to some limitations.

O

To that so the thing we asked we've asked a lot when we add things to Jenna Mize. What is the client going to do so if you communicate that to the client, it's like, oh, if it hasn't got anything you can do about that's that's all. You can really do so. There's.

G

No real need to.

O

Have that in the protocol it.

G

Is more so that they aware of what service they're actually signing up for? Is.

O

That does that have to be validated at this time like what how does it? How does it actually react to it? So that's a design system, design time at the annotation right.

H

O

So we don't need to carry all the implication, the considerations that the system design protocol the protocol doesn't essentially need to carry them actually.

N

This is yes, this has been no no small part about system design, because we said that the implementation time information is needed as well and that's this is this is the way actually to provide.

O

That one to the implementation time thing I think, is definitely a good idea too I'm just not sure that it's it's required at opened all.

B

Right I think we are anyway over time, so this essentially closes the napkin session.

C

C

How long's the break? Okay yeah, so that nut mod session starts in 18 minutes.

B

C

C

Yeah but the net mod session is in blender him.

C

There you put that into the poker yeah hey. What's up.