Automatic IETF Minutes

Markdown Version

Session Date/Time: 17 Mar 2026 01:00

Sure, here is a verbatim transcript of the ONSEN Birds of a Feather session at IETF 118:

Alvaro Retana: Good morning! Good morning. There is some very good coffee out there if you guys need to get up. It’s only Tuesday, we are only starting the meeting this week. This is the ONSEN BoF, Operationalizing Network and Service Abstractions. My name is Alvaro Retana. Suresh Krishnan is going to be your BoF chair for today. We have all seen the Note Well. These are the norms that you agreed to when you registered for the meeting. Please take a second to read it over. It mostly points at policies and BCPs around behavior, around IPR, and it should be familiar. Make sure that you identify yourself at the mike whenever you come in. Make sure that everyone is logged into the MeetEcho so you can get into the queue both locally here and remotely if you are at home or somewhere else. And as I said, please state your name when you get to the mike so that we all know who you are. Linda, who is sitting over here, agreed to take notes. Thank you, Linda. So make sure you say your name clearly so that we can identify you correctly in the notes.

So this session is a BoF. A BoF is a Birds of a Feather. It’s basically a session where we meet to explore new work in the IETF. In this case, it is a working group forming BoF. That means that the objective is to walk out of here with an understanding of whether we think, as a community, that there is enough interest and enough motivation to form a new working group. We are not deciding on the working group today. That is a job for the AD and for the IESG to decide on that. But we are going to talk about whether we need a BoF. We’re going to discuss a charter a little bit later on. Usually the process is: there are proponents that talk about the need for a new working group, the ADs and the IESG approve a BoF, which is where we are right now, and then after this, we can either — or the outcomes could be — we could either form a working group, we can revise whatever the outcome is from this and start over or change the direction, or we could just terminate the effort. So the outcomes from today is what’s going to inform that decision from the AD and the IESG and tell us how to go further.

So some of the things that we are going to consider or that we want to have you think about as we go through the BoF is the clarity of the problem statement. We want it to be something that we all understand, that it is clear, the direction that proponents want to go in. We want to assess the willingness of people to participate in the future working group. This means authors, reviewers, people who are going to contribute in other ways, people who are going to develop, in this case, models and abstractions. It is important for people to be able and willing to participate in that. And we are going to ask questions at the end related to this. So think about that. We also want to assess the suitability of the charter itself. So we are going to go in detail through the proposed charter so that everyone can comment and see if there are any pieces missing or we need clarification on any of that. And we want to again measure or gauge support on support to form a working group. So think about these things as we go through the agenda, as we go through the presentation. At the end, as I said, we will do a series of questions and polls to help the AD and the IESG.

Yeah, that’s a good point, and thanks Alvaro. I think one more thing we want to say is like we don’t need to finalize the charter in this meeting today. So as long as we have a good understanding of the problem statement and what kind of changes are required to the charter at the end of the day, I think it’s really, really good as a positive outcome. And as Alvaro said, we’ll be running some polls, so please join on MeetEcho, even if you are in the room. So like there’s like a MeetEcho light client. Please join there because we want your voice to be counted because we don’t do hums anymore. Please go ahead and join the MeetEcho in the local tool. Okay, so let’s get to it. This is the agenda for today. We are here at the session introduction. So now Mahesh, if you want to say something at the responsibility, please go ahead.

Mahesh Jethanandani: Alright, good morning everyone. I want to thank Alvaro and Suresh for stepping up to help me run this BoF, and to Joe and Dhruv for holding the pen on the discussion around the charter until now. As the chairs have clearly articulated, I think there are two elements that make a BoF successful. One is, of course, a robust community support. And you are here, both onsite as well as remote, I hope, to provide that support. The other is the clear articulation of the problem statement and what the work group clearly wants to work on. Anything short of that is going to muddy the discussion and will make it that much more difficult for me as an AD, as well as IESG, to really figure out whether there is a clear problem statement to be had or not. So let’s try to keep that focus going into the BoF. The work items that we do identify, at least initially, I’m hoping would be something that we can achieve in a short period of time. And by short I mean ideally I would like it to be within one or two years, just to demonstrate that there is a problem, there is work being done. And remember, whatever charter we come up with, it’s not the be-all and end-all of all charters. Things can be rechartered, items can be added, if we are able to demonstrate that what we have started off with is achievable. So let’s try to keep that also in focus. Finally, I just want to thank the proponents who have put in hours and effort into trying to discuss this, and I wish them all the best. Thank you.

Alvaro Retana: Thank you Mahesh. So as I said, we’re over there in the introduction for the session. We are going to have a problem statement presentation. We are going to discuss what we are trying to solve. Then Brad is going to be the only remote presentation. He is going to talk about operationalizing the TMF and YANG based APIs. It’s a short presentation on that. He said he’s going to be remote. Chongfeng is going to have a review of the proposed work. So that’s where we’re going to start looking at the charter in a little bit more detail. He’s going to take the work items and map them to current proposed work. Then we are going to go into detail through the charter. And as I said, at the end we’re going to ask some questions, around what I mentioned before: interest and participation, suitability of the problem statement, clarity, etc. And we’re going to make some conclusions. So okay, let’s start. Benoit, you’re up first with the problem statement.

Benoit Claise: Alright, good morning. So let's discuss about the problem statement from ONSEN. I've been trying to collect information from different sources, different feedback, even discussed during this week, some coming from drafts. So the first source of feedback is an IAB workshop. If you've been working in operation, maybe you know, or you should know, this very old RFC 3535, which was an IAB workshop in 2002. In there, we collected information from implementers, from operators, and about operations. And that RFC led to the creation of two different working groups: first, the NETCONF working group that we still have now, and the second one, the NETMOD working group about the data models. And it led to the entire change in operation for data model driven management. What happened end of 24, a second workshop called NEMOPS, Next Era of Network Management Operations. So more than 20 years later, we looked at: okay, what are the new requirements? And if I just read what is highlighted there in yellow, the second part: NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. So what do we say here? And by the way, thanks Dhruv and Wes for this report, which is going to be an RFC done by the IAB and published soon — definition of soon. If I take out of that report what I believe is linked to ONSEN, this is like: it was noted that the IETF’s focus should be on defining abstract service-level data models, since this is the only thing the community may ever agree on. So this was from this workshop, multiple input, multiple operators, vendors, etc.

Now, we have service models. Great. And the IETF has produced many of those. If you look at the top right-hand side, we’ve got like data models in network devices. We’ve got the network controller. We’ve got the service orchestrator. And with this, we’ve got service models, for example the L3SM, service model for customer-facing. And we’ve got L3NM, for example, for network module, the resource-facing. Fine. So there is not a lack of models so far. However, the operators still have a lot of challenges to try to get them working in production in a consistent, scalable, automated way, in a multi-vendor environment or multi-domain. Because if you look at similar service models, sometimes they produce something which is not quite the same in terms of semantic. So it hampers integration and the deployment in operation.

So in the draft that I mentioned, the first bullet point, China Telecom tried to create a new service. They call that Data-Intensive Workloads Transmission. It requires on-demand ultra-high bandwidth, predictable completion times, dynamic workflows. The point is not to delve into that use case. The point here is they tried to reuse L3SM. And actually, there is like — it's difficult. There is a lack of temporary concept. It assumed the connectivity is on all the time. Lack of dynamic bandwidth. Lack of SLOs, because if we create services, it's because we have customers. If we have customers, they pay for that. So they want to assure that the service is running fine. But we don't have that. Lack mechanism to integrate the slice service templates. So it's difficult to reuse the models that we’ve been creating for a new model.

