IETF Hackathon Closes Loop Between Open Source and Standards
The first ever IETF Hackathon was held March 21-22, the weekend before IETF 92 in Dallas, TX. It was a late addition to the conference schedule, answering the call to action from Engineering CTO and Chief Architect Dave Ward’s talk at IETF 91, Open Standards, Open Source, Open Loop. Cisco DevNet teamed up with IETF leaders to put the event together in short order. Stated goals included bringing running code back into the IETF, bridging the gap between open source and open standards, and introducing more developers and young people to the IETF. It was a huge success by these and other measures, as evident by the announcement at the plenary session of another hackathon at IETF 93 in Prague. So started the blogpost recapping the experiment now known as the first IETF Hackathon.
Fast forward to IETF 100 in Singapore, a milestone event in IETF history. The Hackathon has become the official start of the IETF meeting and a valued part of IETF culture. Wnhereas the first hackathon involved only 3% of meeting participants, this hackathon involved 22%. The following pictures are IETF 92 hackathon (top left), IETF 100 hackathon (top right), graph of number of IETF hackathon participants (bottom).
Despite its growth, the goals of the hackathon remain exactly the same. There have been some changes to the format to accommodate the growth, but the overall agenda and unorthodox style of the hackathon are essentially unchanged. The IETF Hackathon is not your typical hackathon. There is no hype, no sleeping bags, and no prize money. Instead, there is collaboration, common goals, and a drive to make the internet better, faster, and more secure. These motivations are stronger than you might expect.
Despite it being the weekend and Singapore being a great city to play tourist for a couple days, the hackathon room started to fill quickly after the doors opened at 8am. By the official kickoff at 9:30am, it was clear this hackathon would set new records for attendance, ultimately drawing 219 registered participants, eclipsing the previous record of 199 set a few months earlier at IETF 99 in Prague.
Work at an IETF Hackathon revolves around a set of projects. Each project is proposed and led by one of more volunteers, also known as “champions”, willing to lead work related to new, developing, or existing IETF standards. These champions are the life blood of the IETF Hackathon. The responsibilities of a champion are as follows:
Before the Hackathon:
- Update the hackathon wiki with details about project
- Share ideas and any preparation materials or requirements with potential attendees via the hackathon email list
- Recruit participants from associated working groups, open source projects, standards organizations, etc.
At the Hackathon:
- Create and display a poster or sign that introduces the project and makes it
easy to find
- Be available to answer questions and help others
- Hack on things in their copious free time
Anyone can be a champion, and any project is welcome provided it has some ties to existing or future IETF work. The projects at IETF 100 were:
- Data Leak Prevention (DLP)
- IPv4-IPv6 Transition Technology Interop
- JMAP Interop
- DNS-Based Service Discovery (DNSSD)
- Captive Portals
- Interface to Network Security Functions (I2NSF) Framework
- Public Interest and HTTP Status Code 451
- Generating Certificate Requests for Short-Term, Automatically-Renewed (STAR) Certificates
- IPv6 compression + fragmentation prototype implementation for LoRaWAN
- DOTS Interop
- ECN / AQM Testing & Interop
Following a brief kickoff presentation covering the agenda and other housekeeping items, participants self-organized into teams and got to work. The nature of the hackathon is such that it is not uncommon for participants to work on multiple projects and for teams to work together on newly discovered areas of common interest. This level of cooperation and knowledge transfer is another noteworthy benefit of the hackathon. The increased awareness and relationships established during the course of the weekend are arguably more important than the code that gets written.
These newly established connections are not limited to people in different IETF working groups. In many cases, they involve people from open source communities, other standards organizations, and local universities. The hackathon in Singapore included 76 people for whom it was their first hackathon, and 46 people for whom this was their first time at any IETF function. That is clear testament to the ability of the IETF Hackathon to bring different groups of people together.
The majority of the hackathon participants gathered in Singapore to participate in person. However, there were a number of remote participants as well. Remote participation, while not ideal, can work quite well, especially in cases in which one or more people are onsite to bridge the gap between what happens locally and remotely. Taken together, participants represented 38 different countries!
As mentioned previously, the IETF Hackathon is not an all-night affair. Most participants have a full week of intense meetings immediately after the hackathon; consequently, the hackathon doors close at 10pm to encourage participants to get some sleep. Most return the next morning as soon as the doors open and the coffee arrives.
The official start on Sunday is 9am, but many arrive earlier than that, eager to get back to work. This continues until 2pm when coding stops and sharing of results begins. Each team delivers a brief presentation, no more than 3 minutes, recapping what they achieved, lessons learned, and feedback they intend to bring back to relevant working groups to guide and accelerate corresponding standardization efforts.
In the spirit of friendly competition, winners are announced and prizes are awarded. Thanks to Cisco’s Collaboration Group, the sponsor for the IETF 100 Hackathon, there were some pretty nice tech gadgets from which winners could choose. The winning projects were as follows:
DNS: Best Overall (presentation)
- partial implementation of DNS over TLS in Bind, based on RFC 7858, Specification for DNS over Transport Layer Security (TLS)
- python scripts for proxying DNS over HTTPS to a recursive resolver based on draft-ietf-doh-dns-over-https, DNS Queries over HTTPS
- prototype in DNS privacy daemon, Stubby, of DANE Authentication of TLS upstream per draft-ietf-dprive-dtls-and-tls-profiles-11, Usage and (D)TLS Profiles for DNS-over-(D)TLS
IPv4-IPv6 Transition Technology Interop and NAT64 testing: Best Input for the Scotch BoF – to the universal deployment of IPv6! (presentation)
- interop testing of Vector Packet Processing (VPP) DS-lite (AFTR) and Allied Telesis (DS-lite B4) as well as several other v4v6 combinations
- implementation of VPP DHCPv6 PD client, Stun library DNS64 NAT64 discovery / IPv4 literal synthesizer
- testing applications behind DS-lite, 464XLAT, NAT64
Results, lessons learned, and recommendations were shared and will be fed back
I2NSF: Best Student Project
The team from Sungkyunkwan University in South Korea continued their ongoing work proving the framework being standardized by the Interface to Security Network Functions working group. This entailed is using NETCONF, RESTCONF, YANG data models in combination with OpenDaylight for management of network security functions.
YANG/NETCONF/RESTCONF: Best Long-Term Work (presentation)
- YANG Suite integration with YANG Catalog
- YANG Development Kit (YDK) integration with YANG Suite
- YANG module semantic versioning and diff views from YANG Catalog
- REST API for the YANG Regex validator
- Automated YANG test harness against confd and netconfd
- Integration of YANG Catalog with IETF
TLS: Best Remote Participation (presentation)
Huge team that included 16 participants in Singapore and 8 remote participants from Japan, London, and Mauritius (hackers.mu) that tackled development and interop testing of 10 applications based on their support for draft-ietf-tls-tls13, The Transport Layer Security (TLS) Protocol Version 1.3. As a result, TLS 1.3 is closer than ever to releasing, there is a larger network of implementers, and the group is ready for more experiments with middleboxes.
DOTS Interop: Best Open Source Project (presentation)
- successful interop testing of two implementations of the protocols being standardized in the DDoS Open Threat Signaling (dots) working group
- adding new features to open source implementation (go-dots)
- detailed feedback for the working group
SACM: Best Cross Area Work (presentation)
Project involved joint work between NETCONF and Security Automation and Continuous Monitoring (SACM) working groups to add support for telemetry to SACM based on draft-ietf-netconf-yang-push, YANG Datastore Subscription, YANG Push.
All the project presentations are available at the Hackathon Meeting Materials page. The DNS and I2NSF teams went on to demo their projects to the entire IETF community prior to the plenary session on Wednesday. This helped extend the reach of the hackathon and further establish an appreciation of the benefits of running code to ongoing standardization efforts.
On Thursday, Dave Ward delivered another provoking talk, this one titled 3 years on: Open Standards, Open Source, Open Loop. It gave the IETF community an opportunity to look at how much progress has been made, discuss successes and failures, and consider how best to interact with developers, communities and deployers of open source going forward.
The end of the hackathon did not mark the end of the efforts involving running code. Throughout the week, coding and experimentation continued in the Code Lounge, a portion of the IETF Lounge designated for ongoing work on hackathon and other projects. Of particular note was experimentation on Explicit Congestion Notification (ECN), RFC 3168. Thanks to Arris and the tireless efforts of Chris Tuska, a group of IETFers from Akamai and Apple were able to experiment with the impact of ECN when used on a variety of networks with different traffic loads. Their work was ongoing as this was being written, and it will continue at the IETF 101 Hackathon in London in March 2018.
The IETF is committed to continuing to host IETF Hackathons. Cisco DevNet is committed to continuing to organize them and provide developers with resources to prepare for and maximize productivity during the hackathon. A financial sponsor for the is still being sought for IETF 101 and for 2018 in general. If interested, contact Joe Abley.
Hope to see you at the IETF 101 Hackathon in London!