# Name Jonathan Roes # Email: where can we contact you? j roes at jroes dot net # Background: something about yourself: technical skills, experience, etc. Who are you? What makes you the best person to work on this project? I've been a Linux system administrator for myself, friends, and professionally for 6 years. I compete in computer security competitions with my school regularly. I've been programming for about 11 years; I've written a game for the Nintendo DS using C and an open source library called libnds, lots of proprietary code for my employer in database-backed web services and applications, custom automated monitoring tools, and a general-purpose template engine (like Cheetah). I experiment with new programming languages when I hear about their merit, but I try to only use the right tool/language for the job when it comes to programming. I've gone through all of Martin's presentations related to netconf, and all the documentation he has in the git repository. In the short time I've spent getting acquainted with the codebase I've already submitted a tiny patch. My experience specifically related to Martin's required skills listed on the wiki: 1. Python programming -- I've spent 4 years working with Python. I have a solid grounding in OO principles and design patterns and many of the standard Python modules. I've written POC exploits and short security helper scripts, XMLRPC web services code, web applications, and many one-off scripts to scrape web pages. 2. Experience with Unix concepts, such as (sub)processes, file descriptors, pipes, signals -- Throughout the course of my Linux sysadmin experience I've gained a strong grasp of these topics. Additionally, I've written many interesting one-off scripts and one liners to handle specific situations. 3. Grasp of computer networking concepts -- Once again, as a sysadmin and even as simply a normal Linux user with a wireless card, I understand these things well. The topics I was not as familiar with in Martin's design documents I have since brushed up on and will be even more intimate with when I start diving in. 4. Ability to work test-driven -- I am a fan of automated unit testing. The tiny patch I wrote actually fixed the some of the tests in netconf. 5. Ability to work with version control -- I've used Subversion, CVS, and other centralized VCSes in the past, and have recently begun experimenting with and evangelizing distributed revision control a la git and bzr. # Project Title netconf # Synopsis: a short description. "netconf is a network configuration management system designed with modern network infrastructures and the needs of roaming users in mind. It is currently implemented in Python for easy prototyping, but will eventually be ported to C++. It is an event-driven, threadless framework." -- Martin "madduck" Krafft, SummerOfCode2008/netconf # Benefits to Debian Netconf's development will be focused mainly on Debian in the beginning stages. An initial sprint of work has been done to replace the current ifupdown structure in place on Debian. Replacing ifupdown with a more flexible and robust framework will improve the functionality of Debian for those with advanced network needs, which is quickly becoming every user. Additionally, it will provide a rich interface for applications currently living on Debian to take advantage of. Future applications may be written to interface with netconf to provide functionality that would ordinarily be difficult to accomplish with the existing set of tools. Furthermore, netconf intends to be flexible enough to be a useful tool on non-Debian distributions. Spreading out a well-designed network configuration tool with known roots in Debian will bring about increased popularity for the Debian project. # Deliverables: quantifiable results e.g. 'Port Debian to VAX', 'Write 3 articles for X website'. * Bring netconf to 1.0 - There are several required items to bring netconf to a 1.0 status, each is enumerated in a later section. There are also several additional items that I hope to implement if time allows. # Project Details: a more detailed description. The general idea behind netconf is to bring about a more robust network configuration system than that used by most of today's Linux distributions. A very nice description is available at the main netconf project site at [1]. Bringing netconf to 1.0 will mainly serve to lay the groundwork for the more ambitious and advanced goals of the project such as firewall integration, VPN, advanced traffic routing and traffic control, bridging, bonding, and UI interaction. The scope of 1.0 is small enough to actually be completed, and implements a very basic feature set that intends to be solid and stable. The intent of this sprint is to provide a very strong, flexible and stable core for future development to build upon. The design goals, principles, and spirit of the project manifest themselves in presentations at Debconf2007, FOSDEM 2008 and LCA 2008 available from the main project site. There are also many documents in the doc/ directory in the project's git repository that identify particular techniques and strategies that are planned, were scrapped, or are still in a state of flux. I have spent time with these sources and feel I understand the project's aims on an intuitive level. As more specific and detailed design plans are created, I will keep these original goals in mind. # Project Schedule: how long will the project take? When can you begin work? The project should span the entire GSoC timeline. Additionally, I plan to be involved after the 1.0 release and the GSoC ends. I will be able to allocate a large amount of time, the equivalent of a full time employee (at least 40 hours/week), between May 16 and August 20 as I'll be out of school for the summer. Here's a week-by-week breakdown: Before 5/26: Study the current netconf codebase, document and clean up code, write tests, stash away old documentation and code in current repo Week 1 [5/26]: Implement inet6 /etc/network/interfaces methods Week 2 [6/1]: Implement inet6/v4tunnel method, Week 3 [6/8]: Design policy system and config format, initial implementation Week 4 [6/15]: Finish implementing policy system Week 5 [6/22]: Implement netlink socket listener + events Week 6 [6/29]: Implement wireless-tools and wpa-supplicant integration Week 7 [7/6]: Continue implementing wireless-tools and wpa-supplicant integration Week 8 [7/13]: Mid-term GSoC reviews; At this point, we should be very close to 1.0. The time that follows should be used as buffer space for things that may end up taking longer than estimated. Assuming a perfect world, full moon, and star alignment, the following weeks will be used to implement optional fun features. Week 9 [7/20]: Implement LinkLocal integration Week 10 [7/27]: Implement Additional DHCP options, http_proxy options Week 11 [8/3]: Implement ppp/wvdial functionality [Martin has offered to supply the hardware if necessary] Week 12 [8/10]: Run through the TODO [3] and implement minor leftover features Week 13 [8/17]: GSoC 2008 ends; have a beer :) After week 13: Continue to work with the netconf team to get 1.0 out the door; begin work on next challenges * Note: Each week will also involve writing unit tests and documentation for each task, and a weekly blog entry that summarizes my efforts, lessons learned, and results for the week. This schedule is based on the roadmap at [2], my initial review of the current state of the source code, and speaking with Martin about what has already been implemented on the roadmap. Upon completion of the proposed schedule, all of the requirements of the 1.0 roadmap should be satisfied with the exception of ppp/wvdial (I do not have the hardware for this, unfortunately). This schedule will be stored in my netconf git branch and updated as needed. [1] http://netconf.alioth.debian.org/ [2] http://git.debian.org/?p=netconf/netconf.git;a=blob;f=doc/roadmap-1.0.txt;h=285a2cbb47a57e23c3ea043f2c6a9d3d35cbc129;hb=HEAD [3] http://git.debian.org/?p=netconf/netconf.git;a=blob;f=doc/TODO;h=42e449b9d3248ca0881c85d9b0c0a262860bf11b;hb=HEAD