Now, two YANG trees, because I cannot resist. You don’t have to read those. Just read the different points, the different colors. If I look at the L2SM and L3SM, they have the same concept. Alright. And by the way, it comes from your draft. Thanks. So the same concept: a VPN service, a site, VPN policy. But if an operator is managing both of them, then they have a lot of duplicate information. Now, what about a new service? If you come back to the previous use case from China Telecom, does it mean that they have to create yet another new service with what in there? A site? A policy? Or a VPN service because it's maybe a type of VPN service? Then what does it mean? That we go and duplicate everything? So I see that there is someone in the queue. Do we ask — do we go for at the end or in between?

Alvaro Retana: Is this a clarifying question? Ken-Ken, is this a clarifying question? Go Benoit.

Benoit Claise: Okay. So another challenge. What about the OSS/BSS integration? How to integrate what we're doing in this world at the IETF, which is YANG, with something which is not specifically YANG? If we go to TMF, they’ve got a different set of APIs. Right. And we've been knowing for years that those two worlds, they need to meet somewhere. The way I put it in my head is that I always said the IETF is bottom-up: we started from YANG model in the device, resource-facing, customer-facing. And somehow TMF is bottom-down: they define intent API and someone is going to just populate the API. But the key thing is that the operators, they are in the middle. They have to join the information, and this is painful. Because there is a misalignment of layers information. The service abstraction may not cleanly map with the underlying capabilities of network. What I put on the right-hand side, and it's on purpose that you don't read everything because it doesn't matter what the content is. The point is that this operator had to create his own API to actually map TMF to what we do in L3SM. So it's yet another in-between layer which is — I don't want to say spaghetti code, but I mean, for God's sake, we deal with data models. Can we have something more deterministic than this?

Then there is also another challenge which is the fragmented life-cycle challenge. If you do the typical workflow: instantiation, monitoring, modification, decommissioning. It’s actually fragmented. It’s per-service. But should it be per-service? No. I mean, if I need to activate something, do we really want to have something different if it's an L2VPN or an L3VPN? Maybe not. What about service duration? Expiration? Or just the rollback? And I'm not even talking about the service inside a service, which is also something important. And it's great to do configuration. Right. And many of those services are based on the configuration. But as I said, we do this because we have customers who pay, so we want to do the service assurance. And there are limited standards on how to do that. Now, I looked up in the L3SM: okay, yes, we’ve got actual site — or sit — start and stop. Great. But we're not able to observe the current status of the provisioned service. And in the end, whether this is like L2, L3, banana, or whatever, you know, I — I would like to be able to monitor this the same way. Because otherwise per-service, I have different, different ways to do it. The only thing I care about personally, this is to try to solve closed-loop. Right. If you were in the Ops area yesterday, we had three great presentations from three Chinese operators: China Unicom, Telecom and Mobile. I would say maybe the three biggest ones in the world — I don't want to have a beauty contest, but look at the number of subscribers, you will see. And they mentioned all of these: they want to go to ADNL 4. Right. But we still have mapping issues about configuration, how to monitor things. So how can we be doing closed-loop? By having a lot of developers mapping everything? We could do better. Manual monitoring is fine until you’ve got a lot of service.

The conclusion: we know service models are important. But there are challenges. I tried to list some of them, from different sources: from the IAB workshop, from the problem statement, from your draft about the Service YANG. There are some more challenges in the draft, and we’ve been discussing again this week. So there are challenges. We should really do better than what we do today. It's great that the IETF does service models. But if I look at the big picture, we had like L3SM working group for L3VPN. We had L3NM for L3VPN customer — sorry, resource-facing. L2NM, L3NM. We had like — the attachment circuits that were done in OpsAWG. We have some in the TEAS working group. And somehow we should do better to just link all of these. So in my mind, we passed the time of: do we have challenge? Yes, we do have challenges. So the point of this BoF is to say: do we agree on which one we want to solve here? That's maybe where I'll stop.

Alvaro Retana: Thank you Benoit. Does anyone have any questions for Benoit? Ken-Ken, you’re on the queue again. Do you have a question?

Ken-Ken: Oh, no question. I just give me some my — some comments from China Telecom. This is Tantanhuang from China Telecom. In the last few years, we have been committed to advance task-based joint data transmission service. In this progress, we do meet the problems which is — presented just now, that the exist — that the existing RFCs about the several VPN service YANG models are hard to use in practice, since they cannot meet the requirement of dynamic network provisioning, dynamic bandwidth adjust — bandwidth adjustment and integrated capabilities fragmented across existing specifications. So I think it is very necessary to deal all these problems with an enhanced end-to-end YANG model. And I think ONSEN is the right place to do so. Thank you.

Alvaro Retana: Thank you Ken-Ken. Chin?

Qin Wu: So my thanks for your presentation and I think my comments, you know, you for the L3, for example L3SM applicability usability. I think current model already support SLA like latency, jitter and bandwidth. I feel it's a lack of, you know, clarity. And you mention integrated slice service template, we have separate network slice service model, right? So this one I, you know, not fully agree. Yeah. And in addition, we move to the next slide. For high-level duplication between service model, actually, you know, L3SM, L2SM focused on developed these separate model. We think this is technology specific model. We think they lack of, you know, commonality. That's why we — we developed separately. So I’m not clear, you know, you want to propose to define generic VPN model or you think we should follow same approach as L3NM, we, you know, fresh out common VPN data model, use this as a basis, you know. So I — I think this is lack of clarity, you know.

Benoit Claise: Alright, so let me address two different points. The first one about, you know, the — the service — the slice service templates. I didn’t make those slides on this specific point. It comes from operators. And the agreement here is that if the operators want to describe exactly their problem on this one, they can. On the duplication as well, they can. The point is that what I see is what we're missing is somehow building blocks that we could reuse. Right. Because, you know, whenever they say we have two separate model, I have duplicate information in my NMS/OSS. So, you know, we could say from data modeling, it’s true or not true, but this is what they have to do. And they don’t do that for just for the sake of doing this. But we have many way to do this. Take attachment circuit as example, we try to refactor these, you know, like L3SM, L2SM to different building blocker, we can use these as a log of building block. So we can put together, you know, compose to support the various different service. You know, go back to the previous slide, I think, you know, for L3SM, we do make second release. We support, you know, various different service like 5G, URLLC, yeah, I — I think it's very flexible. You can support various different service. So in this one I'm not convinced.

Benoit Claise: I’d like to reply to the — the comments Chin just raised about the SLO integration. I’m the — one of the author of network slice service model and in the network slice service model we define very specific slice service level objectives and that can be shared between many services. So — so some service providers, especially Telefonica, they also had the project to implement L3SM together with this template. So I think the this bullet means that. Layer 3 service model they hide all those definition inside the model. It's not that obvious. Yeah.

Qin Wu: Thank you. Okay, thanks for clarification and may move to the slide 10. Yes.

Alvaro Retana: Can you keep it brief? We can have further time for discussion but like keep your comments brief and we’ll come back to it for sure. But please do make your comment and we are closing the queue after Adrian. If you have further points like we can take it up in the open discussion. Thank you. Go ahead Chin.

Qin Wu: Usually we have, you know, like L3SM, L2SM focus on, you know, connected service configuration, service configuration. So you want to also support this observability operation, you know, data — you know, management. This seems we have separate model like VPN performance main model, service assurance model. You — you want to integrate as one single model to support this. So this is not clear to me whether they should be separate.

Benoit Claise: So I'm kind of hesitant to answer this because we're going into the solution space.

Alvaro Retana: Exactly. Yeah, so — I think we can certainly discuss this after, Chin. Like it’s not part of the problem space, but we can look at the solution space separately. Thanks. Thomas.

Thomas Graf: Thomas Graf from Swisscom. Thanks a lot, Benoit. I think what you’re describing here makes perfect sense. We see this issue on limited observability. We have the issues on like service models not aligning very well. We need to highlight the workflow aspect because that’s — that’s a big problem. What I’m missing here is another problem statement as well is mappability. So just like my experience, for instance with Pro-P and YANG models, they work perfectly fine with IETF YANG models. All perfect. If I try to map TMF models with YANG service models, we tried multiple attempts, we usually failed, and the glue you mentioned before where vendor-specific exactly — this is what we applied. And I think that should be — is something we should try to solve here.

