 you need a demon. So that decision was easy and it's done. Netconf is a demon. Netconf does stateless network configuration. This also means that Netconf doesn't actually know about what it did or what it's going to do. It does not keep any form of state. If Netconf crashes, you can restart it and it'll just pick up exactly where it was because it doesn't care. Whenever Netconf needs to make a decision about what needs to be changed in the environment, it looks at the environment to figure out what needs to be changed. It took us quite a long time, I think, to truly arrive at this point in our design document simply because it's hard and because it's too easy to pretend that you're being stateless when in reality you are not. However, I guess not in the least because of my previous involvement with artificial intelligence and robotics, where a famous motto is that the world is its own best model, that any attempt to maintain a model of the world in which you're interacting or of, well, the kernel, the network configuration, the system that we are configuring, will sooner or later get out of state. So you will be faced with a lack of synchronicity between what your demon or what your robot thinks it is doing and about the environment in which it is doing something and what is actually going on. So it took us a long time to arrive at this point, but Netconf will be completely stateless. Sometimes it is impossible to be stateless because sometimes you may have to start DH Client, for instance, and DH Client is a long running process. So because that process is running, it's stateful. The way we deal with this is that we say we do not keep state, but if state is being kept for us or if state is inherently kept by whatever we are doing, we will not rely on it. So if DH Client dies, we can still continue doing what we're doing because we will just start it again. Netconf is policy-driven. What we mean with that is that whenever Netconf makes a decision or has to make a decision, we prefer to defer to you because we do not know how you want to configure your network. So whether you would prefer that if DHCP fails to obtain a lease, you do a link local configuration or you turn your wireless interface of your laptop down so that it can go into power safe mode, we don't know. And we are not going to try to be very smart about it and figure it out. As a matter of fact, I don't have it in my notes and maybe I'm going to regret this, but I'll say Netconf is not smart. As a matter of fact, it's not trying to be at all. Netconf is also threadless. There's two reasons for that. The first is that threads are very hard to write and implement without using any form of polling. As soon as you use any form of polling, your processor wakes up a couple of times per second. If your processor wakes up a couple of times per second, then your battery goes depleted. So since we want Netconf to be runnable on servers and workstations and laptops alike, we had to go with a solution that didn't involve any form of polling. The other thing about threadless design is that it actually makes your program deterministic again. I was at LCA in January and we had lightning talks and Rusty Russell, whom you all know or should know. He's the implementer of IP tables. Let me say anything wrong. Maybe it's IP chains. I don't actually know. But Netfilter, I am. He delivered a lovely, one of the best lightning talks that I've ever seen and it went something along those lines that it took us 30 years to go from operating systems that would crash if you tried to do something in parallel to something that can actually run your second process in a protected environment and would do everything correct. And now we're adding threads on top of that and then trying to synchronize between them again. I can't get his message across as good as he did, but anyone of you who has ever written anything threaded and had to debug that will probably agree that it is a nightmare. And anything that is non-threaded is much easier to debug and also to follow what it's doing. And I guess that's one of the design principles of Netconf. I want it to be transparent. I want it to fit in with the Debian system that we know where nothing happens that we don't want or that we haven't implemented. Netconf is written in Python. I've gotten so much, can I say shit? I've gotten so much shit in the last two weeks about it being Python. Apparently there are people that have very, very strong opinions about the lack of braces and indentation. Well, you know, I agree with you. I've spent one and a half days at Debian Camp last week figuring out a bug that was introduced because I forgot or I somehow erroneously deleted an indent. One single line, indent deleted. Tough luck. I didn't find it. I can't necessarily say that I was being very strict about the way I used version control at that point in time, so it wasn't very easy to bisect, but you know how it goes. However, Python is, I maintain a really, really good language for prototyping because it is a very straightforward language that allows everybody to look at the code and understand what's going on and also allows you to shift things around very quickly. So I chose it as a language for prototyping Netconf, but you can rest assured that Netconf will not remain in Python. If we would ever rely on Netconf in Debian, then it will be rewritten, most likely in C++. Just laughing. Cheers, Bienel. Well, you know, as I will say later on, you can join the project. You can take an influence. You can make or be part of these decisions. Let me move on. The current roadmap that we have says Netconf 1.0 is our goal, and the goal is to be IF up, down, compatible. Now, a lot of you are, I think, and it makes me very happy that you are looking forward to Netconf, or at least, shall I say, the promises that I've made so far for Netconf. I'll allow you to make up your mind again when we deliver. However, do not make up your mind about the entire idea when we deliver 1.0, because Netconf 1.0 will not be any better than IF up, down. I am sorry. We tried. We really did. But even the challenge of implementing something like IF up, down with an event-based system that is actually running as a demon and uses sub-processes versus shell in very many places was challenging. And for some reason, we forgot to read every morning that page that told you that you are not going to need it, keep things as simple as possible. Well, maybe my student did. I certainly didn't read that page when I was about implementing that ETC network interfaces handler and IF up, down compatibility layer, because probably like most of you in this room, I am fed up with IF up, down in very many ways. So I wanted to solve all of these things, and I won't, because IF up, down by design is not capable of doing what we wanted to do. Other projects, one of them Network Manager or Network Mangler, as it's affectionately being called by the Fedora developers, they also run as a demon. They are not fire and forget. They run as a demon, and they do not specifically, they do not implement IF up, down. If you add your interface to ETC network interfaces, Debian patch network managers will simply disable that interface and not ever worry about it again. It was a smart decision, part of the Network Manager, guys. Maybe we should have taken that decision as well. Maybe we should have set the same thing. Ignore IF up, down. Ignore ETC network interfaces forever. But something deep down inside made me feel that we needed that in order to gain acceptance, in order to make it possible to transition from IF up, down to NetConf. So this is what NetConf is, or should be, and I'm going to tell you how NetConf does what it does. So that's how it works. Any questions? Oh, I like gray tones, colors, and I'm colorblind. That's possibly it. Well, those of you who have seen my previous talks on NetConf may notice that this has been extended here and there. I find it increasingly harder to look at this picture and say NetConf is simple bottom-up design. I will continue to maintain that NetConf is simple bottom-up design. It is, however, only as simple as the task can be, or I'll turn the words in that sentence around until it makes sense. Let me run through this briefly. And as a matter of fact, I'm allowed. Let me just check back for a second. Yeah, I'm supposed to email something. So I'm trying to get a bath scheduled for tomorrow, around 1600. I'll send an email to the mailing list to explain this in greater detail because it's not quite as simple as it looks. So the core of NetConf is the core. That's what we could call it main loop. We'll call it main loop for now on. Main loop is actually just a forever loop that is centered around a blocking select call. If you've used select before, you know select does stuff with file descriptors. So as a matter of fact, a lot of NetConf is based on file descriptors. Because Python doesn't implement pselect, which is select that can actually handle signals, even signals are being handled via file descriptors. And so are timed callbacks and all these other kinds of things that we actually need to implement because I decided to make NetConf threadless. Most of this would not be necessary if you would use a multi-threaded approach. And I'm sure a lot of you would be willing to argue that threadedness is a feature that I should add back. I won't. The core is essentially collection of reactors. A reactor is something that gets called when an event appears on a file descriptor. So when the select loop comes back, it'll give you a list of file descriptors that have values to read. And then you fire up the reactors once after the other and ask them to shave off the data of that pipe and do whatever they want with it. So one of the easiest reactors that we have is the control socket reactor. NetConf aspires to let you configure your network interface even if you're not root. If you're a normal user, you should be able to say if up eth0 and if the system administrator permits that sort of change, then that should happen. There are two ways to implement that. One of them is set UID. I don't like set UID. The other one is going by a control socket and that's the approach I took. And as a matter of fact, the control socket is destined to be the main interface for any form of communication with NetConf. This is also where later on I hope to add debus adapters so that more advanced tools can interface with this core. So the control socket is always available and it registers itself with the core and it listens. And when it gets an event on the file descriptor that it's associated with, then it calls the reactor and issues an event. Such an event might be if up eth0. When we get if up eth0, we pass that through an authorizer. So this is a command event and only command events get passed through an authorizer. This authorizer basically determines our people or it actually asks control socket whether this request is currently authorized because well, that's a design decision. But can the user who just connected to the control socket issue this command for this interface? If no, bugger off. And if yes, it passes it onto the interface policy. The interface policy is sort of the higher level core. It tries to delegate the decisions away from NetConf. It tries to give you an interface where you can plug in your own decision making skills or preferences. So let's assume for a very, very simple case that because you're still using ETC network interfaces and you haven't had time to modify them, that you configured or told your policy that you would like to have ETC network interfaces tried or ENI as we call it in NetConf tried first. But for a little bit of added benefit or spice, let's say that if ENI handler doesn't have a stanza for the interface that you're trying to configure, then it should fall back to DHCP. So what's actually happening here between the policy and the interface policy and the configuration back end is that the policy first asks the configuration back end something along the lines of is an IFUP command for ETH0 coming from the control socket? What should I do? We've already at the allowed part, sorry. So what should I do if I get IFUP ETH0 from the control socket? Well, and the policy says you should try ENI. So then the interface policy delegates over to the ENI handler. It instantiates the ENI handler, asks it to do whatever it can and waits for a result and then discards it. So there's no handler caching. That's a major change over the last time I had this presentation because after all, NetConf is stateless. In our example now, ENI handler fails to find an IFACE definition for ETH0 and raises an event. This is now a result event and those don't go through the authorizers. Raises an event that basically says, look, I couldn't do it, sorry. Upon reception of an event from ENI handler that basically encompasses a failed result, the interface policy consults the configuration back end and tries to figure out what should I do? I have this IFUP command for ETH0. It comes from the control socket and ENI tried but failed. This is answered by the configuration back end as with DHCP. Look, now go ahead and do DHCP. So now the interface policy instantiates a DHCP handler, which then spawns a DH client sub-process, hooks up file descriptors to the control socket so that you actually see what your DH client is outputting. I think a lot of us like to see that and be able to react without having to go through the syslog. So that's why we had to jump through this FD proxy loop. And we do have to have this FD proxy stuff in there simply because if you ever want to reconnect to a running process, you won't be able to otherwise. You actually need to step in between because Unix will keep file descriptors open until the very last writer or consumer of these file descriptors have closed them. So potentially if you want to reconnect at a later point in time and look at the current output of DH client, why it's currently failing, we actually have to go via a proxy here. This is really ugly. Can't figure out a better way though. Upon spawning DH client, the DHCP handler also registers a special reactor for DHCP events with the core and whenever DH client now issues an event, what they call reasons, whenever DH client wakes up the DH client script for a specific reason, we get data on the file descriptor and the reactor called and that reactor now can take appropriate action. Let's assume we got a bound event back, which means that the DHCP server gave us a lease and gave us all these other data along with it. Well in case of a bound event, the reactor then passes all the data to a manipulator and the manipulator is the one that touches the interface. It doesn't actually do that directly. The manipulator now delegates to scripts on your file system, which I didn't include in the picture here. The reason for this is simply that it should be easy for any distribution and any operating system to make changes on how the interface is actually being manipulated so that the interface that we have here for the manipulator is sort of a higher level one and the actual steps are left for the implementers. So that's the picture. That's what's happening when you tell NetConf to do something. Are there any questions about this at this point? Jimmy, you might want to have a microphone? Is there a microphone? Okay. You said that the two ways to do the, to provide non-root users access to this were via a set UID and a control socket and you also vaguely mentioned debuts. What about something like policy kit, which is on my to-do list to learn about and it seems to be the way most people or not most people, but people seem to be moving toward using the bus and policy kit to allow a sort of unified way of setting policies for that sort of thing. So I understand your question to be why isn't NetConf just using debuts? I'm just wondering about the bus and policy kit as a way to manage, I guess, a combination of giving non-root users access and the authorizer functionality. I agree you need some sort of more general thing to receive input from DH clients and everywhere else. Yeah. I thought a lot about this and I really felt very, very stupid after a while looking at my crap control protocol that I had worked out by that point in time with zero experience for protocol design and something like XMLRPC. That was around the time when I was writing plugins for Joey Hess's icky wicky and you know, like hands up, who likes XML? All right. Let's make it a little more specific. Who likes XML for very structured data storage and passing it around? Who has not heard of XML? I'll explain it to you later. Honestly, you know, everyone hates it, but when I was writing Python plugins for icky wicky, which was implemented in Perl and I could do pretty much everything that I needed to do and I didn't have to touch Perl anymore. As geeks, we have opinions, right? I was very happy and I was looking at it and it was like it actually does everything that I need and more. And then I'm like XMLRPC debus. Wow. It does even more. It does routing. I can do authorization. I can do all this kind of stuff. And then I was thinking, am I going to get a package into the Debian based system, which is my goal that has a lip debus one dependency. And when I heard the other day, the lovely description of what is going on with debus right now, which is quote, unquote, collectively un-maintained, I decided that I was actually doing the right thing. So it is very, very true that a lot of what is happening on the control socket is basically NIH not invented here. It's basically reimplemented. It's reinventing the wheel and it's painful and I'm sure there's going to be bugs and all that kind of stuff. I just didn't see another alternative. So that's hopefully answering your question. Are there any others? Yes. You said something about the FD proxy there. Maybe dash proc dash what the PID dash FDs could help there. I don't know. Yeah. Linux makes things easy in very many ways. Other, basically the comment I believe was that you can easily reattach to file descriptors because Linux has the proc file system which exports the file descriptors and actually allows you to reattach to them. On the one hand, I felt that was incredibly cheap and hacky. On the other hand, it's not supported across other operating systems and I do want to make NetCon target other operating systems as well. Now, FD proxy is a gross hack. If you look at the code after this presentation, skip FD proxy. Mainly because I haven't figured out exactly how to do it yet and mainly because I haven't figured out exactly how it fits in. So this is definitely work in progress. But well, I'm looking forward to your suggestions. What do you think about Twisted? Again, Twisted does a lot of the stuff that NetCon does. As a matter of fact, I got the term reactor from Twisted looking at their code and wondering how the heck they can do something without threads and I can't. Again, it's a huge dependency. And I don't actually know whether it is available for anything other than Python. So am I going to be able- There are reactors in other languages. Yes. Yes. I'm well aware that a lot of this could be factored out and I was looking at Twisted, I didn't want to settle on it at this point. It is, I think, possible to do it again. As a matter of fact, if this is going to be re-implemented in another language, it's basically going to be a rewrite anyway. Right now, I'm in the prototyping stage and figuring out an API for Twisted and trying to use it and molding your entire program around it very much limits you in terms of the prototyping that you can do. You have different opinions on this. I'm quite possibly wrong, I agree, but that's what I've decided so far and I'm happy to talk about this more if you are interested. Are there any other questions? All right, in that case, where is the code? If you go to netconf.aliath.debian.org, the question was where the code is. netconf.aliath.debian.org is the home page and it has links to the code, the Git repository where the code is maintained. All right, so it's one of those questions that I've heard a lot in the last two weeks at this conference. Where is it? Can we test it? Is it ready? Well, if you look around at this conference and you ask some of the people here, you go by word of mouth, then it's paperware. As a matter of fact, it's Duke Nukem forever. You keep talking about it. Could even be the new herd. But let me tell you this, will it be out before DeppConf in Thailand? I promise. Will it be in Lenny? Is it in the archive yet? We really, really wanted to upload netconf.0 during this presentation. We didn't. It's a good question. So netconf is a project that's part of the Google Summer of Code. And I was lucky enough to get a student, Jonathan. That's Jonathan. During, I think. I don't know. He looks confused. Anyway, Jonathan is watching, so cheers. But, you know, thank you very much for that wee question. I could go away a little bit. It was kind of uncomfortable there. Why aren't we done? Yeah. So netconf does network configuration management, right? It's a demon and it's stateless. It tries to do a lot, and there are very many, very tough design decisions to be made. And as a matter of fact, I will take full credit that I've made a couple of really bad ones in the past. And possibly in the future, sure. Nevertheless, in the last year, and netconf is actually just a little older than a year now because I started coding it at Deppconf 7, we went through two almost full rewrites of the code. And you know, the result of all of this is that it actually does work. The question was not whether it doesn't work or whether it does work. The question was, will it be in Lenny? Is it in the archive yet? No, it is not. We haven't created the package. There are still a lot of blue points that are missing, but it works. Let me show you. So I'm going to start the demon in debug and foreground mode. And you can see here that what it does with all the FD reactors. So even just after starting it, it already has 11 file descriptors open. Yeah. You know, I don't expect there to be 255 file descriptors. If you want to be doing your open VPN over DNS IP tunneled by a WPA supplicant managed interface that actually does bonding and so on and so forth. Yeah. If you want to do all of that, pray that it doesn't exceed the 256 that you get. I don't actually know how many there are. Well, so for instance, you can ask it to configure the interface. There's no command line client yet, but there's a control socket. As you can see, the control socket pretty much gives you all the information that you expect. Does it have help? No, you can type it in. No, it doesn't. It doesn't have help. It's not. There's one other reason why I didn't want to have XML RPC on the control socket. Because I can, as the assistant administrator, actually directly connect to it, and I can use shell scripts and something like SOCAT to do wicked stuff on it. If I had to do XML for every single time that I wanted to do something like that, I'd probably go insane if I'm not already. I'm sorry if I have to refine my question again, but I mean, you just did what I could do by just typing it DH client interface name on the command line. So what the censored word here, does it actually do that's really cool that I don't have right now, and why do I really want NetConf? Why me as a user or kernel hacker or whatever, why do I want NetHack? Did you see this slide? It's more capable. It can react to DHCP events that happen after you've typed IF up and gotten back control to the shell. It can do the proper thing when your pre-up hook fails or your post-up hook fails or your pre-down and post-down hook fails. It provides, as you called it, a service-based architecture, which, sorry, my lingo is a little off. It is designed with other tools that plug in in mind, and with that I mean stuff like IP over DNS and open VPN, and I do not mean hooks that integrate very brittily and that require you to, if you actually need to restart everything from scratch, that you have to go through the process table and kill open VPN hooks that didn't get picked up because your pre-down hooks failed, so the post-downs didn't actually run. It is stateless so that you can actually give... If I can add another thing, this is a prototype implementation coded by one, maybe two people for less than a year, and it can already do what you have now, which have been coded by multiple people, not in a prototype stage for multiple years. I think this is like asking Alexander Graham Bell, I mean what use is this thing that can ring a bell in my bedroom from across the world. I think that this is kind of early to ask what NetCon can do at this stage of its life. Thanks Manosh, and you know you have the freedom not to use it. So I move on. It does a little bit, you know, it does work. I can even take the interface down. There you go. All right, so there was an extra zero at the top of the... Yeah well, it does work. The reason why there isn't a package yet in the archive is very, very simple. We really do not like quick and dirty, and it was very simple at times to fall back into that track and implement things in a quick and dirty way, and then we would really regret it later. So now we're at this point where it's very, very close, but there are still some decisions that have to be made. So we would like to make these decisions properly, and let me tell you something. Being at Depcamp and Depconf is not the place where you can actually make these decisions by thinking about it a lot. There are a lot of distractions. It's one of the lessons I learned. There will be more lessons later on. We just don't compromise, and I guess that is another thing I can say about Netconf. I'm unwilling to accept any form of hack into the code base. So if your wifi driver does not go into power down mode, then you should change your driver. Yeah, not go down to power down mode if you take the link status down. Then you should change your driver. Then don't expect me to do something in Netconf in the case where this specific driver is loaded. Could you please get the microphone? Why? So honestly, as a kernel hacker, we have to work around all this shit from hardware all the time, and there's no way all the layers below you are going to fix because you don't like hacks, so better find a clean architecture where you can put the hacks without compromising the main system because you will need these bloody hacks. I think maybe this is just a point where you and I disagree. I really don't like to have hacks in Netconf. I think as soon as you start doing that, you will very, very soon end up with an unmaintainable code base. You will end up with what the Linux kernel is having right now, drivers for... Let me finish the sentence. You will have drivers in the kernel for devices that are not very much used and that are actually getting in the way of any form of transitions that are required when you change APIs in the Linux kernel. What's your name? In that case, maybe you want to go or not. So here are the lessons learned. Lesson number zero, other people know better. Lesson number one, stateless is hard, but it's worth it. There used to be efforts by Red Hat earlier about five or six years ago that tried to do network configuration in a stateless manner and they gave up. It's still being worked on, but nothing has ever come of it because it is hard. But having looked at it, I don't think it's impossible. It does require us to have some form of standards though, something that we can rely on, some interface that we can rely on, and I guess that fits in well with the earlier comment. If we actually now have exceptions for every single driver that needs it, it's going to be incredibly hard to get somewhere. Now, there's always a question of what are we trying to do? Are we trying to create a system that replaces IF up down and in 10 years becomes the nightmare of every other system administrator because it didn't scale, because it did exactly the same decisions or made the same decisions or went the same paths that IF up down did? Or are we possibly going to create something that will never work but might be an incentive to create such interfaces? Now, I prefer to go the second way. I prefer to create something that is actually leading the path forward and not trying to make things happen now. So it might take a while. This is another lesson. Unfortunately, there is no alternative to DH client, but we all use it, but it really, really sucks. Sorry. If you go threadless, then callbacks make things very, very complicated. At some point in time, three, four weeks ago, we had three levels of callbacks flying one over the other. That was one of the times when we decided that we had to go another way. Test-driven development isn't that easy at all. I have to admit that I was being awfully naive about this. I read the book for test-driven development. I came back and thought that I could go and write code that was test-driven, developed in a test-driven manner. But it's not easy, especially not if you are coming at it from the perspective of what I used to love when I was coding multidimensional diffusion models in artificial neural networks in C++, which I would do with a policy-based approach. If you do a policy-based approach, you can't test anymore. If you want to write test-driven development, if you want to write, sorry, if you want to do test-driven, then there are very many important lessons to be learned. As a matter of fact, there's a blog at Google that's called Test-Driven Something. I'm happy to put out the URL on the list afterwards that taught me a lot of stuff. It made me realize that I'm not the best object-oriented designer. As a matter of fact, I'm possibly not a programmer, but I'm someone who really doesn't like the way that network configuration is happening, and so I would like to address that. This being a Google Summer of Code project, it wasn't always very easy. I am supposedly the mentor, and my student is the student who works on the project, but I found it incredibly hard to define the role. What am I supposed to be doing? Am I supposed to be mentoring, and what does it entail? How do I do it? Without steering too much, because that's in the end what I did. I made, as I said earlier on, a couple of bad decisions, and I steered my student right into them. There's stuff to be learned from that, and I don't consider it a failure. However, it's definitely something that needs to be thought about before, and I didn't. I threw on a little bit of lessons learned here, and I know that some people want NetConf. I'm one of them, and I guess all I can ask you is, if you're interested, then join and help. If you don't like Python, there are other ways in which you can help this. With that in mind, I would like to close. Are there any questions? Could you show us the policy that you have on your box right now? It's hard-coded at the moment. It doesn't have any policy configuration broker or any manager, so it's really in the Python code. I can definitely show it to you, but it's not going to be very exciting. The reason for this is quite simply that up to this point, I haven't been able to define exactly what is needed from the policy. We are at the point where the idea of asking it what to do on arrival of a command for interface, given a previous attempt that resulted in this. These four points is enough, and so we coded that up in here. As you can see here, the control flow basically says, I can't figure out right now where the source comes in, but it does. If we get an IFUP command, and nothing has happened previously, or ENI handler cannot handle result, then try DHCP handler. This is hard-coded right now, and it probably will be in Netconf 1.0, which is IFUP down compatible, simply because this is what IFUP down does. We don't need anything more, and I prefer to wait with the design of policy and also the design of the configuration file format, until we know what is actually expected of it. But as you can see, there are comments in there that say, do we need this duplication, and so on and so forth. This is all work in flux. Be there. So I think from your last few comments, I'm starting to get a sense of what you think a 1.0 might be like, but there have been a couple of comments on the IRC channel and in my own thinking, my own head about trying to understand what's sort of the bigger plan here. How big a slice of the stuff that, for example, might be running on my notebook or somebody else's in the room, would we eventually expect Netconf to supplant? And from sort of an evolutionary standpoint, once you think you're to a 1.0 uploadable kind of stage, what steps would you expect it to go through when does it get smarter about what, how much have you thought about that? Well, as soon as we have IF up-down compatibility done to the point where the rough edges are smoothened out and you can actually use it, we can use the fact that we didn't just implement IF up-down in Python, but actually thought about it a lot and tried to come up with an architecture that would be able to handle asynchronous events that you might have in a stateless way. So as soon as IF up-down is superseded, I'll say by Netconf, then we can use that infrastructure that is in place to put in other components. And I specifically think about stuff that is currently using IF up-down hooks in Debian and uses rather brittle approaches, but at the same time, I don't want to create something that is complex like Network Manager, something which is more or less a black box and you don't understand what's going on anymore inside. What I would like is a system that exposes to you exactly what it does and an interface for packages to install additional functionality that you can integrate and use directly from the policy. I hope that answers your question. There are certain layers on this, OpenVPN, IP over DNS, any form of IPsec and so on and so forth. That's one of the things that I always lacked about IF up-down is that it wasn't really extensible, that as soon as you wanted to do something more complicated, you had to use hooks and I also didn't find it possible to make modifications to IF up-down to add that functionality. That is basically the source of why I started to write it. Yeah, I think that all makes sense. I have this latent fear that you're in one of those sort of modes where until a whole lot more stuff is working beyond what you have in mind for 1.0, that it's going to be of limited utility for, you know, then unless we end up just sort of giving it hooks or wrapping it or doing whatever, that until it gets some number of steps beyond what you're thinking of as 1.0, it's frankly just won't be terribly exciting to someone like me. I know and I argue the reason why it's the two of us in the team. So far, people have not been interested. It is not yet usable on your system. People have not looked at the code, maybe some of you have, but I think the general majority haven't and quite possibly I haven't been managing to get the point across. All of these things, you know, like I always say that this is the hobby of mine and I'd like to move it forward. So far, I've invested eight weeks in NetConf in total over the last year and I've learned a lot and if that's what's NetConf going to be in the end, you know, at least I profited of it, but I think that there's potential and I'm not ready to let go of that. So I'll just keep dragging on. Any other question? Zach, are you first? Okay. First, I would like to make just an observation. I like what I see so far. Okay. I just would like to point out that you should be careful not to go so far as to become a simpler network manager. That's something you have already said you are aware of, but I would like to reiterate that. And in the end, if I can see that your design would let me have something that is a normal user behavior. When I am using DHCP and WPA supplicant and I go from one network to another, I want the firewall to reset. I want it to detect that it has been moved to another network and configure everything. Your design lets me do that. Well, of course, the more complicated design will do too, but yes, up down really has you jumping over many complicated hooks to do that and it breaks all the time. So just for the fact that you are forcing us in a way to relook at things and her think yes, up down, maybe we are going to move to NetConf, maybe not. That's a win already. That's what I think. Zach, I think that's the last question that we are probably about out of time. Okay, Steve. A question about the policy. So it seems to me that you are thinking of having a control socket which is, I guess, writable by anybody, but the access control is done after that, right? The access control, yes. Okay, so this is somehow more complicated than just stating that only a given group can write to the control socket. So I'm wondering if you have some use case in mind in which having a more final control of what the user, a typical UNIX group would have allowed to is interesting. No. Manos believes that any such approach would belong into SE Linux. I guess I went the way for access control doing it on the control socket on the one hand because it seems easy. I get the UID, I get the GID, I have to do the matching. It doesn't seem to require rocket science. On the other hand, UNIX file permissions are not capable of expressing anything more complicated than what we have. So I'm not sold on that idea. I'm not saying that's how it has to be, but that's sort of how I envisioned it, and that's what's currently implemented. So Steve, last question. Okay, so it sounds like you and Jonathan have had a reasonably successful project so far. Yes. If 1.0 is just about ready to go, we've put it well done. Have you managed to convince Jonathan to carry on as your minion even after the summer code? Jonathan, can you answer that? I think I can't check the IRC channel right now, but I think that's a yes. I've enjoyed working with him a lot in the last couple of weeks. I think he's enjoyed it and he stated yesterday that he definitely is looking forward to continue to work on this. Quite possibly it's going to be less time that it's going to be involved. But I think Jonathan looked at the code and possibly I was able to share my vision with him that NetConf can go somewhere. I hope I'm not letting him down. Cool. All right, thank you very much, guys.