WEBVTT 1 00:00:01.589 --> 00:00:02.010 Chaker Al-Hakim: Okay. 2 00:00:02.100 --> 00:00:06.480 Stephen Terrill: Let me put up the agenda, since I have it here and sent it out and then 3 00:00:07.859 --> 00:00:09.510 Stephen Terrill: So can you see my screen. 4 00:00:11.040 --> 00:00:11.940 Chaker Al-Hakim: I can, yes. 5 00:00:14.849 --> 00:00:28.350 Stephen Terrill: So the agenda here was so sad at the meeting and hand over to chuck. Then we've got the architecture reviews. We've got Pam with the policy architecture. And there's two parts there. And that was the only topic. Actually, that was requested for today. 6 00:00:30.150 --> 00:00:32.850 Stephen Terrill: Anything else to add to the agenda that people wanted to take 7 00:00:37.380 --> 00:00:37.620 Stephen Terrill: Good. 8 00:00:38.070 --> 00:00:39.840 Stephen Terrill: Well, congratulations checker. I 9 00:00:39.990 --> 00:00:44.880 Stephen Terrill: hand over to you and I thank everyone for their tolerance of their 10 00:00:47.160 --> 00:00:47.970 Chaker Al-Hakim: Suffering. You mean 11 00:00:48.300 --> 00:00:49.170 Yeah, the suffering. 12 00:00:51.150 --> 00:00:55.650 Stephen Terrill: So with that I'll stop sharing and wish you all the best. 13 00:00:58.020 --> 00:01:01.560 Chaker Al-Hakim: Steve, thank you very much. I do appreciate the 14 00:01:03.000 --> 00:01:08.100 Chaker Al-Hakim: kind words. And I do want to thank you on behalf, on behalf of the team for great 15 00:01:10.410 --> 00:01:14.760 Chaker Al-Hakim: And all the great work that you did throughout the year. I think you put the architecture. 16 00:01:16.830 --> 00:01:30.300 Chaker Al-Hakim: Committee meetings to the next level. And my hope is to maintain that level of due diligence, if you will, and take it to the next step. So thanks for everything. Thank you. Good luck. 17 00:01:35.520 --> 00:01:36.120 Chaker Al-Hakim: With that 18 00:01:36.330 --> 00:01:37.230 Chaker Al-Hakim: It's all yours. 19 00:01:38.820 --> 00:01:39.690 Vijay Venkatesh Kumar (AT&T): Okay, great. 20 00:01:39.720 --> 00:01:40.470 Pamela Dragosh: Thanks a lot. 21 00:01:40.530 --> 00:01:41.610 Chaker Al-Hakim: Chucker and thanks to 22 00:01:43.590 --> 00:01:44.490 Pamela Dragosh: Let me share 23 00:01:45.870 --> 00:01:53.940 Pamela Dragosh: Our wiki page that we put together here every a release here fairly similar page that we have 24 00:01:55.290 --> 00:02:00.060 Pamela Dragosh: So talk about the policy. The, the work that we're doing for Frank for 25 00:02:00.990 --> 00:02:11.700 Stephen Terrill: Gen one one thing. It's this and the the as to as two things right. This picture that we should do for every release plus will come. Yes, will come to this very good. Cool, cool. And 26 00:02:12.810 --> 00:02:14.070 Pamela Dragosh: Yeah, sure. Um, 27 00:02:15.960 --> 00:02:18.960 Pamela Dragosh: Okay. So, no, that's fine. I'm fine. Um, 28 00:02:20.010 --> 00:02:28.110 Pamela Dragosh: Yeah, so, um, for policy, um, again, going back to Dublin, that's where we started re architected in 29 00:02:29.280 --> 00:02:37.200 Pamela Dragosh: The framework in order to alleviated some some major design issues and flaws that were there and the seed code. 30 00:02:38.130 --> 00:02:52.260 Pamela Dragosh: So we just continuation of this work. It takes a few releases in order to get all this work finished and cleaned up and working properly, and the rest of the own app components actually transitioned over to it. 31 00:02:53.310 --> 00:02:58.200 Pamela Dragosh: So when it comes to Frankfurt, there's, there's a few things here and I've 32 00:02:58.680 --> 00:03:11.670 Pamela Dragosh: I've sort of captured maybe overarching requirements that include this when it comes to policy in another team and or another component is affected or if it's something that's just really just the policy framework itself that is making the changes. 33 00:03:13.290 --> 00:03:16.890 Pamela Dragosh: One of the first things here is update notifications and that 34 00:03:17.970 --> 00:03:32.070 Pamela Dragosh: Previously, that was done as a web socket and it was determined that that was was not a very good way of doing that. And so of course with the new the changes to a new API and policies we worked with a DC team who are the primary 35 00:03:33.180 --> 00:03:45.960 Pamela Dragosh: Users of this to come up with a demon D map based notification. And of course, with it being a D map. Now, this is now available to all the components as well as integration testing. 36 00:03:46.620 --> 00:03:51.840 Pamela Dragosh: As far as getting an update when somebody decides that I'm deploying a new version of a policy. 37 00:03:52.530 --> 00:03:59.130 Pamela Dragosh: Or I'm rolling back to a previous version or him completely and deploying a policy. And so this notifications of that help 38 00:03:59.940 --> 00:04:15.600 Pamela Dragosh: Move towards more real time updates for components that are in the process of enforcing policies, which notably right now is DCA through the control loop hat. Usually the other components. Don't need that quick notification, but it's there. It's available going forward. 39 00:04:17.400 --> 00:04:32.910 Pamela Dragosh: As part of the self serve control loop requirements. Obviously, we have a new API with new policies and so we have been working in the basics. But we, of course, as we move along. We want to build more validation tools. So when people upload a new 40 00:04:32.910 --> 00:04:44.310 Pamela Dragosh: Policy, it is valid or new policy type as well as new policy from a policy type. And so we're we're moving towards some very simple validation tools that will help with 41 00:04:45.720 --> 00:04:47.970 Policy designers for that. 42 00:04:49.680 --> 00:05:01.650 Pamela Dragosh: Underneath that policy 1845 arm. This is something that was kind of in there in the previous legacy components. And so we we do view this as as something that's needed 43 00:05:02.100 --> 00:05:14.430 Pamela Dragosh: When it comes to very complex use cases. And that's basically we have three PDP engines now apex stackable and drools and in some cases, you want to have 44 00:05:15.600 --> 00:05:34.020 Pamela Dragosh: Native policies loaded that either run on their own or they run in conjunction are used with with a translated policies that get translated from the telescope policy types. And so we're, we've added some more support for coordinated policies. 45 00:05:37.260 --> 00:05:39.660 Pamela Dragosh: The next one wreck 162 46 00:05:40.710 --> 00:05:41.970 Pamela Dragosh: Okay, this is in which 47 00:05:43.110 --> 00:05:46.710 Pamela Dragosh: I am working with the team and the SDN see team. 48 00:05:47.790 --> 00:05:59.430 Pamela Dragosh: To get their clients to support them in policy lifecycle API. So our first two clients were clamp and DC at that that was done in Dublin Alto, but now in 49 00:06:00.180 --> 00:06:06.090 Pamela Dragosh: Frankfurt, we're working with those two teams to get them transition on and those would be the last two teams for the moment that 50 00:06:06.810 --> 00:06:19.110 Pamela Dragosh: Need to upgrade, although we'd love for all the own app components to use the policy API right now those for right now they're using it. So hopefully going forward. We can pull in more more components in their 51 00:06:20.670 --> 00:06:23.250 Pamela Dragosh: Pocket compliant policies and 52 00:06:23.550 --> 00:06:26.130 Chaker Al-Hakim: Then yes. SO THE SHOCKERS. So, question for you. 53 00:06:28.620 --> 00:06:34.710 Chaker Al-Hakim: The, the two components that you that you just mentioned STC and 54 00:06:36.960 --> 00:06:37.290 Pamela Dragosh: Oh, 55 00:06:38.310 --> 00:06:38.610 Chaker Al-Hakim: Oh, 56 00:06:38.880 --> 00:06:47.040 Chaker Al-Hakim: Oh, so do we have, do you have, yes, sorry. Do we have a commitment from them to make the changes required to support the annoyance. Okay. 57 00:06:47.700 --> 00:06:51.000 Pamela Dragosh: Yes, they did commit to it. It is it is a Frankfort requirement. 58 00:06:51.600 --> 00:07:02.100 Pamela Dragosh: Okay, put it up there. It's a hopefully small t shirt work. I mean, the team is moving along pretty well with that which is probably because we actually started working with them in Dublin for it. 59 00:07:03.240 --> 00:07:03.810 Chaker Al-Hakim: But, but 60 00:07:03.900 --> 00:07:11.730 Pamela Dragosh: What as we worked with them. We discovered while they that the current policy models that they had were not sufficient, and they have a lot more requirements. And so we'd been 61 00:07:12.450 --> 00:07:17.940 Pamela Dragosh: Continuously working with them since since Dublin throughout alto to kind of get that work done. 62 00:07:18.420 --> 00:07:32.070 Pamela Dragosh: And we're about 90% there with that with them. Yes, NC team is much simpler solution. I'm actually meeting with them today to kind of go over what I've built for them so far that we should so far. My team is on target to offer it to them. 63 00:07:32.430 --> 00:07:35.010 Chaker Al-Hakim: And I hope that they have cycles, then to go and 64 00:07:36.420 --> 00:07:37.230 Chaker Al-Hakim: Force the API. 65 00:07:38.700 --> 00:07:42.660 Chaker Al-Hakim: Yes, I'm, what I'm trying to, to understand is how do we 66 00:07:44.220 --> 00:07:48.510 Chaker Al-Hakim: How do we document this cross dependencies, so that we 67 00:07:50.820 --> 00:08:09.090 Chaker Al-Hakim: We don't overlook them as we move forward into their release right and make sure that you know STC. For example, this becomes a priority for them. So, Dan. I'm not only you know I'm assuming that it's not only st st NC, it's the CDS framework as well. Right. 68 00:08:10.410 --> 00:08:18.030 Pamela Dragosh: Yeah, there is some integration with CDs to that I'm talking about. Also, I mean as part of see things like that. 69 00:08:19.080 --> 00:08:27.720 Pamela Dragosh: I don't know if there's if this is one way of tracking it. But there's other places where at least I say who my inputs and outputs are and 70 00:08:27.750 --> 00:08:29.520 Chaker Al-Hakim: I'm sure those projects do the same. 71 00:08:29.550 --> 00:08:37.020 Pamela Dragosh: Thing but now whether or not everybody's in line with each other. Now that's just, that's just one of those things that 72 00:08:37.020 --> 00:08:44.370 Pamela Dragosh: I'm not sure if it's if it's tracked in one place or over multiple places. There's enough overlap so that we catch these things. 73 00:08:44.700 --> 00:08:51.000 Chaker Al-Hakim: Okay. Hey Steve, have we have we track these cross dependencies in the past and you anywhere. 74 00:08:52.260 --> 00:08:53.880 Stephen Terrill: Yeah, the sea level usually 75 00:08:55.200 --> 00:09:01.560 Stephen Terrill: Regarding the releases there, there's this when it comes into the release. There is sort of the implications on the different projects that 76 00:09:02.580 --> 00:09:07.710 Stephen Terrill: I'm is well familiar with and the other purpose at work. But the reason why I brought this up. Is that supposed 77 00:09:07.710 --> 00:09:07.980 Chaker Al-Hakim: To 78 00:09:08.130 --> 00:09:19.290 Stephen Terrill: At a glance, and we need to, as we go through the reviews, look at the the consistency, so we make sure that you know I have seen them when I can know once we're coming through it. We can see the interfaces are a mess. 79 00:09:20.070 --> 00:09:21.660 Chaker Al-Hakim: When you come to the past on reviews. 80 00:09:21.780 --> 00:09:22.980 Stephen Terrill: But that's the catch point there. 81 00:09:23.550 --> 00:09:24.840 Chaker Al-Hakim: Okay. All right. Thank you. 82 00:09:25.980 --> 00:09:30.840 Stephen Terrill: For for an architectural review point of view, we just made to make sure this architectural consistency across here so that 83 00:09:32.820 --> 00:09:43.350 Stephen Terrill: Policy is not thinking that's offering interface that to SDN SEO, and SEM. So you've got that, not, not, I don't see that in my world about the the commitment of the delivery of those will be more with our project management there. 84 00:09:45.090 --> 00:09:52.440 Pamela Dragosh: And that's why I brought this lemonade. This requirement and in the actual Frankfurt requirements here so 85 00:09:53.700 --> 00:09:54.720 Pamela Dragosh: Which is off on 86 00:09:56.490 --> 00:10:01.440 Pamela Dragosh: Our release page. So I have it. I have it here. So it was visible to everybody. 87 00:10:05.130 --> 00:10:15.360 Pamela Dragosh: Yeah, right here, the component upgrades right here. This requirement right here. And that's this is where the impacts and dependencies and who's committed and things like that. So yeah. 88 00:10:16.380 --> 00:10:16.740 Chaker Al-Hakim: For sure. 89 00:10:17.400 --> 00:10:19.290 Pamela Dragosh: We're getting smarter. Okay. 90 00:10:23.310 --> 00:10:34.560 Pamela Dragosh: Going on to this one. Another wreck 21 comes out of the controller subcommittee. So when we started in Dublin, we, we were only able to Tosca do Qatada compliance for the monitoring for the PCA team. 91 00:10:34.950 --> 00:10:43.650 Pamela Dragosh: We had a couple other policy types that we just sort of managed into that and this work is to get them fully Tosca compliant. So 92 00:10:44.670 --> 00:10:54.630 Pamela Dragosh: And that's for operational policies which are the policies that respond to the events from DCA even something when we have a condition that's getting being triggered. 93 00:10:55.230 --> 00:11:06.330 Pamela Dragosh: As well as guard policies that sort of prevent you know things from rebooting over and over and scaling up too much and not scaling down to zero and things like that so that 94 00:11:06.960 --> 00:11:28.350 Pamela Dragosh: That that covers that work. And then also, we've had CDs. We've had some companies want to use CDs as an actor, basically in control loops, whether you can take an action on something they like to go through CDs versus so STC s&c I'm sorry SP MC and app. See the Fc so 95 00:11:28.740 --> 00:11:40.920 Pamela Dragosh: That work was started in Dublin. It was dark, then and now it's ready to be brought online and available, it is a little dependent on wreck 21 but that's, you know, that's, that's okay, we're managing this pretty well. 96 00:11:41.640 --> 00:11:51.150 Pamela Dragosh: So that's sort of the majority of the new component capabilities that we're doing as far as modifying interfaces and stuff like that. We have a few some work around it. 97 00:11:51.600 --> 00:11:57.510 Pamela Dragosh: You know, given that we were rewriting the whole framework, you can't really accomplish this all in one. 98 00:11:58.410 --> 00:12:13.500 Pamela Dragosh: You know, one release. So, you know, our Dublin release. We took a stab at creating simple solutions. And once we use, the more we realized that, you know, we're missing things here, we just weren't going to be able to fix things and Alto. So we defer them to Frankfurt and so 99 00:12:14.610 --> 00:12:27.060 Pamela Dragosh: So we have a few things about health checks around health check, consolidate consolidation and adding some statistics in to help monitor the components. That's what this this policy 2025 is about and 100 00:12:29.310 --> 00:12:38.850 Pamela Dragosh: Or anything in the API that we had discovered was not correct. So we we stuck with JSON for our first 101 00:12:39.450 --> 00:12:48.840 Pamela Dragosh: Implementation in Dublin now also because that's all clamp and DCA he cared about. But honestly, we kind of prefer gamble. It's a little cleaner to look at. And so we added in. 102 00:12:49.440 --> 00:13:06.420 Pamela Dragosh: Things like that were added in as content type, as well as, you know, minor things. So the API in general is still the same, you know, nothing's really changed the more attending any major changes anywhere like that. It's just cleaning up little here things here and there for that. 103 00:13:08.010 --> 00:13:20.760 Pamela Dragosh: And another thing 2026 is since we fix that communication. We have a brand new path and the way it communicates with all the PDP now, you know, we were able to bring an apex into that full 104 00:13:21.240 --> 00:13:28.320 Pamela Dragosh: So there's been many of a discussion that we just couldn't we couldn't resolve in in Dublin. So we've had plenty of time since then to to 105 00:13:28.800 --> 00:13:45.330 Pamela Dragosh: To work out through the team and the preferences as to how groups are built and how they're registered and how the PDP report. You know what policy types it they support and things like that. And so all of this is sort of under the framework. It's not really 106 00:13:47.010 --> 00:13:59.490 Pamela Dragosh: It doesn't really affect any of our external clients at all. So we just sort of worked out some of the logic in that and passive mode when when when when should a PDP be passive versus active and 107 00:13:59.550 --> 00:14:00.570 Things like that. And what does that 108 00:14:02.340 --> 00:14:04.740 Pamela Dragosh: What does that work is done and we have ongoing 109 00:14:04.860 --> 00:14:06.210 Pamela Dragosh: We have documentation on it, but 110 00:14:06.210 --> 00:14:11.430 Pamela Dragosh: We'll, we'll make sure everything is pretty well documented of how this how this interaction back and forth. 111 00:14:12.720 --> 00:14:15.180 happens between the paths of the PDP so 112 00:14:16.710 --> 00:14:28.380 Pamela Dragosh: Again, we've made sure everything is backwards compatible. We haven't really, you know, you know, pulled the rug under any of your clients, everything's pretty much the same was just adding adding things to convenience things 113 00:14:28.410 --> 00:14:34.110 Chaker Al-Hakim: Methods and things like that. So that's, that's that covers this 114 00:14:35.490 --> 00:14:40.920 Pamela Dragosh: And again, through I list these things out on the interfaces through our version and strategy. 115 00:14:41.970 --> 00:14:56.430 Pamela Dragosh: So we have these these API's that we consume portal. We don't expect any changes here and a lot of these these top things. These seem to be the same. Of course, the teams like of a FD map and SEC notify 116 00:14:57.600 --> 00:14:59.730 Pamela Dragosh: That, hey, we've made changes here. 117 00:15:00.870 --> 00:15:05.640 Pamela Dragosh: And it's available to the community for upgrade will look and see if we can upgrade to any of that. 118 00:15:06.510 --> 00:15:19.950 Pamela Dragosh: Everything else there's no real versions on these only, the only thing that I guess we need to look at is the CDs. We're now compiling towards the CC SDK. And of course, their interfaces GR PC. It's not rest on the map. 119 00:15:21.630 --> 00:15:26.280 Pamela Dragosh: So that's, that's the new edition here. Everything else is pretty much on par with four 120 00:15:28.980 --> 00:15:37.680 Pamela Dragosh: And we have a we have three sets of API clamp is our big client when it comes to the lifecycle API for for crowd. 121 00:15:38.460 --> 00:15:47.760 Pamela Dragosh: For the creation of policies and the deployment of policies and things like that. And they just implement their the client side in their own code, they don't use any of our code base. Yes, yet. 122 00:15:48.990 --> 00:15:55.950 Pamela Dragosh: Oh, if an SDN see will be using our decision API in order to get a decision as to which policy, they should be 123 00:15:57.780 --> 00:16:16.470 Pamela Dragosh: Enforcing on their end. And I'm sorry let me let me change here for DC. They don't use our life cycle API that it's clamp that does that. They just have, they just utilize our decision API. And of course, with the new update. They care about the update notifications by the map. 124 00:16:18.180 --> 00:16:18.690 So, 125 00:16:19.710 --> 00:16:36.420 Pamela Dragosh: And we've we still have our legacy API, we still have the legacy code that's we're going to have it through Frankfurt. So we have a pointer to that old API. But we're, we're hoping that with Oof, and SDN seem moving over that we're done will be done with that. 126 00:16:36.420 --> 00:16:36.630 Said, 127 00:16:37.740 --> 00:16:38.250 Pamela Dragosh: Without 128 00:16:38.340 --> 00:16:51.660 Pamela Dragosh: The GA release. We've got all of our we've been keeping up with our API documentation here. So that is in. Well, according to elbow here. I'm sorry, let me change. I'll change that link to the master branch here. 129 00:16:53.010 --> 00:16:57.120 Pamela Dragosh: Because that obviously is the old one, but the master branch has the latest. 130 00:16:58.200 --> 00:17:08.700 Pamela Dragosh: Latest changes to all our API's and what they look like. So now we share our we share our project meetings with the client team because they're they're our biggest customer here. 131 00:17:09.360 --> 00:17:09.960 Pamela Dragosh: As well as 132 00:17:10.140 --> 00:17:25.380 Pamela Dragosh: DCA we're on the control subcommittee call with with each other. And so, as each week we're updating each other as to the API changes and things like that. So, so all the teams. All three of these project teams are aware of the changes. 133 00:17:25.380 --> 00:17:26.910 Pamela Dragosh: Oh, f is another team. I've set up. 134 00:17:26.910 --> 00:17:38.370 Pamela Dragosh: regular meetings with. And so we're on track with them as far as getting them as far as, as far as them. Understanding all the changes to the policy API's this the MC team. 135 00:17:39.810 --> 00:17:44.670 Pamela Dragosh: Small changes for them. And as I said, I'm actually starting to meet with them today and we'll meet with 136 00:17:44.670 --> 00:17:50.940 Pamela Dragosh: Them to make sure they are up to speed with the API, so they know what they need to do before I'm for 137 00:17:53.610 --> 00:17:54.840 Pamela Dragosh: It system limits. 138 00:17:56.250 --> 00:18:02.040 Pamela Dragosh: This I pulled forward but I may need to go back to that and look at that I, you know, a lot of the work that we did. 139 00:18:02.130 --> 00:18:07.140 Pamela Dragosh: Or re architected we really brought our code base down significantly. 140 00:18:08.280 --> 00:18:15.120 Pamela Dragosh: We have a lot of common code model code that shared, but each one of our components themselves are a lot smaller and center. 141 00:18:15.690 --> 00:18:19.110 Pamela Dragosh: And we're hoping that the memory utilization will be going down on that. 142 00:18:19.650 --> 00:18:31.320 Pamela Dragosh: As well as the maintain ability. So I might need to revisit this they were fairly slim ourselves. We're not not big dogs when it comes to any of this, and I and our decisions in the execution of policies are actually pretty quick. 143 00:18:32.280 --> 00:18:32.490 Chaker Al-Hakim: With 144 00:18:32.610 --> 00:18:38.310 Pamela Dragosh: run our tests and we do store that information in our read the read the docs, as far as the SPP requirements, but 145 00:18:39.630 --> 00:18:54.780 Pamela Dragosh: When we can get rid of our seed code. I think we can we can bring this any type of system limitations will be able to bring that down and and kind of show that we are we are much slimmer lighter version here going forward. 146 00:18:56.610 --> 00:18:56.970 Chaker Al-Hakim: Okay. 147 00:18:57.780 --> 00:19:07.050 Stephen Terrill: So you're saying you're kind of your limitation even know for gigs, not that big. Actually, but your limitation is your memory limited in policy not sort of processing momentum. 148 00:19:07.740 --> 00:19:16.680 Pamela Dragosh: Yeah yeah it's mainly memory, but with the legacy architecture in one of the reason we had to replace it, we'd have to do things we'd have to say things like 149 00:19:17.340 --> 00:19:24.990 Pamela Dragosh: You know, create a policy and then wait five minutes before you can read it was just not very good. So we've managed to eliminate that 150 00:19:25.830 --> 00:19:35.670 Pamela Dragosh: For the most part, in our architecture. I think I know in Dublin, we had to ask the client to wait for three seconds. But I think when we re architected a few things that that went away. 151 00:19:36.150 --> 00:19:43.980 Pamela Dragosh: So what you create if you get a 200 doc from creating a policy your next call immediately should come back and say, Yes, it is. There it is. 152 00:19:44.370 --> 00:19:46.650 Chaker Al-Hakim: You can read it. You can delete it. 153 00:19:48.750 --> 00:19:49.980 Liam Fallon (Ericsson): I suppose the only other 154 00:19:51.720 --> 00:19:59.820 Liam Fallon (Ericsson): The only other thing baby is we do have some disappears, but it should be pretty small for the Maria DB I should just documented anywhere. 155 00:20:00.630 --> 00:20:02.100 Pamela Dragosh: Yeah. Yeah, let's do that. 156 00:20:02.220 --> 00:20:04.680 Liam Fallon (Ericsson): Yeah yeah yeah yeah 157 00:20:05.910 --> 00:20:22.380 Pamela Dragosh: Yeah, we're a pretty pretty small footprint when it comes to things like that the only the only thing that would can grow in size is we do track when we, when we run our operational policies for control loops. We do track actions that we take so we can set up guard policies on that. 158 00:20:22.800 --> 00:20:27.630 Pamela Dragosh: But that that's something that you can set up a regular on cleaning out of that. 159 00:20:28.470 --> 00:20:36.270 Pamela Dragosh: Of the database or what we really ideally like to do is kind of roll things up so you don't lose track of things but so for example. 160 00:20:36.660 --> 00:20:45.900 Pamela Dragosh: We can go back and say well you know what you rebooted this certain VF 10 times in the last hour. And so what's going on there. So let's let's block on 161 00:20:46.230 --> 00:20:52.740 Pamela Dragosh: Another reboot of it and go bring in an ops team so that database will grow but it's on our list to 162 00:20:53.700 --> 00:21:01.770 Pamela Dragosh: To look at Rolling, rolling it up and consolidating it so we retain useful information. So you can sort of track things over time. 163 00:21:02.760 --> 00:21:07.500 Pamela Dragosh: That would be the only database that would be affected. Everything else is how many policies do you have, and 164 00:21:08.070 --> 00:21:22.260 Pamela Dragosh: If you start having thousands and thousands of policies, I think you've missed them you've made a mistake somewhere so 10s or hundreds might be okay. But I think that that's that's overkill. So, but that's that's my opinion. 165 00:21:24.540 --> 00:21:32.220 Pamela Dragosh: Okay, as far as use use cases, we support all of the standard ones we are all scale up BCP and we 166 00:21:32.490 --> 00:21:39.090 Pamela Dragosh: The folks from five g o FF also have some requirements for us, they they've got a couple control loops and they like doing control of coordination. 167 00:21:39.480 --> 00:21:54.210 Pamela Dragosh: As far as any of the other use cases. I think we, you know, we still support them anyway and test only, but specifically for these because we're involved with clamp in the integration team we and oh, if we make sure you know I've highlighted, these ones, but 168 00:21:54.810 --> 00:22:10.530 Pamela Dragosh: Any use case that wants to use a control loop should be able to work as long as all that they use all the existing actors in the actions that are that are and what I mean by actor kind of a bad word I but it's basically any of the controllers or orchestrators that are out there. 169 00:22:12.390 --> 00:22:13.140 Pamela Dragosh: Um, 170 00:22:15.030 --> 00:22:33.930 Pamela Dragosh: You were impacted models. Okay. Yeah. I mean, we've we've switched to Tosca for a policy models. And so I'm just highlighted that, you know, so anybody, anybody that is using the old legacy API with the old gammell type of style of defining a defining a model. 171 00:22:34.410 --> 00:22:36.450 Chaker Al-Hakim: Or an operational policy. 172 00:22:36.510 --> 00:22:46.260 Pamela Dragosh: After this really that we're going to keep it around. But after this release. We're going to, we're going to remove all that code. So look, we affected that but at that point they really should be ported over to using the new the new 173 00:22:47.370 --> 00:22:51.240 Pamela Dragosh: You know, the new new components of the new framework and things like that so 174 00:22:52.620 --> 00:22:57.150 Pamela Dragosh: We designed the code for. Okay. One thing that we are doing policy. 175 00:22:58.230 --> 00:23:18.660 Pamela Dragosh: Is all that code that we do use during runtime to invoke actors and make make calls in response to control group events. Got a little bit away from us. And so we're we're making an effort here to go into that part of the code base to to clean it up, make it, make it a little bit. 176 00:23:18.690 --> 00:23:19.920 Liam Fallon (Ericsson): easier to understand and 177 00:23:19.920 --> 00:23:20.370 Read 178 00:23:21.390 --> 00:23:27.090 Pamela Dragosh: Make it a little more maintainable, be able to work. Sit asynchronously and synchronously. And we're also trying to reduce 179 00:23:27.930 --> 00:23:38.310 Pamela Dragosh: The RL that's associated with it. So there are less rules in there that aren't so just so making it a lot easier to implement going forward. And then, of course, on the APEC side they 180 00:23:38.670 --> 00:23:45.510 Pamela Dragosh: They need to be able to utilize the models and the actors themselves or somebody wants to operational policy that uses 181 00:23:45.660 --> 00:23:46.590 Liam Fallon (Ericsson): Impacts and so 182 00:23:47.820 --> 00:23:57.780 Pamela Dragosh: Most of the other work is done. And this is work star just start, we'll have plenty of time to finish that. But again, we're just more code clean up maintain ability usability. 183 00:23:58.830 --> 00:24:01.650 Liam Fallon (Ericsson): Trying to reduce overhead and just make things 184 00:24:01.710 --> 00:24:13.950 Pamela Dragosh: Easier for when the community pulls in policy and they want to write their own rules where they want to use their own you know use their own actors, they have a nice framework here where they can go ahead and do that. 185 00:24:15.990 --> 00:24:19.110 Pamela Dragosh: Okay, I'm at the end of this week here. They need questions. 186 00:24:20.040 --> 00:24:21.870 Chaker Al-Hakim: I do have a couple of questions. I didn't wanna 187 00:24:23.910 --> 00:24:27.960 Chaker Al-Hakim: I DIDN'T WANT TO STOP YOU BEFORE. SO, SO I have question regarding 188 00:24:29.820 --> 00:24:42.600 Chaker Al-Hakim: The policy, the usage data within the policy engine, do we collect any data in terms of how often a specific policy gets executed in by home. 189 00:24:44.430 --> 00:24:45.900 Pamela Dragosh: Yeah, kind of. We 190 00:24:46.200 --> 00:24:46.620 Chaker Al-Hakim: Do and 191 00:24:46.890 --> 00:24:50.070 Pamela Dragosh: We have this policy 2025 here. 192 00:24:50.880 --> 00:24:54.750 Pamela Dragosh: This, this is about collecting statistics. 193 00:24:55.020 --> 00:25:08.190 Pamela Dragosh: Okay, as well. I'll in consolidating the health check in. So some of the PDP like this actual PDP report statistics. It tells you what how many permits and denies and things like that you've gotten. How many things like that. 194 00:25:09.330 --> 00:25:20.760 Pamela Dragosh: But that was just put in there, you know, in Dublin, that's a first stab at it. Now this this epic is about bringing all the PDP is online as far as successes and failures and things like that. 195 00:25:21.720 --> 00:25:29.670 Pamela Dragosh: When it comes to policies and stuff like that. So we'll wrap that work that type of stuff in here and keep moving on it going forward. 196 00:25:30.750 --> 00:25:33.180 Pamela Dragosh: So some of that would be captured here. 197 00:25:33.510 --> 00:25:34.770 Chaker Al-Hakim: And these statistics. 198 00:25:35.040 --> 00:25:50.580 Pamela Dragosh: We also the PAP when it actually communicates with the PDP. It is also sending out notifications as to successes and failures for that. Now, whether or not that's going to get tracked in a database. 199 00:25:51.090 --> 00:25:58.200 Pamela Dragosh: That's something we can think about for the G release it's logged somewhere at the very least, is on the map. So it can be captured so 200 00:25:58.260 --> 00:26:09.030 Pamela Dragosh: So yeah, so so yeah so so we are we are making effort towards making sure that our, you know, all of our components are monitor arable and 201 00:26:10.080 --> 00:26:13.710 Pamela Dragosh: Easy to figure out what's going on with them that they're not these black boxes that you 202 00:26:13.770 --> 00:26:18.390 Chaker Al-Hakim: Don't know exactly, exactly the statistics. I mean, can look to some statistics to see how 203 00:26:20.220 --> 00:26:20.970 Chaker Al-Hakim: How many 204 00:26:22.020 --> 00:26:30.660 Chaker Al-Hakim: Policies, we have often do they get executed or they've been executed in the right you know by the right actor or, you know, source and so on and so forth that may be 205 00:26:31.800 --> 00:26:33.360 Chaker Al-Hakim: Useful data to look at. Yeah. 206 00:26:33.810 --> 00:26:48.000 Pamela Dragosh: Yeah, and and actually inform the operational policies as they as that, as they get executed. We do have a D map sort of a state machine API for doing that already. So that gets actually dumped out onto the map topic and is 207 00:26:48.150 --> 00:26:49.560 Chaker Al-Hakim: Something that can be logged by a 208 00:26:49.560 --> 00:26:56.010 Pamela Dragosh: System or used by, you know, integration team for testing and things like that you can use. 209 00:26:58.770 --> 00:27:03.300 Chaker Al-Hakim: The, the second question that I have is, I'm assuming that you're aware of the 210 00:27:05.400 --> 00:27:09.690 Chaker Al-Hakim: Of the downtime time that has been scheduled for the one river lab. 211 00:27:10.860 --> 00:27:16.080 Chaker Al-Hakim: Early next year. Is that going to impact any of your the work that you're trying to accomplish. 212 00:27:17.730 --> 00:27:19.620 Pamela Dragosh: Um, it might because the 213 00:27:20.970 --> 00:27:26.460 Pamela Dragosh: I mean, obviously we need a place for the team to go to to actually start testing things at the 214 00:27:26.460 --> 00:27:27.030 Chaker Al-Hakim: Moment, we're 215 00:27:27.150 --> 00:27:28.860 Pamela Dragosh: We're a little in flux. 216 00:27:29.550 --> 00:27:43.170 Pamela Dragosh: But we're in. And one thing I'm struggling with right now is I have, I have a resource that freed up and he's doing the JDK 11 upgrade, but we can't finish that without alpine images. 217 00:27:43.650 --> 00:27:56.880 Pamela Dragosh: It's kind of stuck with with getting that. So we may not get that so early January. And so how do we test that if we don't have a lab. So because we need to kind of have stable images to 218 00:27:57.960 --> 00:28:05.190 Pamela Dragosh: Have things. In addition, if I'm trying to demo things too. But today, I'm going to try to demo to the SDN see team. 219 00:28:05.910 --> 00:28:18.150 Pamela Dragosh: It's kind of tough sometimes to demo everything when you've got like four or five components here that you need to bring up and you know I've just got my little laptop and so it's easier if you have a lab up and running. So 220 00:28:18.870 --> 00:28:26.880 Pamela Dragosh: Yeah, we'll be looking for that lab to come come back because obviously I'm too is one thing, but when you were after after January 21 221 00:28:27.390 --> 00:28:40.710 Pamela Dragosh: We need to make sure we're stabilizing the images and that's when I start saying things like, you know, no more big changes or we're not going to bring this change in at this point because we need to start, you know, settling the images down and making sure they're working 222 00:28:42.600 --> 00:28:50.730 Pamela Dragosh: And we need to do that by him, for I think if they can get it done early January I think they'll be okay. But if it's stretches out or drags out that might be a problem for us. 223 00:28:53.250 --> 00:29:01.380 Chaker Al-Hakim: Yeah, I do have this guy. The reason I'm asking is because the topic came up has come up quite a few times I just, you know, even though it may not be related to the 224 00:29:02.280 --> 00:29:10.500 Chaker Al-Hakim: To the overall architecture. It's just, you know, it's just, you know, I want to make sure that you know what I know and make sure that you 225 00:29:11.310 --> 00:29:24.330 Chaker Al-Hakim: You're aware of it in in your plan for it, or at least take into account because it is the list schedule that I saw cause for the the lab to be down probably three, four or five days at least. 226 00:29:25.980 --> 00:29:28.560 Pamela Dragosh: Yeah, I mean, that's probably okay if 227 00:29:28.830 --> 00:29:35.520 Pamela Dragosh: I'm in the timing. Okay, it would been better if they've done it in December. 228 00:29:36.780 --> 00:29:39.420 Chaker Al-Hakim: Now, but that's their call it's their 229 00:29:39.420 --> 00:29:41.070 Chaker Al-Hakim: Labs and we 230 00:29:41.220 --> 00:29:44.310 Pamela Dragosh: Are not doing it like late February, which is right before I'm for 231 00:29:46.470 --> 00:29:47.220 Chaker Al-Hakim: One last question. 232 00:29:47.490 --> 00:29:50.520 Chaker Al-Hakim: This is just for my own my own benefit. 233 00:29:52.710 --> 00:29:59.310 Chaker Al-Hakim: Where do you first, the very first time you do pairwise testing with other own app component 234 00:30:00.510 --> 00:30:03.510 Chaker Al-Hakim: Is that in the Wind River lab or 235 00:30:03.630 --> 00:30:05.220 Chaker Al-Hakim: Do you work prior to account. 236 00:30:06.570 --> 00:30:06.960 Liam Fallon (Ericsson): Yes. 237 00:30:06.990 --> 00:30:08.280 Pamela Dragosh: That's the only thing because 238 00:30:09.570 --> 00:30:10.020 Pamela Dragosh: The thing about 239 00:30:10.050 --> 00:30:11.430 Pamela Dragosh: Politics is 240 00:30:12.150 --> 00:30:15.450 Pamela Dragosh: Most, most, most of our interaction is with clamp. I mean, 241 00:30:15.840 --> 00:30:16.380 Pamela Dragosh: You can very 242 00:30:16.500 --> 00:30:30.030 Pamela Dragosh: Easily test because basically they set things up and and it's a lot of creation and deployment. So that design time in an initial stuff is pretty easy to accomplish. But once you get past that you start doing runtime. 243 00:30:30.030 --> 00:30:31.350 Pamela Dragosh: Stuff very 244 00:30:31.560 --> 00:30:32.280 Pamela Dragosh: Difficult for us. 245 00:30:32.400 --> 00:30:32.700 Because 246 00:30:36.480 --> 00:30:37.800 Pamela Dragosh: Usually what happens is we 247 00:30:37.830 --> 00:30:39.090 Liam Fallon (Ericsson): Get clamped done and then 248 00:30:39.150 --> 00:30:40.050 PCA 249 00:30:41.670 --> 00:30:43.020 Pamela Dragosh: Gotta have to tee up 250 00:30:43.080 --> 00:30:45.450 Liam Fallon (Ericsson): After that we have with 251 00:30:45.510 --> 00:30:46.740 Pamela Dragosh: Apps. He and 252 00:30:47.700 --> 00:30:50.550 Pamela Dragosh: So we usually are never able to 253 00:30:50.760 --> 00:30:53.520 Pamela Dragosh: We've got to rely on the integration team to do that. 254 00:30:54.600 --> 00:31:03.000 Pamela Dragosh: It's just, it's just really hard for us to do that because you have to have, you have to have service distribution successful and then instantiate successful and usually 255 00:31:03.030 --> 00:31:03.690 Chaker Al-Hakim: Absolutely. 256 00:31:04.320 --> 00:31:08.040 Pamela Dragosh: That's failing, all the way up till you know our CTO so 257 00:31:09.600 --> 00:31:19.800 Chaker Al-Hakim: Yes. And this you know i i didn't i was not paying attention before but yesterday, you know, this week I realized that when the, when Grover lab is the only lab or you could do. 258 00:31:20.970 --> 00:31:24.060 Chaker Al-Hakim: Any pairwise testing. And that's, you know, that's a little bit challenging 259 00:31:25.200 --> 00:31:26.460 Chaker Al-Hakim: Can be let's put it this way. 260 00:31:27.540 --> 00:31:28.890 Chaker Al-Hakim: Yeah, okay. 261 00:31:30.150 --> 00:31:32.070 Chaker Al-Hakim: Okay, good. Thank you. Yep. 262 00:31:32.430 --> 00:31:40.140 Pamela Dragosh: Okay, so I suspect Stephen a shocker. I think we want to go back to this picture and see what changes we needed here because we probably need to add in 263 00:31:42.660 --> 00:31:50.550 Pamela Dragosh: Well, I guess if the CBS controllers is underneath the controllers right here. That's probably sufficient right 264 00:31:54.570 --> 00:31:56.610 It's an action trigger control. It's probably 265 00:31:57.930 --> 00:31:58.320 Chaker Al-Hakim: Fair. 266 00:32:00.180 --> 00:32:02.280 Chaker Al-Hakim: Yeah, it seems reasonable. Yeah, yeah. 267 00:32:04.230 --> 00:32:07.320 Pamela Dragosh: So we have nothing. None of these things should have 268 00:32:10.320 --> 00:32:12.030 Pamela Dragosh: Changed unless we need to add 269 00:32:14.340 --> 00:32:18.660 Pamela Dragosh: Something for the update notification that we published on the map topic. 270 00:32:21.210 --> 00:32:21.510 Chaker Al-Hakim: Maybe 271 00:32:21.630 --> 00:32:23.490 Pamela Dragosh: That needs to be added to this page. 272 00:32:24.690 --> 00:32:32.250 Chaker Al-Hakim: I'm trying to see where the GR PC changes or documented for the CDs. 273 00:32:34.620 --> 00:32:35.280 Chaker Al-Hakim: Framework. 274 00:32:36.570 --> 00:32:37.110 Chaker Al-Hakim: And this way. 275 00:32:37.500 --> 00:32:38.040 Pamela Dragosh: We would have 276 00:32:38.100 --> 00:32:40.110 Pamela Dragosh: A list that I think underneath here. 277 00:32:40.410 --> 00:32:41.760 Okay, yeah. 278 00:32:43.080 --> 00:32:44.880 Chaker Al-Hakim: We're listening, just because it's been oh yeah 279 00:32:45.930 --> 00:32:46.590 Pamela Dragosh: Yeah, and 280 00:32:48.420 --> 00:32:55.170 Pamela Dragosh: Oh, maybe appear, you would have to separate CDs out because so his rest. You can see the rest here. 281 00:32:56.700 --> 00:33:02.640 Pamela Dragosh: He has since it's kind of weird. Okay, so some of our some of our 282 00:33:05.010 --> 00:33:11.760 Pamela Dragosh: Yeah SDN see is also rest via FC is rest only SDN or an app, C, or D map. 283 00:33:13.950 --> 00:33:22.530 Pamela Dragosh: So we have a combination. Some of our controllers on the map. Some of them are on rest and this sort of shows only S O is rest. 284 00:33:23.520 --> 00:33:38.070 Pamela Dragosh: That maybe maybe what we do is, for this one, we do D map slash risks last GR PC for for this thing right here. Maybe just put them all underneath that or unless if you want to highlight, who does what 285 00:33:39.960 --> 00:33:47.940 Pamela Dragosh: Like that. And then I'm not sure about the trouble tickets, because of the system that and maybe that's just really know we don't really have a trouble ticket system in 286 00:33:48.990 --> 00:33:50.190 Pamela Dragosh: You know now, but 287 00:33:50.400 --> 00:33:52.650 Pamela Dragosh: The theory goes that you know we 288 00:33:53.250 --> 00:33:56.310 Pamela Dragosh: You know show somebody should be able to integrate with that system. 289 00:33:56.850 --> 00:34:06.330 Chaker Al-Hakim: Yeah. What I want to do is let me discuss with Steve because he's the one that created this this diagram, I would like to see the controllers box. 290 00:34:07.350 --> 00:34:12.570 Chaker Al-Hakim: broken into three different three separate boxes in each box specifies the 291 00:34:13.620 --> 00:34:21.240 Chaker Al-Hakim: Specific API, you know, the, you know, if it is CDs, the CDS framework. It's a GR PC. If it is the same controller. 292 00:34:22.200 --> 00:34:35.880 Chaker Al-Hakim: The traditional SDN, see, you know, whatever it is, whether it is rest or the map, but I'd rather see that at least for clarity, because as especially as we go through the transition right you know ultimately 293 00:34:37.260 --> 00:34:44.490 Chaker Al-Hakim: I think the plan is excuse me to migrate everything to GR PC. But up until we get there. I think when you have a 294 00:34:46.140 --> 00:34:48.180 Chaker Al-Hakim: View that reflect the reality. 295 00:34:49.650 --> 00:34:50.070 Okay. 296 00:34:52.320 --> 00:35:06.810 Pamela Dragosh: Yeah, that's something I'll put my control subcommittee hat on. Oh, well I guess it's more of a policy hat. I mean, I would I would actually we were actually thinking it would be nice to just use the map and then we have a common a common 297 00:35:08.850 --> 00:35:15.240 Pamela Dragosh: Structure that we publish out there and we can change use different topics for different controllers, but 298 00:35:15.390 --> 00:35:21.810 Pamela Dragosh: Yeah, basically, same format. And then we just, we could remove a whole bunch of old chunk of our code base. 299 00:35:22.230 --> 00:35:32.130 Pamela Dragosh: And just and make it very easy to extend to cop, you know, Custom Controllers internal you know if a company has their own proprietary controller system that they want to integrate into their 300 00:35:32.580 --> 00:35:38.400 Pamela Dragosh: We just use the very the map topic or D map based message that has well structured format to it. 301 00:35:39.390 --> 00:35:40.710 Chaker Al-Hakim: And you 302 00:35:40.890 --> 00:35:52.470 Pamela Dragosh: Then there's no work on the policy and because you know otherwise we're just always every time there's a new API underneath these controllers. It's more work to do on our end in order to communicate with them. 303 00:35:53.130 --> 00:36:04.080 Pamela Dragosh: And be nice just to have the message be able to programmatically automatically from okay these are the policies and this is our interface with Amy I all I need to do is take data from 304 00:36:04.470 --> 00:36:14.550 Pamela Dragosh: From the event that we can inform DCA make a call to AI and then easily populate demand message and publish it to the right topic in a way you go 305 00:36:16.500 --> 00:36:16.710 Chaker Al-Hakim: But 306 00:36:17.310 --> 00:36:27.480 Pamela Dragosh: I just haven't. I just have not had the cycles to present this. I've had it marked in the control subcommittee. But one of the things we're hoping to get to in 2020 307 00:36:27.510 --> 00:36:36.180 Pamela Dragosh: Is to get on architecture and talk about that. So when you say hey you're we want everybody to migrate to GR PC. 308 00:36:37.140 --> 00:36:37.410 Chaker Al-Hakim: I mean, 309 00:36:37.530 --> 00:36:45.990 Pamela Dragosh: It's great when one hand, that's great. But what does that mean for the policy team because we're, you know, we're we're greatly affected by by this every time a new actor and 310 00:36:46.590 --> 00:37:00.000 Pamela Dragosh: What I what we call an actor. I probably shouldn't use it a different different term but anytime we have to do anything like that it's it's bit of work on our end and it would be nice if we had just one clean systematic way of doing that, that just worked forever and you 311 00:37:00.210 --> 00:37:09.510 Chaker Al-Hakim: Know, I understand you understand. I kind of, I kind of agree with you. Right. And the reason that I mentioned your PC is because the topic was discussed. 312 00:37:10.830 --> 00:37:13.470 Chaker Al-Hakim: I want to say maybe three or four sessions back 313 00:37:15.360 --> 00:37:16.800 Chaker Al-Hakim: It was presented by 314 00:37:18.660 --> 00:37:26.790 Chaker Al-Hakim: By Dan and a few other people that are working on the CDS the controller as well as the CDS framework. 315 00:37:27.240 --> 00:37:30.030 Chaker Al-Hakim: Like you're in your room. That's right. 316 00:37:30.210 --> 00:37:43.980 Pamela Dragosh: Right, yeah. I mean, every chair PC. I mean, I think it's, I don't know enough about it. I know that people are moving towards it, or it's getting popular or so I'm not sure how to classify that but so it's so it's well well worth looking into. 317 00:37:45.120 --> 00:37:51.570 Chaker Al-Hakim: That you know maybe you see I see I got the impression that the the work has gone for 318 00:37:52.680 --> 00:38:10.320 Chaker Al-Hakim: You know, has been has been going on for a while and they they have and I don't want to misquote anybody right now, but for some reason I thought that they had an agreement with either AI policy or few other components to use G RPC for the future for the next release right 319 00:38:12.720 --> 00:38:17.640 Chaker Al-Hakim: You know there. We had a significant discussion that was probably over 45 minutes 320 00:38:19.560 --> 00:38:24.360 Chaker Al-Hakim: And I think the assumptions that they're making is that the default 321 00:38:26.760 --> 00:38:31.230 Chaker Al-Hakim: API into the control framework has gone G RPC until it's 322 00:38:32.430 --> 00:38:42.150 Chaker Al-Hakim: It's otherwise agreed to write from moving forward there maybe for there's going to be from their perspective is to support the RPC. Anything else that 323 00:38:42.690 --> 00:38:59.760 Chaker Al-Hakim: Is not G RPC basis going to be supported by the recipient. There were seven components. So we may need yet another discussion to make sure that we're all on the same page in terms of how we want to introduce and use G RPC within the platform. 324 00:39:01.110 --> 00:39:02.010 Pamela Dragosh: Yeah, I mean, 325 00:39:03.180 --> 00:39:15.210 Pamela Dragosh: For from the policy side, you know, Liam had actually done a rest implementation to CDs as a proof of concept. But then when the bell Canada team came team came 326 00:39:15.210 --> 00:39:15.660 Chaker Al-Hakim: In they 327 00:39:15.930 --> 00:39:27.960 Pamela Dragosh: Worked with a CC SDK with the CDS team and they were like, no, no, no, you're going to use GR PC, so I didn't have, you know, we didn't really have too much of a choice. 328 00:39:29.280 --> 00:39:30.300 Pamela Dragosh: You know, so 329 00:39:31.860 --> 00:39:44.940 Pamela Dragosh: But it okay so if all the controllers to use GR PC and they use it for everything, whether it's a manual call to do something, or it's something as part of an automated control loop event. 330 00:39:45.480 --> 00:39:55.740 Pamela Dragosh: Okay, there's, there's some consistency there. But then what do I do about if I want to talk to. So do we make. So go to G RPC. So they're also consistent 331 00:39:57.420 --> 00:40:07.260 Pamela Dragosh: And, you know, then if you want to integrate and let's see, Paul thing you pull own app into your own company and you have things like a 332 00:40:07.980 --> 00:40:22.530 Pamela Dragosh: Like a help to help desk ticketing system Q chat system or email system. You got to use G RPC to integrate to those two or are we still stuck with having a flavor for this a flavor of an API for that, things like that. 333 00:40:24.510 --> 00:40:32.190 Pamela Dragosh: Those are the questions that I come back with me. You know, I think of and I'm all for consistency and that's exactly what I'm looking for. 334 00:40:33.720 --> 00:40:34.320 Pamela Dragosh: So, 335 00:40:36.300 --> 00:40:37.080 Chaker Al-Hakim: I know I 336 00:40:38.130 --> 00:40:47.730 Pamela Dragosh: investigate those things to see where the ramifications of that because it obviously for me for for control loops. We're trying to make it as the most flexible system. We can we can do 337 00:40:48.720 --> 00:40:59.190 Pamela Dragosh: So you can you can write any type of control of that to do you want that policy can just very easily integrate with the other with the other with whatever this is in the system and 338 00:40:59.460 --> 00:41:00.030 Chaker Al-Hakim: Not have 339 00:41:00.600 --> 00:41:10.860 Pamela Dragosh: You know, not require loads of development time for, you know, developers to integrate, you know, third party system. So that's, that's kind of our goal here so 340 00:41:12.120 --> 00:41:17.130 Pamela Dragosh: I guess going forward. Let's just keep discussing it and see what what the right solution is 341 00:41:18.090 --> 00:41:25.740 Chaker Al-Hakim: I think that's my my intent. My intent is to make sure that I share with this team. I mean, on this forum. 342 00:41:27.000 --> 00:41:34.530 Chaker Al-Hakim: discussions that have taken place and some of the participants on, you know, may not have had changed to 343 00:41:35.490 --> 00:41:51.300 Chaker Al-Hakim: To be aware of them or to be made aware of them right GR PC is critical because they did have, like I said, we did have a significant discussion in AI offline. I reached out to a few other key developers to make sure that I understand it and 344 00:41:52.440 --> 00:42:05.490 Chaker Al-Hakim: At least, and I think there's a little bit more work to be done on this topic to make sure that all the components are on the same page in terms of how how in should we 345 00:42:06.960 --> 00:42:08.010 Chaker Al-Hakim: Only have 346 00:42:09.600 --> 00:42:11.100 Chaker Al-Hakim: In GR PC based 347 00:42:12.780 --> 00:42:24.030 Chaker Al-Hakim: Control frame control framework. And then if you need to support anything else, then it is up to you to, to make sure that the interface is is implemented and tested correctly. 348 00:42:25.380 --> 00:42:31.260 Pamela Dragosh: Yeah, and some other things to look at. What about edge deployment will that work through edge deployment. 349 00:42:31.770 --> 00:42:32.820 Chaker Al-Hakim: Think so. Right. I can't 350 00:42:33.060 --> 00:42:35.520 Pamela Dragosh: It's been a while since I've looked at Dr. C. So I don't know. 351 00:42:36.270 --> 00:42:38.790 Pamela Dragosh: But that won't matter, you know, 352 00:42:39.840 --> 00:42:46.380 Pamela Dragosh: Yeah, definitely. I hope to have more cycles next next year to to sort of help work on this topics. 353 00:42:47.010 --> 00:42:54.690 Chaker Al-Hakim: Absolutely. I don't have an opinion. I just want to make sure that we we just have the discussion. So to make sure that everybody's on the same page. And we come up with 354 00:42:55.470 --> 00:43:04.350 Chaker Al-Hakim: One agreement that is basically that works for everybody and everybody is aware of it might otherwise we'll, we'll end up with surprises at the tail end of the cycle. 355 00:43:06.180 --> 00:43:06.480 Okay. 356 00:43:10.290 --> 00:43:10.950 Chaker Al-Hakim: Okay, good. Okay. 357 00:43:11.520 --> 00:43:18.540 Pamela Dragosh: Um, so what else do we need to do for this page. I think so. I think we need to some picture modifications. 358 00:43:19.590 --> 00:43:25.710 Pamela Dragosh: I think maybe the publishing of the update notification should probably be highlighted. 359 00:43:28.170 --> 00:43:28.440 To 360 00:43:29.610 --> 00:43:31.650 Pamela Dragosh: This I'm kind of asking 361 00:43:33.030 --> 00:43:37.710 Stephen because I'm not sure how much Ooh yeah I should probably 362 00:43:38.760 --> 00:43:41.250 Pamela Dragosh: help out with these links and stuff like 363 00:43:41.250 --> 00:43:41.730 That 364 00:43:44.790 --> 00:43:51.390 Pamela Dragosh: I know we were doing some work. We're trying to get some of this overall documentation things documented here so 365 00:43:53.400 --> 00:43:55.410 Chaker Al-Hakim: What I will do. Pam, just because 366 00:43:57.390 --> 00:44:09.960 Chaker Al-Hakim: You know, I'm still a bit new to this and going to look over your presentation and trying to understand to, you know, what's being requested and what has been 367 00:44:11.850 --> 00:44:16.560 Chaker Al-Hakim: You know, entered, and if they see any gaps. I'll send you an email. 368 00:44:17.910 --> 00:44:18.210 Okay. 369 00:44:23.730 --> 00:44:24.090 Chaker Al-Hakim: Okay. 370 00:44:24.900 --> 00:44:26.640 Pamela Dragosh: Okay, that sounds fine to me. 371 00:44:30.450 --> 00:44:31.950 Chaker Al-Hakim: Okay, anything else. Pam. 372 00:44:33.480 --> 00:44:35.280 Pamela Dragosh: No, that's, that's all for my end. 373 00:44:36.120 --> 00:44:36.480 Okay. 374 00:44:38.400 --> 00:44:40.170 Chaker Al-Hakim: Thank you for presenting 375 00:44:41.370 --> 00:44:41.610 You 376 00:44:44.700 --> 00:44:45.690 Chaker Al-Hakim: And I guess so. I'm here. 377 00:44:46.110 --> 00:44:50.550 Pamela Dragosh: Today, if you want to send email to try to resolve anything through Thursday otherwise back on the second 378 00:44:51.030 --> 00:44:57.330 Chaker Al-Hakim: Yes. Well, I'm trying to do the same. So let me, let me see if I have time, I'm still traveling. This week, but let me see if I have 379 00:44:58.500 --> 00:44:59.580 Chaker Al-Hakim: I'll send you whatever I can. 380 00:45:02.190 --> 00:45:04.410 Chaker Al-Hakim: So that was the last topic we have 381 00:45:05.580 --> 00:45:09.690 Chaker Al-Hakim: On the agenda. Are there any questions comments or 382 00:45:11.010 --> 00:45:12.540 Chaker Al-Hakim: Feedback from the rest of the team. 383 00:45:17.250 --> 00:45:18.960 Vijay Venkatesh Kumar (AT&T): Every day, every day. 384 00:45:19.980 --> 00:45:24.930 Vijay Venkatesh Kumar (AT&T): Hey, for the DC Victor Vito demonic check if you have a slot available for the seven 385 00:45:29.790 --> 00:45:31.110 Chaker Al-Hakim: Sure. I haven't looked at the 386 00:45:31.290 --> 00:45:35.040 Chaker Al-Hakim: At the agenda yet but I'm pretty sure we will have a slot on the seven 387 00:45:36.750 --> 00:45:41.760 Vijay Venkatesh Kumar (AT&T): Okay, if you have. Yeah, please. Florida and yeah I think I have it ready by then. 388 00:45:42.330 --> 00:45:43.590 Chaker Al-Hakim: Okay, okay. 389 00:45:44.010 --> 00:45:44.550 Chaker Al-Hakim: Sounds good. 390 00:45:44.850 --> 00:45:45.480 Chaker Al-Hakim: Thank you. BJ. 391 00:45:48.960 --> 00:45:49.980 Chaker Al-Hakim: Okay, anything else. 392 00:45:52.050 --> 00:45:57.270 Chaker Al-Hakim: I think we're gonna give you some time back this this week in before we conclude 393 00:45:59.790 --> 00:46:03.480 Chaker Al-Hakim: This session is going to be the last session for the for the year. 394 00:46:04.680 --> 00:46:09.360 Chaker Al-Hakim: I will be off next week. And the final week and we'll come back, we'll get back on the sevens. If you 395 00:46:10.440 --> 00:46:22.560 Chaker Al-Hakim: Have any topics that you want to propose for the agenda for the seven, please send them to me. And you could always send them to me. And Steve for now during the transition to make sure that we don't drop anything 396 00:46:23.760 --> 00:46:34.860 Chaker Al-Hakim: And with that, I just wanna if there is no more comments or questions. I just want to wish everybody if you celebrate the Happy Holidays and we'll talk to you. 397 00:46:36.000 --> 00:46:36.720 Chaker Al-Hakim: On the seventh 398 00:46:37.320 --> 00:46:44.370 Pamela Dragosh: It, by the way. Shocker. I'm Steve. Steven creates jurors in the open up architecture for each one of these reviews. I just 399 00:46:44.370 --> 00:46:45.000 Chaker Al-Hakim: Yes, my 400 00:46:45.360 --> 00:46:58.710 Pamela Dragosh: My empty ticket towards that. So can you do. Can I consider that our architecture reviews done. And of course, if we have any other gaps or anything that needs to be addressed. After you look at this, we can reopen them or 401 00:46:58.980 --> 00:47:01.140 Pamela Dragosh: Address later. I just want to make 402 00:47:01.170 --> 00:47:02.100 Chaker Al-Hakim: Sure I can. My 403 00:47:02.130 --> 00:47:03.510 Pamela Dragosh: Ticket. Yes. 404 00:47:03.720 --> 00:47:15.120 Chaker Al-Hakim: You may. Okay, you could go ahead and do that. Steve has already created the JIRA I'll take a look at it after this call, or when I have a chance. And then we'll do whatever we need to do to close it up. 405 00:47:16.410 --> 00:47:17.250 Pamela Dragosh: Very good, thank you. 406 00:47:17.820 --> 00:47:18.840 Chaker Al-Hakim: Okay. You're welcome. 407 00:47:20.610 --> 00:47:22.080 Chaker Al-Hakim: Okay. Any last thoughts. 408 00:47:25.170 --> 00:47:29.040 Chaker Al-Hakim: Okay. Thank you all. Happy Holidays again. All right, take care. 409 00:47:33.330 --> 00:47:33.570 Vijay Venkatesh Kumar (AT&T): Bye.