Alvaro Retana: Thank you.

Houmei: Houmei, Huawei. Actually the when I read the title of this BoF and the charter, this would be very useful to introduce the idea of the abstraction. But what I look into here, I believe things are a little bit confused because you detect there are kind of duplication among multiple models. And I believe duplication itself won't be a problem because there are different implementers implementing towards different scenarios and services. So what you are trying to do here, if I understand correctly, is a kind of generalization and creating a kind of common model header for multiple data models that would changing some existing implementations compliance and I was worrying about that. So I do look forward for this kind of abstraction, but it would be extremely useful if the working group, sorry, I'm not sure whether there is going to be a working group to produce a kind of methodology or guidance on how people could do the abstraction correctly or instead of we create more YANG models because we have more than 10 working group working on different kind of data models. Thank you.

Italo Busi: Italo Busi from Huawei. Okay, I was a little bit tempted but at the end I decided to come here. It was — Qin was right, there is something in the network slicing service model. Unfortunately, there is something else in TEAS, which is the TE service mapping which is augmenting layer 2 and layer 3 SM with this type of information like SLO delay and constraints. The issue I see here is that there are, okay, two issues: adding new features which is always possible and the fact the other issue which is concerning me more is that you’re right, there is a lot of duplication or a lot of inconsistency. The problem I see is that we have a set of YANG models which are doing more or less the same thing in a different way in overlapping and in the gaps and I don't see efforts on aligning but I always see efforts on adding a new YANG model. So add increasing the mess from N incompatible YANG models to N+1 incompatible YANG models doesn't help. So I think we should be very careful here in having something which rationalize and give a way to go into one solution. Otherwise, it’s — we are going to add the mess to the mess. Thank you.

Kris Lambrechts: Kris Lambrechts. The thing that was pointed out several times here is that duplication in itself is maybe not a huge issue. You might think that that’s sort of okay, and I tend to agree with that, but what is sort of not mentioned is that there are interop — there are interactions between these different models. Right. So particularly in the service models, you’re looking at sites. Well, for the customer, that is one and the same site. Right. If you duplicate it, it’s really he’s trying to express things for different services, say it’s L3VPN, L2VPN or it’s optical delivery. You want to be able to express a relationship between these things. That is still the same site, the same physical address, and so I might want to express that these things are, in fact, the same related and be able to do that. There’s also the fact that these models are meant to be customer-facing, like you should be able to offer a Netconf connection to your customer directly, order things over that. Doing duplication there, that’s not nice.

Adrian Farrel: Adrian Farrel. Thank you Benoit for attempting this rather difficult task. I’d encourage us to try to frame the problem not in negatives, if you get my negative. So here, for example, you’ve got “service abstractions may not cleanly...” Let’s talk about what it is we want to achieve, not what it is other things don't do, and try to avoid criticizing what we've already done like L3SM, which actually delivered precisely on charter that the AD set and was worked on by operators. So if we can pick up what Joe said in the chat and try to reach consensus on what we want to achieve rather than the negatives.

Benoit Claise: Good point, I should have followed that guideline. Looking at the reaction in the room now.

Alvaro Retana: Thanks Adrian. Olga, we closed the mike, so unless you have something really relevant for this and you can make it quick, please.

Olga Havel: Olga Havel, Huawei. I did many times in the past mapping from TMF and MEF models to IETF layer 3, layer 2 models and all that. So I absolutely see some of the challenges. (Speak into the mike, please.) The general approach and also the life-cycle is an issue, but there are different ways maybe how you can do it. Maybe you don’t need a new models to achieve it. Maybe some kind of labeling or some kind of approach of kind of trying to reuse the existing model to categorize different things and align them. So that’s maybe a candidate approach of looking at the problem. Thank you.

Alvaro Retana: Thank you Benoit. Now we're going to move over to Brad, who is remote. And okay, yeah, go ahead and speak. Hold on, let me give you the control of everything.

Brad: Thank you. Okay, good. Okay, go ahead. Thank you. I’ll move a bit closer. Hopefully that solves the echo. So really, this is just a bit more pictorial in terms of those views, right? Where a lot of OSS vendors have adopted TMF APIs and they enable business layer interactions between different operators and also at the service layer aspect point of view as well. They have interfaces defined that lead in to the network and the resource layer, and I think that’s part of the charter as well in terms of some of those specific entities. But a lot of those over many different generations, so can be actual explicit resources, but there’s also a set that’s all focused on services as well, which I think was the lead-in from Benoit in terms of the service models and so forth. So they do do provisioning and assurance side from a service aspect point of view, but what comes out of the network is fundamentally YANG-based models. And the data models between the two of those interfaces are explicitly different. And it’s not like they just easily match up together. And typically, from an operationalization aspect point of view, the operators end up needing to do that integration between them. There’s no easy other solution. And I think what we heard yesterday from China Com and that Benoit mentioned and even a minute ago from Thomas in Swisscom, it’s the same answer. Right? You end up having to do this explicitly yourself from an operator aspect. Which means, of course, that none of that is typically reusable. I think Thomas highlighted that as well in terms of it’s for you and almost you only. If those TMF products are actually off-the-shelf products, that is relatively high cost in a life cycle that the operator’s actually got to bear over the period of time. I think that was largely — there is another slide in terms of the previous generation. This is the previous generation, I suppose, where TMF’s at the moment. But if you look at TMF’s evolved mission with autonomous networks, some of these interfaces have actually changed because they’ve moved to a semantic interface between all of those layers as well. So some of the interfaces and the APIs exist within the layers, but between the layers, they’re focused on moving towards a semantic interface that is a layer of abstraction above a service. So it only specifies what are the requirements to be provided. Not so much of what is the service or what is the network configuration, but purely what is the requirement in terms of how much bandwidth do I need, what’s the SLA, what’s the packet loss, and it’s left to what is the network deciding what’s the service it’s going to provision to meet the requirements. But it is a fundamental shift in terms of it’s no longer a prescriptive interface. It’s now a declarative interface. It’s just asking for a set of requirements. And how do you manage that into the network at a lower layer as well becomes a question of that everybody will probably be facing coming up. And I think we heard it from China Com yesterday as well in terms of how to deal with semantic interfaces where the vocabulary may be different on both sides as well. But at the moment, I think that’s probably pretty much the same answer in terms of it will be up to operators to integrate between the two as it stands. It won’t change in terms of whether it was from the previous one. But I think that’s about it, as I said. I think the lead-in from yesterday from China Com and Unicom and so forth and Thomas’s comments were completely aligned with what we're discussing. But that’s — that’s it over. Anybody got any questions?

Alvaro Retana: Yes, Adrian.

Adrian Farrel: Adrian Farrel from China Telecom. You know, I want to ask one thing. If there is difference between the TMF SID and the northbound YANG interface, who will be changed? So we from the TMF side will be changed or the YANG API will be changed? If the YANG API will be changed, then we need redesign all the service model that produced by the IETF.

Brad: So I think we're getting into some of the solution possibilities in the discussion, right? So there’s probably a number of ways that you can make this work, but I think that’s part of the BoF, right? To come up with what is the best way that — to make this actually function from the network into probably TMF APIs. I’m not probably going to get into which — which one needs to change, it’s probably the focus of the BoF, right? To sort out which is the best way to do it.

Adrian Farrel: Oh yeah, you know, because as I know, the design of the service model is just — it does not reference the TMF SID. So I think there will be challenge for these two interface collaboration together.

Brad: Oh yeah, I mean, that’s why all the — all the operators actually do that integration themselves, right? At the moment, because there isn’t that close match. And I think even Benoit mentioned the same thing. It doesn’t easily fit in from one to the other, right? So the question becomes: what is the best solution that can actually be reached to — to achieve that? Okay, thank you.

Qin Wu: Qin Wu. So thanks Brad, you know, provide good input from TMF side. Hope in the future we have more people in both TMF and IETF to work together and bridge this — help to bridge this discussion. So I see you introduced two slides. For the first one, it seems, you know, you try to mapping the information model to YANG-based API. And I think in the past MEF or ONF do the same things they do the translation mapping from information model to YANG. You will lose a lot of information. So it's not a lossless mapping, right? I think this focus on syntax level mapping. And second slide, and it's more focus on semantic level mapping and to mapping property at the, you know, TMF API level and YANG-based API level. So Brad, I'm wondering what you propose IETF to do, to follow the second — the semantic level mapping or syntax level mapping? I think syntax level mapping is more challenging.

Brad: I think it’s up to the BoF to decide which one they want to tackle, right? I think there’s a couple mentioned in the charter explicitly, but I do think that it’s up to the team of which one they want to tackle, right?

Alvaro Retana: Right, so we're going to go into the charter in a second to look specifically at what is proposed there to be done. Mahesh.

Mahesh Jethanandani: Mahesh speaking as a contributor. I — I dropped out of the queue because I think Qin kind of asked the question that I was going to ask, which is: Brad, listening to your point, you almost seem to be suggesting that the operators have been trying to solve this problem and maybe there is really nothing for IETF to do, or do you really think that there is a solution that IETF might have in trying to help the operators solve the interface between the OSS/BSS layer and the network abstraction?

Brad: I think it’s the latter, right? Of what can IETF do to make this easier, right? And I think as was called out earlier, it may be potentially liaisons on both sides of things to — to actually make that change, right? But it’s what — what makes it less friction, I suppose, between the two layers to make it easier for that integration to actually happen.

Mahesh Jethanandani: Okay. So a combination of liaison work combined with work in IETF. Thanks.

Alvaro Retana: Okay, thanks Brad. So we’re going to move on to Chongfeng, who’s going to talk about the work items in the charter and start, you know, talking a little bit more about what is proposed to be delivered.

Chongfeng Xie: Hello everyone. This is Chongfeng Xie from China Telecom. It's my pleasure to give this presentation of review of proposed work. With this presentation, I'd like to walk you through each work item of ONSEN. So let's start from abstraction. Nowadays, operators rely on abstraction to build, deliver and maintain different services in a simple way. So here, abstraction refer to the process of defining simplified, high-level constructs that can represent network and service capabilities. So for operators, abstraction include network and service model. They enable the integration of management components and automation of network management system without exposing underlying device-specific implementations. That’s important for network operation. And based on the comments driven by the questions of Benoit in his speech, ONSEN aim to make service network abstraction easier to implement, improving automation, operational efficiency and interoperability. So there are five work items in the current charter of ONSEN. They are operational motivation for network service abstractions, update to YANG network data models for LNM, L3NM, L2NM, update the YANG service data model for L3SM and L2SM, and develop a new framework for reusable service YANG data models, and define the interface between YANG-based service API and OSS/BSS layer.

So the first one is operational motivation for network service abstractions. We all know that IETF YANG data models have been around for more than 10 years and have given great contribution to the network operation. But we all found that sometimes they are operationally incomplete. As mentioned by the IAB/NEMOPS workshop, that operational workflows for deploying, monitoring and evolving these abstraction are inconsistent and poorly integrated, despite much of the underlying IETF machinery already being in place. So with this problem, for operators, these abstraction are not easily to be seamlessly pieced together to form a coherent network or capability. Maybe this is due to many reasons. So in this framework, in this work item, ONSEN plan to develop operational motivation document to catalog and deploy use cases, document why difficult to use current models in production, document approach of operationalizing them in a consistent, scalable and automated manner. There has been one related draft in the data tracker which align with this work item. It should be noted that even though there are several drafts in the data tracker which align with related to this work items, it does not mean that they are the chosen solutions for these work items yet. They do show that people are willing to work on this and provide contributions. If the work group is set up, it will discuss and the adoption work will progress.

So the second one is update the YANG network data models for L3NM and L2NM. These two models provide YANG data model for network configuration and operation L2VPN, L3VPN service cross provider networks. So they disguise the specific implementations, and based on operational experience, some missing features were identified. For example, the lack of some SRv6 support and more BFD parameters. And so in this work, ONSEN plan to identify limitations in current network models and then update the existing L2NM and L3NM models by supplementing missing functionalities, configuration blocks, address operational limitations, meet the need for more granular control. So there's one related draft for this work item.

The third one is update the YANG service data model for L3SM and L2SM. These two service models provide YANG data model for customer-facing configuration management, L2VPN and L3VPN services. And several shortcomings and needs were gathered from years of deployments. For example, the lack of Layer 2 QoS support for L3SM, duplication. Here, duplication means, as has been mentioned by Benoit, that there are some — the two models model the some common concepts separately and independently. So this forces operator to maintain redundant information in network operation and make the operation complex. So maybe a new base model is required. There was one related draft which from — maybe from China Telecom.

The fourth one is develop framework for reusable service data models. And we all know that service rely on common building blocks that are not adequately taken into account when designing service models. And some recent service models were designed to provide such common blocks. For example, AC-service. This is a very positive example. And however, efforts still needed to optimize how these various service can be offered. So in this work item, ONSEN plan to develop approach that allow to decompose the complex services into composable and reusable ones.

The last work item is define the interface between YANG-based service API and the OSS/BSS layer. This is important because it concerns about how to expose network capability to the ecosystem. Right. To guarantee the value of operators' networks. So ONSEN here concern about how to integrate, how the IETF YANG-based models integrated with external community such as TMF, Open API. And so this can be enable the current model can be consumed by external community. Here this is the integration, automation glue that concern IETF standard to real-world workflows. Currently it's a significant gap in the IETF landscape as has been detected earlier. So this ONSEN plan to develop mechanisms to map YANG schema to OSS/BSS models and APIs, and also give guidance for operationalizing, implementing YANG-based APIs.

So since the beginning of ONSEN initiative, a couple of documents have been received, which show people have interest to this work item, to the BoF of ONSEN and willing to provide long-term contribution. This is it. Any question?

Alvaro Retana: Anyone? Questions, comments? Yes, Luis.

Luis Contreras: Luis Contreras from Telefonica. Chongfeng, in your previous slide, the slide that you were commenting about the OSS, the previous one. Yeah, we here have been discussing with this relationship with OSS/BSS thinking from the perspective of TMF forum and so, but there would be other consumers of the network. So we can anticipate all these cloud providers and so. So the idea here, when we generalise — we are talking about OSS/BSS, would be only to restrict to TMF forum, I mean the classical Telco way of provisioning services? Or it would be something a little bit more open, also considering all the rest of consumers, potential consumers of the Telco network? What would be your comment here?

Alvaro Retana: So if I can — when we go through the charter, Luis, you’ll see that it is defined in a general way. So what I would say is that it’s going to be left up to the working group to decide specifically is it just TMF or do we go...

Luis Contreras: Okay, got it. Thank you.

Alvaro Retana: Yeah, and Luis, like to follow up on Alvaro’s, right now in the charter it’s like used as an example of things that we need to do, but we can decide like what the working group has wants to work on, right? Got it, thank you. Go ahead Jay.

Jay: Jay from ZTE. Would you please go back to the work item 4? Yeah, thank you. What do you mean by saying reusable service YANG data model? Because you mentioned the common building blocks. So would you please to clarify with some examples of what exactly is the common building blocks?

Chongfeng Xie: Okay, thank you for your question. Actually, this has been discussed a little bit. This means that some common build block can be shared between L2VPN and L3VPN models. If you compare these two models as Benoit has shown, that there have some common nodes or features. So this can share because this cause network operation more complex and because operators need to maintain redundant information. For the future flexible service delivery, it may be needed to define a common base modules for service delivery. Yeah, that’s what I mean.

Jay: Thank you.

Scott Mansfield: Scott Mansfield, Ericsson. My point has already been answered, but since I stood up, I thought I would say it anyway. On working item 4 or 5, sorry, the next one, I would strongly suggest, and it sounds like it’s already being done in a generic way because there is at least one other example I can think of this, and that’s in O-RAN space, where there’s a radio domain and a transport domain, and those two do — they both use YANG but they use it in different ways and having some kind of way to do this mapping in a generic way would be great. Thanks.

Daniele Ceccarelli: Daniele Ceccarelli from Cisco. So, I think the charter is very well written and, I mean, when I read it I was super relaxed. I said: okay, yeah, hey, that’s good. Then I look at these work items and I have a tiny voice here in the back of my head that says: backward compatibility, backward compatibility. So the work items seem to be that are taking a risky direction. In the sense that L2NM, L3NM, they are widely deployed in networks. We have a lot of different implementations, they are in production, etc. I have the feeling that sometimes we are not considering backward compatibility with what is existing today. And that would be a kind of problem. So as long as we build on top of what already exists, everything is fine. There is a lot of room for improvement, a lot of things that we can do better. But we should try not to break what is already there because we are not speaking about something new but we are building on top of something that already exists.

Kris Lambrechts: Kris Lambrechts. I'd like to maybe first get back to what Daniele just said. I think there might be a decent amount of implementations of the NM models and I’d certainly love to see what backward compatibility aspects we need to maintain there. I'd love to actually speak to people who have implemented the service models, though. Like, I know I have, but I feel like it's not actually widely deployed otherwise. So if people want to come up later and sort of discuss what they have there and what backward compatibility aspects they see, I'd love to learn more. Why I first joined the queue was to go back to work item 4 and sort of respond about what is the main reusable aspect that this is about, which is really about those sites definitions, right? So this is the customer interface, right, between operators and customers, and that definition of sites, site addresses and sort of site devices in the service models is the key thing that I think should be reusable here across a wider variety of services.

Adrian Farrel: Adrian Farrel. Actually, I like that point. The understanding needs to be that the service models we've been building are service models between the operator and the operator's customer. And the fact that they don't have things like BFD in them is probably a good thing, unless the operators really want their customers playing with what functions are inside the operator's network. That doesn't mean there isn't work to do, but I don't believe it's building on top of this the existing service models. I believe it's building under those service models, which is kind of what the LXNM was trying to do.

Chongfeng Xie: Yeah, for work item 4 and I think try to decompose the complex service into the, you know, reusable build block. I think there’s many way to do this, you know, flesh out common building block but YANG model actually it's very complex. Another way is you can follow some approach in TEAS working group, they established profile really can, you know, reduce this kind of complexity.

Kent Watson: Kent Watson. I was happy to see in Benoit's slide the problem statement from NEMOPS workshop. And there was another outcome from the NEMOPS workshop which was the potential desire to create a data model transformation framework to go from the service level models to the device specific data models. So it would be not necessarily the API, the Open API that’s being exposed northbound, but more the infrastructure, the code that would be below the OSS layer to convert to the communicating to the devices. There was suggestions of perhaps an open source effort to create such a data model transformation framework. This kind of tags into what Adrian was just saying as well, with having the what’s under the hood. You wouldn’t expose BFD directly, but internally a service model might map to BFD. So, I was just wondering, I don't see this in any of the work items that you were presenting. Is it something that you think should be added to the charter or into the scope of this effort? Okay, thank you.

Alvaro Retana: I think we can talk about it in the charter discussion when Dhruv and Joe talk about this. You can say: hey, if there’s missing stuff, like feel free to propose it, right? But yeah, thank you.

Alvaro Retana: Okay, thank you. And speaking of which, we're going to move over or move on to Joe and Dhruv.

Dhruv Dhody: Hello everyone. So we will now be going over the charter. Joe and I have been working, we have been listening to the feedback that we have been getting all this time on the list, and we have tried our best to reflect that. But now it’s the time to get more bigger, new eyes and get feedback on how the charter is going. And some of the discussions that we had, it felt like the first meeting of the working group, like people are debating solutions, so it’s pretty good. So with that eye, maybe it will be good to look at the charter, whether that charter covers the discussions that you want to have when this gets formed. So with that, we have a GitHub, so we have been maintaining it, it’s linked here and it’s on the mailing list as well as on the data tracker page. So you can look at the history, you can look at all the contributions that have gone from multiple people for the current charter text.

So like in any charter, we start with setting the context. We say why we are doing this, we refer the various different services for which we need abstraction. We refer to the IAB workshop and say how this problem was kind of highlighted. Then we also focus on: what does abstraction means in this context, and clearly put a definition for that, which you see in the third para. And give a high-level aim for what this working group wants to achieve.

The next set in our charter is to identify four core areas. Sort of aligns with the work items that we saw in the earlier discussion as well: documenting operational needs and motivation. Yes.

Alvaro Retana: Hold on. So we have Sue, you're in the queue. Did you want to say something about this? Okay, okay. So as you go through the different pages, let’s, you know, pause for a second just in case someone wants to comment on that specific part. So we can take, you know, comments as we go and then at the end as well. Okay, so Sue, we’re going to wait for the end, okay? Just Dhruv mentioned the GitHub repository. We put a lot of words up here in front of you. We’re not going to do a live edit session of the charter here in this meeting. If you have suggestions, for example Adrian mentioned backward compatibility, that’s kind of a big block, please go to the GitHub and open issues. That’s the best thing. Then we can start discussing this. We can bring these back to the onions list, it’s not called Onsen, it was open before we changed the name. We can discuss them there, but we’re not trying to do a live edit session. So high-level discussion points here, big items that you would like to bring up, but we’re not going to wordsmith this live. Thanks for that.

Dhruv Dhody: So with that, Sue is the only one, so we’ll move ahead. So with this part of the charter, our aim was to identify the four core areas: the first one, the documenting the operational need and motivation for this work; making sure that this abstraction work is done with a coordination as one of the key focal areas of why we want a new working group, which could be a focal point. We identified various YANG data models that we will be maintaining. This is the work that is done in some working groups that have been closed, some working groups that currently exist. Making sure that we learn from each other. Since over time we have developed service models in our own vacuum, we have now some deployment, we did the workshop, hopefully we can learn and when we are doing this maintenance activities, whether it includes refactoring, restructuring, adding a reusable component, we try to do it in a consistent way and learn from things that we have done in the past. And the final one is the reusable abstraction, which is a work item which has been proposed, that we should look at whether there are commonalities in all these service models that can be easily reused and we should come up with a mechanism in which we can share this extensible foundation across service models. Any questions on this part? No.

The next set adds a little bit more things that we will also focus on. Okay, Wim is coming.

Wim Henderickx: Wim Henderickx, Nokia. I just want to — so thanks, by the way, for the charter, I think it’s really well done. I would like to stress the composability aspect, because I believe that there is not one YANG model that’s going to serve the world, right? So I — I'm a big believer of focusing this working group on these composable building blocks and try to make them complete, because the composition is going to be different for different people. Of course, there will be lots of commonalities, right? But there will, I — I'm of the opinion that you need to have the ability to, as a — as a consumer, to customize it, right? That’s why I’m a big believer of making these building blocks composable and try to make them complete such that they are, let’s say, implementable and actually reusable among different use cases, right? I'm also personally a big believer of not doing L2 and L3 because I'm a believer of: you provide connectivity as an abstraction, and L2 and L3 is a property of that connectivity, right? Which has led, in my view, to some of the problems of the reusability aspects, right? So I think we need to first try to see: okay, what are the problems that — and what are the biggest bang for the buck that we help from an operator community to make progress and to actually use some of these models, and then try to go to the next level and and so on and so forth. So I'm what I’m trying to say is that try to scope the initial deliverables to something that delivers the biggest bang for the buck compared to — with respect to the operator community. And I think right now if you try to do all of that, it’s a lot of work. So I'm what I’m trying to say is that I — I would propose to focus on these building blocks and make them complete because I believe that’s a cornerstone for all the rest.

Dhruv Dhody: Thanks Wim, thank you.

Alvaro Retana: Can I — Wim? So one of the things, if — first, if you think that there are missing big items, open — open a PR or issue, please. One of the things to your point about scope of work and how much do we want to bite off at first. One of the questions that the chairs are going to ask at the end is who's willing to invest the time and not just the time, but the resources, maybe even build a reference implementation of some of this. We can't just do more paperwork. So if there are tangible, concrete things that we should be doing initially, and we think we did that, we think with the framework, we think we have some initial operators that really want to extend and revise the great work that was already done in these network and service models. We wanted to focus on that concrete work knowing that once we get some momentum we can start tackling some of the bigger things and maybe recharter V2, V3 and so on. But if you think that there's something to be called out, please do that for us.

Wim Henderickx: I will — I will do, yes. I think one of the things that is not there exactly is the I — what I call policy or — or how you consume, because that’s how you can do abstraction, right? So you can basically say — that’s why I'm focus on like L2 and L3 — so you could basically say: okay, here is some properties that are specific to the operator that are going to be used within that environment, that doesn’t have to be in the model but you actually use it when you render it to the device element that you actually going to consume somehow. So you don’t need to actually model that but you need to have an ability to do that indirection in order to deliver the abstraction layer. Do you see what — so in other words, like: okay, L2, L3 is maybe a bad example, but if you go for example, say: okay, I have an L2 or a VPN service that is basically EVPN-based or IPVPN-based, you can actually decouple some of that with respect to the real instantiation stuff like that. So there is also an aspect of let’s say approaches on how to build abstractions, which is not necessarily going to be an actual YANG model but it's more the approach on how you get to an abstraction, right?

Dhruv Dhody: So Wim, just to tease it a little bit, are you saying the problem statement needs to be expanded or like something we do something in the charter to add something explicit?

Wim Henderickx: We can — I will — I will add some comments to the — but I — I'm just I — I have not been directly involved, but I'm saying yeah, so you could actually build some approaches on how to build abstraction which has not — is another deliverable. I don't know whether you want to do that, but that’s what I personally learned doing a lot of effort in this area, which are things that help you make much more reusable components.

Dhruv Dhody: Sounds good. Thank you. Sue?

Sue Hares: Oh, my comment Alvaro might work very well now. When we did the first L2, L3 LSMs and the L3 LNM models, we tried for dynamic models as well. You know, are you going to give it a shot for that? Because in many cases the security incursions are getting worse and reusable models that are also easy to spin out and use dynamically might fit very well with the current environment. I — but it is something to bite off. So part of the reason you got the early light is: is this in your first attempt? Is this out of your first attempt? That would help me make good comments. Um, thank you for picking up this work again.

Dhruv Dhody: Yeah, so Dhruv and I were just — I had the same question. When you mean dynamic, can you give us a more specific example?

Sue Hares: So when we did the R2S, a lot of this stuff was looking Joe to try to make it dynamic so we could, if we had things in routing that blew up or needed a little extra stuff we could spin the models dynamically, add more, right? And or take away and have less. So I'm wondering if you're going to try for that. The NMDA was also an attack at trying to do. I don't see a lot of models spinning up in that way in routing or in security at least, or maybe I don't know and I don't read them, but it’s a whole — are you going to go that direction with this work as well?

Dhruv Dhody: I think, if I understand, because you mentioned NMDA, what Benoit described in some of the problem statement and what we heard in our little brief meeting planning for this was that we need more visibility, observability and extensibility to be flexible. A little to what Wim was saying about composability, using a lot of —

Sue Hares: Extensibility would be really great. But — but extensibility can be: I want to add more features or extensibility can be: oh my goodness, something really bad happened and I want five copies of the model and be able to handle it in scale. And so they’re two different angles. I just, you know, I can’t tell from your words extensibility whether that's in, out, or to be decided later.

Dhruv Dhody: It — a little bit is to be decided, well, a lot of it is to be decided by the working group. What we're trying to get at here is capture things that people are willing to work on in a way that is clear, as best as possible, and then leave it up to the working group to connect everything, to — to instantiate and to build. If you think, though, that we need to call something specifically out that isn't here, that’s what we're trying to get at. Like if you — if you feel that what you want from a dynamic modeling standpoint could be forgotten, and it’s important, we should raise that and discuss it on the list more broadly and see what text would definitely add clarity to the charter for that.

Sue Hares: I spent a lot of my life trying to make it happen before. Of course I want to try to see it happen again. But it has — I just hope it's part of the discussion. Thank you.

Dhruv Dhody: Sounds like it will definitely be if you're part of the discussion.

Fengchao Fu: Hi, I'm Fengchao Fu from China Telecom. And dear chairs and colleagues, my — I support for me the ONSEN working group because from our experience current L3SM cannot meet the dynamic VPN requirements. So I think we need an enhanced L3SM with dynamic network provisioning and dynamic bandwidth adjustment. And China Telecom will contribute to this work. Thank you.

Daniele Ceccarelli: Hello, Daniele again. So, I will go and create the issue to discuss it further. But before that I wanted to check if there is some sort of agreement on — on the proposal that I'm going to make. So documenting operational needs is absolutely the starting point. But then what about making an analysis of what is already there, what works and what doesn't? Let me make an example. We spoke, the example that Italo brought up and that Dhruv that you know very well because we've been spitting blood on the on it for for years, which is the TE service mapping. So the — the requirement is I want to create a service with a given SLO. We have already — a solution already exists in TEAS because we took the L3NM and we mapped it to TE infrastructures. Maybe we could deprecate that and say: this doesn't work for this, this and that reason and this is the new solution. But that’s — that's need something that needs to be done. In the sense that I would like not to have two different operators asking for two different ways to do the same thing, right? So I mean that that could be harmful for — for interoperability.

Dhruv Dhody: Yeah, at least from the TE service mapping and since I’m the co-author there and I looked at the charter and I thought it’s not published yet and within our — what we are currently pointing out here is all the published items. Which way that’s why the keyword there is maintenance. With respect to what we do TE service mapping, first of all I don’t clearly think of that as an abstraction because it’s not really an abstraction you are — a service already exist, you are mapping it to what are the underlying TE properties that exist. But at the same time, the charter text when we talk about relationship with other working groups, that part covers it. We want ONSEN and TEAS working group together to come to an agreement. Is this the right way forward, and if it isn’t, we’ll — we’ll see it. So it’s separate from the item number 3 and item number 4, but I take your point when we come to that slide re-look at that text and see if something needs to change for that part specifically.

Tantanhuang: Hi, it’s Tantanhuang from China Telecom. Just Sue have asked a very good question I think, that she said that the dynamic will make the situation more worse. But actually in practice, we have made some — potential or proposed solution to solve this problem. For example, for the persistent connection in PPP, we — we will use the PPPoE over — PPPoE to get to steer the traffic to the B-RAS and for the joint — joint data transmission we use another anchor. So we use totally different plane to separate joint data from the — small data in the network. And I think this is the — ONSEN's work to generate a new YANG model to solve this problem. So I think Sue's suggestion or question is very good input for ONSEN. Thank you.

Alvaro Retana: Thank you. Ken-Ken, next time can you please get on the MeetEcho line so the remote people can follow along that you’re saying stuff. Okay. Yeah, thanks. Thanks. Okay, Wim, go ahead.

Wim Henderickx: Wim, just quickly. One thing that I forgot to — to mention was I think what I see right now in the charter is — is everything is built on YANG, right? I think here I what I typically see in the reality of the world and that’s again I think something from the operator side is that you have to interact here with existing systems that are in place, right? And so are we going to try to address that as well or are we going to say the whole world is YANG and that’s what we are trying to do? Or are we going to try to also make some guidance on how you interact your — your models here that we are trying to address with existing implementation, for example a site is a perfect example of most likely something that is already in place and that might not have been modeled through YANG in an existing system. Are we also planning to build guidelines or whatever on how that model would interact with systems like that? Because I think I don't from my perspective that’s what I see the real world is — is having in place right now and it — it would I think for me to adopt this it would be great if we could do some of that. But that’s of course a huge another big barrier to go to, so and very difficult. But from an adoption point of view and operationalization point of view, it might be really, really beneficial.

Dhruv Dhody: Yeah, so Wim, like the in the proposed charter there is like mapping of YANG to external frameworks. So if you want to tighten that thing to put more stuff, like I'm sure suggestions are welcome.

Wim Henderickx: And maybe we probably need some operator input but there are some adjacent elements where you typically see that there that’s where the interaction is typically relevant. Right. That was my — that was just a question by the way because I think we refer to TMF as a way to do so, but there is other interactions potentially and I what I’m just trying to say or what I was trying to say is that you could just provide guidance on how to do that. And that and leave it like that rather than going into full details.

Dhruv Dhody: Yeah, thanks Wim. PRs, issues. Issues, PRs. So — excellent point to end that. So that’s the paragraph, the wording that we have used is YANG-based service APIs and we are using TMF as an example. So that we were cognizant of what you were saying and I hope that is being reflected in the charter. So if there is an issues, please highlight. Another point I want to highlight is with respect to the tooling. We say that working group will catalog tooling resources. We want the working group to be active in this space at hackathons, at other things and get the best — like you know what are the tools that are available including the tools that you were talking about. The other thing that I would like to highlight is right now the wording is ONSEN will define an interface between YANG-based service API. A previous version used to say guidelines. We got feedback that no we should commit to something tangible and that’s what we see right now. So if there is disagreement on that, please bring it up on the list and we can resolve it. But there is a lot history on that as well. Thomas.

Thomas Graf: Yes, Dhruv. I wanted to wait for end of the slide but you’re mentioning one point about hackathon. I think we need to be more precise what kind of problems we want to resolve at the hackathon. I would see — I would love to see at the beginning that the hackathon work is actually showing where the problems are lying and then throughout the — the working group like how the documents are solving the problems or what kind of things are still open.

Dhruv Dhody: I completely agree and I think that would be perfect between chairs and ADs and the group to agree. I don’t — putting this in charter and discussing with the whole of the IESG doesn't really help. That’s when it’s AD’s job to pick chairs who can drive this work.

Thomas Graf: Got it. Thanks.

Dhruv Dhody: And even though we weren't going to really talk about milestones here, we — we tried to capture some of that Thomas in — in the first milestone. But I totally agree with Dhruv, that’s going to be defined by the working group as — as the work is proposed and adopted.

Alvaro Retana: Okay, you from before or —? Okay.

Fengchao Fu: Okay, I'm Fengchao Fu. I want to explain what is exactly dynamic L3VPN. For example, customers need a 100M bandwidth, but after one hour they need 10G bandwidth. On the other hand, the set of customer will also change frequently. And maybe today I want to establish with someone but tomorrow or next hour I want to establish with others. This is our understanding of dynamic L3VPN. Due to the time we can show the method of dynamic L3VPN in the next meeting or offline. Please contact — please contact with me. Thank you.

Dhruv Dhody: So these are the work items, the same thing that you saw in the previous presentation as well. These are the concrete things that we see already being discussed in the various — on onion list, there are drafts which are already there, there is discussion. If people have disagreement on these work items, it’s up for debate and please use the list. The final part which I wanted to show was relationship with all the other existing working groups, clearly making sure that there is clear scope, clear boundaries with each of them. We have tried to identify that so that each of the working groups that we have a relationship also understand that we are not just like doing all service and all network but there are clear boundaries between the work that we want to do it in ONSEN versus anything technology specific, anything which is touching YANG models itself or that is not the scope of Onsen in any way. So that is the part which we have tried to clarified with this section. And that’s it.

Alvaro Retana: Dhruv and Joe, Qin, go ahead.

Qin Wu: Yeah, you know for this — you have a last slide relationship with —

Dhruv Dhody: Yes, please, yeah here.

Qin Wu: You know I try to understand, you know, maintenance criteria. In the previous slide you maintained a list of model, I list the AC-TVM model developed by the TEAS. Now actually you think this should be separate. I — I try to understand whether the criteria is all the published RFC should be maintained by this Onsen instead of published in TEAS or published in Ops area. But ongoing work should still be developed in existing working group.

Dhruv Dhody: So our aim is, like for instance what we write with respect to TEAS and C-CAMP and Bess, that’s a good example to look at: ONSEN working group will take on future network and service data modeling effort while technology or protocol specific modeling remains in this space. So if it is generic, we want it to come to ONSEN, but if it is not, it is very specific, it remains in that working group. And I hope like with ADs and with working group chairs we could — we have done this in other groups, we coordinate in the IETF and we’ll try to do the right thing as much as possible. So that’s what we read. Earlier version of the draft actually had much more bigger text which said that oh ADs must have consensus or they must discuss. I think this current text kind of covers it, but if there are concerns, please reach out.

Qin Wu: So you think AC-TVM model is generic model or technology protocol specific model?

Dhruv Dhody: See AC-TVM is listed up as maintenance so it is definitely a generic model.

Qin Wu: Okay, I thought it's TE specific model.

Dhruv Dhody: According to me, things like TE topology, TE tunnels, those things we are not taking. Those are not service models.

Qin Wu: I just feel your, you know, charter text consistent issue.

Dhruv Dhody: Yeah, so please suggest how we can fix it. Thank you.

Alvaro Retana: Ketan, go ahead. You’re remote.

Ketan Talaulikar: Yeah, I echo what Dhruv just mentioned. This has been discussed between the ADs and especially as routing AD, this is what we came to a conclusion of. In the charter, explicitly all the models are listed to provide clarity to everyone here. And for existing adopted work, this is something it’s not going to be forced onto Onsen, Onsen working group if it gets formed. This is something that will be taken up as a collaboration work between the working groups. So this is just normal IETF collaboration I would say. But if there are something not clear, the BoF is a good time to bring them up.

Dhruv Dhody: Thanks Ketan. And I guess there’s going to be some discussion between Mahesh and like the other ADs, right, like to kind of do this in during the chartering process. So I think the right thing will happen there.

Alvaro Retana: Okay, looks like the queue is drained. So if anybody has any questions or any statements to make, now would be a good time before we go into the questions.

Mahesh Jethanandani: So while Alvaro is trying to formulate his set of questions, I thought I would just jump in and echo some of the comments that Thomas especially made, is this working group is going to be somewhat different, or at least I believe it should be different, from other working groups in that the focus should be on implementations. And those implementations identifying the gaps that the work group documents on. Normally working group publishes documents and then they look for implementations. I think this working group will succeed only if, not only, but really if implementations actually drive the work within the working group. Thanks.

Alvaro Retana: Okay, so as we mentioned at the beginning, there were some criteria that we mentioned that that we wanted to for you to think about as we were going through the presentations. So we're going to start by asking questions. There's going to be a poll on the MeetEcho, so please take a second for everyone to log into the MeetEcho. You will need that to cast your opinion. Um, we have a series of several questions, so, you know, we're going to basically cut and paste these questions into the poll. So the first question: is the problem statement clear, well-scoped, solvable and useful to solve? Okay, things are starting to slow down and we are seeing a clear pattern, so there's overwhelming number of people who kind of say this is like clear, well-scoped and solvable and useful to solve. But there's some noes, like and if you want to speak up on where this is lacking, that would be like very, very useful. So if anybody wants to either speak up or send some, if you are like shy to speak up now, please send stuff on the list at least to, or like you know, at least to these people who are holding the pen on that, so we can incorporate your comments because we really want to have included everybody in the development of this. So thank you. Kent.

Kent Watson: Yeah, thank you to Dhruv who tried to clarify my concern with if it was YANG data modeling language or API that was being presented. And he put up a screen of the slide said YANG API, which actually confuses me because YANG is not an API. YANG is a data modeling language from which APIs are generated. So I was a little bit confused as to what was meant with that. And hence why I was — maybe it’s not entirely clear to me what the charter is about.

Alvaro Retana: Okay. Dhruv, Joe, did you want to answer that? Yeah, go ahead.

Joe Clarke: Joe Clarke. I the — the charter’s evolved quite a bit. I think initially that point was called YANG to API, which was a mapping exercise to take YANG and develop an API-like Kent, you mentioned the Open API swagger spec. Um, it’s since evolved because we — we were worried that mapping might be too much of a of a big chunk to to bite off, but we were thinking of and I think it’s come up here a few times what are what would be in scope would be how do we make whatever comes out of these abstractions consumable by a wide variety of of different operators. Um, and it’s not just going to appeal to one or two sets of operators. Um, but we weren't saying that YANG is an API. We were saying how would we create something that could be, for example with TMF, that would be connected to APIs that these operators are using.

Alvaro Retana: Thanks Joe. So would you submit like you and Dhruv can you submit sometext change to kind of incorporate that? Thank you. Thanks. Adrian?

Adrian Farrel: Adrian Farrel. Listen, I accept I'm very far in the rough here, so um this is just to maybe help people. Uh, funnily I picked exactly the same sentence as Kent for not being clear, and this is the thing that says "it’s an interface between a service API and a layer." And this just doesn't mean anything to me. Uh, I can't extract anything from that.

Alvaro Retana: Dhruv?

Dhruv Dhody: Um, I think the intent there was to really define the interface... um, okay. Let me start with the problem statement was um we have um external bodies like TMF defining their APIs, and then we have our IETF YANG models. And the what we seem to have identified or at least the proponents seem to have identified is that there's this gap between those APIs and whatever we are defining in IETF. So it was really to I think the charter was trying to say is that one of the items should be to define that interface, whether that comes in the form of an actual API or it comes in the form of another service level model um that it could be any one of those items. So I don't know if that helps clarify.

Alvaro Retana: So it seems clear to me or clear to us that we need to clarify some clarifications in the charter. Okay. So we're going to move on with the questions. Um, next question is: who is willing to author, contribute, edit documents?

Chongfeng Xie: Hello everyone, this is Sun Chong from China Telecom. And um I present — I presented some of China Telecom’s challenges uh yesterday in OPS area, and I’m now in charge of our network operating system R&D center, and we are — we are developing, implementing our network management system and OSS uh by our own. And um I — I am also responsible for over 500 developers. So uh we already have dep — adopted YANG models in our controllers and uh from network aspect and also we adopt TMF-based APIs uh from up layer. And we are really facing the challenges that we discussed here in ONSEN and uh um we — we really hope uh our model will be uh like Mahesh just said, dynamic, flexible and so I would be very happy that the challenges will be uh solved in ONSEN. And uh I am also willing to contribute more resources, uh including our developers and the documents uh in — in the future in this ONSEN working group. Thank you.

Alvaro Retana: Thank you. And and I think in this question, right, we're trying to see if there's like a community willing to contribute, and the numbers show that. So we're not going to dwell on the "no"s, like because there's obviously people who will not contribute. That's fine. Um, um, for the people in the queue, uh is this like you're coming to say your statement of support to do work here? Okay, so make it brief and we can move on after that. Yeah, thank you. Jing?

Jing Zhao: Okay, I'm Jing Zhao from China Unicom. And uh I fully support this working group, and I think the work is highly relative and meaningful, and uh we will actually participate and contribute to the working group. Thank you.

Alvaro Retana: Thank you. Thanks. Ian?

Ian Farrer: Ian Farrer, Deutsche Telekom. Um, yeah, a lot of the problems there are ones that we've firsthand experienced and we're willing to work on this, both in terms of drafts and uh you know documents around there. We've also got a large open source implementation of this stuff that we're contributing or want to develop through here as well.

Alvaro Retana: Thank you. Chongfeng? Yeah, Tongfeng, yeah.

Chongfeng Xie: Oh, we — we are willing to invest human resource on this work and provide our contribution, give support to it.

Alvaro Retana: Thank you. Luis?

Luis Contreras: Also a statement of support from Telefonica side, so we expect to contribute as well and work on this working group. Yeah.

Alvaro Retana: So I think this is like more critical: a lot of people are willing to do the work, but we do need a lot of people to review. Um, hopefully at least the same number or probably more, because if everybody is just like writing, looking at their own documents, it doesn't help. So um please volunteer to review stuff. So thank you.

Do we need a new working group to solve these problems?

Okay, so it looks like the numbers are converging. So for the people who said "no," do you think there's another working group in the IETF who should do this, or do you think the IETF should not do that? So either way, if you want to come speak up, that's fine, or if you want to go talk to the AD uh in private, that's fine as well, but I think that's like very, very useful input if you think there's another venue for this, right? Because like um the basic assumption in doing this is there's no single venue for this, or like even multiple venues that cover it. So if you do have different opinions, please share them. Um, now would be good. Um, in after is also good. Thank you. Give it a second for people to come up. Okay, thank you. Mahesh? Like um I think we can dig on this a little bit, but nobody um said where — why. But so just something to pull on.

Okay, so the next question is: is there support to form a working group with the proposed charter? And you'll notice a little asterisk there that at the bottom says: assuming that any proposed change changes or revisions to the charter are discussed and made. So as uh Joe and Dhruv said during the charter discussion, there's a GitHub, you can go make uh PRs or or issues there, can be discussed on the list as well. So in general, is there support for a working group based on the proposed charter?

And and we do note for the minutes that like Wim, um Kent and Adrian did propose charter-related stuff, and that's that's something we'll pull on. Yeah, sounds good. Thank you. And Joe is saying he did put a PR in, so if you can look at it, that'll be perfect. But uh we'll kind of uh be pretty lax on like accepting this thing until like Mahesh is ready to put it on a telechat. So...

Oh, there's a magic zero number in there. That's pretty nice. I didn't jinx it yet. Oh, yeah. Okay, yeah. So... let the minute show that it was a prank.

Okay, and the last question, which is not really a poll: um is there anyone who feels a working group should not be formed? Please speak up now.

Great. Thank you. We um now it's time for conclusions. Um, obviously you saw the polls. Um, I believe we're safe to say that there's uh strong overwhelming support. Um, however, as we said at the beginning, you know, this is not the place where we're going to decide if the working group is going to be formed. Uh this is the work for Mahesh. Mahesh, if you want to come up and say something. Um, otherwise, thank you so much for being here.

Mahesh Jethanandani: And thank you very much for everybody who expressed your opinions. It was like really professional and well done. So thank you very much for like being like really, really nice audience here. Thanks.

Alvaro Retana: Thanks everyone for coming. You get five minutes back to do whatever else you want to do.

Mahesh Jethanandani: Okay. Can we get the proponents, Joe and Dhruv? Just wanted to quickly confirm. (Foreign language conversation) 没有人反对. (No one opposed.) 刚才那一堆. (That whole pile earlier.) 根本就是一边倒的. (It was simply one-sided.) 可能有人质疑, 有一点点不同意见. (Maybe someone questioned it, had a tiny bit of a different opinion.) 您好您好. (Hello, hello.)

Alvaro Retana: It's near the front mike, the mikes are hot, so whatever you say is public. So. (Foreign language conversation) 多谢多谢. (Thanks a lot.) 没关系没关系. (No problem, no problem.) 对对对, 已经搞定了. (Yes, yes, yes, it's already settled.) 就这一个. (Just this one.) 给 AD, IESG 寄上去. (Send it up to AD, IESG.) 没有人反对, 没有人反对这个. (No one opposed, no one opposed this.) 那太棒了. (That's great.)