The Internet Engineering Task Force (IETF) is holding a hackathon to encourage developers and subject matter experts to discuss, collaborate, and develop utilities, ideas, sample code, and solutions that show practical implementations of IETF standards.
When: 18 - 19 July 2026 (Saturday - Sunday)
Where: Hilton Vienna Park
Room: TBD
Sign up for the Hackathon
View the list of registered:
Keep up to date by subscribing to the IETF Hackathon email list.
The IETF Hackathon is free to attend and is open to everyone. It is a collaborative event, not a competition. Any competition is friendly and in the spirit of advancing the pace and relevance of new and evolving internet standards.
¶ Agenda
Subject to Change
Hackathon (all times are GMT-4)
¶ Saturday, 18 July
- 09:30 : Room open for setup by project champions
- 10:00 : Room open for all - pastries and coffee provided
- 10:30 : Hackathon kickoff
- 10:45 : Form teams, see Team Schedule
- 12:30 : Lunch provided
- 15:30 : Afternoon break - snacks provided
- 18:30 : Dinner provided
- 20:30 : Room closes
¶ Sunday, 19 July
- 09:30 : Room opens - pastries and coffee provided
- 12:30 : Lunch provided
- 13:30 : Hacking stops, prepare brief presentation of project
- 14:00 : Project results presentations
- 16:00 : Hackathon ends
- 17:00 : Tear down complete
Related activities before and after the Hackathon weekend
¶ Hackdemo Happy Hour
- Share your Hackathon project with the IETF community
- Monday, 20 July, Time: 19:00 - 20:00, Room: TBD
- View the schedule or reserve space for your team/project
- Reservations for space must be made by 13:00, Monday 20 July
¶ Shared Workspace
- Space for groups to gather and collaborate on running code
- Monday - Friday, 18 - 24 July, Room: TBD
- View the schedule or reserve space for your team/project
NOTE: You will need an IETF Datatracker account to login to the Hackathon Meetecho sessions.
When you register for the IETF Hackathon, you are sent a separate email to create an IETF Datatracker account if you don't already have one.
If you already have an IETF Datatracker account, please ensure that the email address with which you registered is associated with your Datatracker account.
If you received the email but the link to create an account has expired, please see the instructions below:
- Go to https://datatracker.ietf.org/accounts/create/
- Select "New Account" from the User menu at the top
- Enter the email address that you registered with for the Hackathon
- Follow the instructions in the email you receive
¶ Presentation and Meeting Materials
- You can share the code you're working on through the IETF Hackathon GitHub, or via the links provided in the project descriptions below.
- Request to be added to IETF GitHub organization by sending your GitHub ID to (hackathon-chairs@ietf.org).
- Hackathon project result presentations should be uploaded to Datatracker under the specific session Hackathon Results Presentations at 14:00-16:00.
- To upload your presentation, you must have a Datatracker account and be logged in.
- The Hackathon Results presentations from Sunday, 14:00-16:00, are available on Datatracker:
¶ Participant Preparation and Prerequisites
¶ Project Teams and Champions
- Champions are the leads for individual projects in the Hackathon
- Champions are individuals familiar with a given technology who volunteer to help get others get up and running with that technology
- Before the Hackathon, champions should:
- Add information about your project to the list of Projects included in Hackathon
- Recruit participants from associated working groups, open source projects, etc. Announcing your projects via an email to (hackathon@ietf.org) can be helpful as well.
- Specify when and how the project team will meet on the Team Schedule
- At the Hackathon, champions should:
- Make themselves available to answer questions and help others
- Hack on things themselves in their copious free time
- Additional projects are welcome at any time. For any questions, contact the chairs at (hackathon-chairs@ietf.org)
¶ Choosing a Project
- Champions post and lead projects
- Details on each project and links to additional information for each project are in the list of Projects included in Hackathon
- How and when teams meet during the week is up to them and can be found in the Team Schedule.
- Familiarity with technology area(s) in which you plan to participate will certainly help
- It is perfectly fine, even encouraged, to work on multiple projects
¶ Lost & Found
- Participants looking for a team and champions wanting help on their projects are encouraged to visit the Lost & Found.
¶ Development Environment
- Bring a laptop on which you are comfortable developing software
- Some projects may require installing additional software or make use of VMs or containers
- Installing and becoming familiar with !VirtualBox, Vagrant, Docker or something similar may be helpful
- Specific coding languages are called out by some projects (e.g. Python, Go, Java, C++), but this is heavily dependent on the project(s) you choose
¶ Sharing Code
- Git/GitHub is commonly used for open source projects. Familiarizing yourself with it is recommended.
- An online tutorial is available here: Git Tutorial
- The IETF Hackathon GitHub organisation is used by some of the Hackathon projects to host their repositories.
- If you would like to have your project/code hosted here, send your GitHub ID and the name of your project via email to (hackathon-chairs@ietf.org)
¶ Project Presentations
- All teams have the opportunity to present what they did at the end of the Hackathon.
- Hackathon project result presentations should be uploaded to Datatracker under the specific session Hackathon Results Presentations at 14:00-16:00.
- To upload your presentation, you must have a Datatracker account and be logged in.
- DO NOT WAIT until just before the start of the Hackathon project presentations to upload your presentation, as it may be lost in the chaos.
¶ Network
Access to the IETF network
The NOC team has an ongoing experiment that allows you to join the IETF network remotely as well as at an IETF meeting venue.
Requests for networking capabilities beyond wireless access to the IETF network (e.g., wired ports, L2 access, prefix delegation) can be sent to support@ietf.org.
All requests are addressed on a best effort basis. Advance notice is appreciated and improves the odds of your request being fulfilled.
¶ Webex sessions for teams
Champions can request a Webex account they can use to schedule meetings for their team. These are similar to the Webex accounts allocated to working group chairs to be used for virtual interim meetings. An account can be requested by a team champion at any time. Accounts will remain active and available for the duration of the IETF meeting. Request your account HERE. In the request form, you can use your project name where it asks for "Working Group Name" ("Hackathon Project Name").
¶ Ongoing Communication
In addition to registering for the Hackathon and subscribing to the Hackathon list. It is recommended to monitor both the Hackathon wiki and the list as the Hackathon approaches, determine which project(s) are of interest to you, and reach out to the champions of those projects to determine how best to be involved and coordinate with the rest of the team working on each project.
Champions are welcome and encouraged to list times and mechanisms for collaborating with their team in the Team Schedule. Participants can use this page to determine how and when to reach other team members.
The Hackathon kickoff and the project results presentations can be joined via Meetecho. The Hackathon Zulip stream may be used for general and project specific communication.
¶ IPR and Code Contribution Guideline
All Hackathon participants are free to work on any code. The rules regarding that code are what each open source project and each participant's organization says they are. The code itself is not an IETF Contribution. However, discussions, presentations, demos, etc., during the Hackathon are IETF Contributions (similar to Contributions made in working group meetings). Thus, the usual IETF policies apply to these Contributions, including copyright, license, and IPR disclosure rules.
¶ Projects Included in Hackathon
Note, all projects are open to everyone. However, some champions have identified their projects as being particularly good for those who are new to the IETF or new to the Hackathon. These projects are marked with a star, i.e. *. If you are championing a project that is great for newcomers, please add a * at the end of your project name.
For inspiration and examples of previous Hackathon projects see the previous Hackathon page.
¶ RESTful Provisioning Protocol (RPP)
-
Champions
Maarten Wullink maarten.wullink@sidn.nl
Pawel Kowalik pawel.kowalik@denic.de -
Project Info
The RPP working group is focused on designing a new protocol for registering objects in a shared registry, as a possible alternative for EPP. This will result in a series of specifications known collectively as the RESTful Provisioning Protocol (RPP). -
Hackathon Plan
- Discuss/Develop/Validate current and future work
- Develop running code
- Other interesting ideas
-
Related documents
¶ Identifier Locator Network Protocol (ILNP)
-
Champions
- Saleem Bhatti saleem@st-andrews.ac.uk
- Rodney Grimes rgrimes@freebsd.org
- Alistair Woodman awoodman@netdef.org
-
Project Info
- https://ilnp.cs.st-andrews.ac.uk
- RFCs 6740(E) - 6748(E)
- The basic approach is to deprecate the concept of an IP Address and replace it with addressing using separate Locator and Identifier values, a pairing of which forms an Identifier-Locator Vector (ILV). Although the architectural concept is independent of any particular network protocol, our ongoing research work is based on realising ILNP on IPv6.
¶ Low-Power Wireless IPv6 Networking with Thread *
-
Champion
Stuart Cheshire <cheshire@apple.com> -
Thread Overview
Thread is a specification for how to carry IPv6 datagrams over a self-configuring mesh of low-power IEEE 802.15.4 wireless links. Stuart Cheshire gave a brief presentation about Thread at the IETF 119 IAB Open meeting in Brisbane. The Thread specification is developed and published by the Thread Group. There are several independent implementations of Thread, the main one being the OpenThread open source project. This Hackathon event is open to all — Thread Group membership is not required, though of course Thread Group members are also welcome to participate.
-
Participants and Project Info
- To avoid taking up too much space on the main Hackathon page, Thread participants and projects are listed separately on the Thread Projects page.
¶ YANG Data Model for Network Inventory (IVY) - 2
-
Champions
Nigel Davis <ndavis@ciena.com> -
Project Info
The IETF IVY WG has been developing models for network inventory. Following on from the successful IVY activity at the IETF 125 hackathon, this hackathon activity will again focus on the modelling of physical inventory. The intention is to have multiple players in both inventory system role and controller role where the inventory system player displays physical inventory detail provided via an IVY conformant interface from various controllers. -
Hackathon Objectives and Plan
The aim is to extend the participation, exercise more of the model and, especially, to:
-- Work with the latest ivy YANG and potentially previous versions
-- Demonstrate systems from various vendors can interoperate and convey inventory detail
-- Explore for missing detail and demonstrate interop with additional new properties
-- Compare with other inventory models (especially [TAPI (Linux Foundation)] (https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI)) and add further properties as appropriate again demonstrate interop
-- Prepare proposals for updates to IVY model -
Related documents etc.
Network Inventory YANG (Ivy)
A Base YANG Data Model for Network Inventory
network-inventory-yang
TAPI
¶ Service Affinity Solution based on Transport Layer Security (TLS)
-
Champions
Aijun Wang (wangaj3@chinatelecom.cn) -
Project Info
This project aims to present a demo of the TLS-based service affinity solution. This proposal is designed for environments where operational simplicity and migration speed are paramount. It intentionally omits the path validation steps to minimize the latency of the migration process. Furthermore, it simplifies the trigger mechanism by using a new TLS alert, which is a direct and unambiguous signal. -
Related works
-
Service Affinity Solution based on Transport Layer Security (TLS): https://datatracker.ietf.org/doc/draft-wang-tls-service-affinity/
¶ AI based Network Management Agent (NMA)
- Champions
Xing Zhao (zhaoxing@caict.ac.cn)
Minxue Wang (wangminxue@chinamobile.com)
Bo Wu (lana.wubo@huawei.com)
Daniele Ceccarelli (dceccare@cisco.com)
Haomian Zheng (zhenghaomian@huawei.com)
Jin Zhou (zhou.jin6@zte.com.cn) - Project Info
The draft <AI based Network Management Agent(NMA): Concepts and Architecture> (https://datatracker.ietf.org/doc/draft-zhao-nmop-network-management-agent/) defines the Network Management Agent (NMA), an AI-driven entity that bridges the gap between service intent and network operations. It acts as the cognitive layer, autonomously decomposing intent, planning tasks, and making decisions, while leveraging SDN Controllers as the execution layer to enforce policies on the network infrastructure.
This project will produce a live demo of a single NMA agent. The focus is on validating NMA deployment and application in specific network domains, including but not limited to OTN (Optical Transport Network), SPN (Slicing Packet Network), etc. The demo will showcase how NMA integrates with SDN Controllers to achieve intent-based closed-loop automation, so as to validate the practicality of the NMA architecture and also identify potential areas for future standardization. - Related works
¶ Interop testing/Demo of CoAP-EAP
- Champions
Francisco López Gómez (francisco.lopezg@um.es)
Iván Álvarez Belotto (i.alvarezbelotto@um.es)
Rafael Marín López (rafa@um.es)
Gabriel López Millán (gabilm@um.es) - Project Info
CoAP-EAP was published as RFC 9820 in September 2025. It defines CoAP as a new lower layer for EAP, intended to support authentication in Internet of Things (IoT) and other constrained environments.
Researchers from the University of Murcia (Spain) have developed a new implementation of the final RFC specification to evaluate CoAP-EAP in a representative IoT scenario, including experiments with EAP-EDHOC, a new EAP method currently under standardization. To further validate both the CoAP-EAP implementation and the EAP-EDHOC experiments in constrained networks, this project invites additional implementations to enable interoperability testing.
Additionally, a demo of the current CoAP-EAP implementation in combination with EAP-EDHOC is available in a constrained scenario based on Nordic’s nRF52840-DK and nRF52840 dongle platforms using Thread to communicate, with the aim of promoting discussion on relevant aspects.
Furthermore, RFC 9820 defines the derivation and use of an OSCORE context to protect communication between the EAP Peer and the EAP Server. An alternative version has also been developed in which, instead of using OSCORE, EDHOC-PSK (currently under standardization in the LAKE working group) is executed using the MSK derived from EAP to establish session keys. - Related documents
CoAP-EAP: RFC 9820.
EAP-EDHOC draft: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-edhoc/
EDHOC-PSK draft: https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-psk/
¶ Validate YANG-Push to Message Broker End-To-End Data Processing Chain
-
Champion(s)
Thomas Graf (thomas.graf @ swisscom.com)
Leonardo Rodoni (leonardo.rodoni @ swisscom.com)
Ahmed Elhassany (ahmed.elhassany @ swisscom.com)
Benoit Claise (benoit @ everything-ops.net)
Paolo Lucente (paolo @ pmacct.net)
Vivekananda Boudia (vivekananda.boudia @ insa-lyon.fr)
Maxence Younsi (maxence.younsi @ insa-lyon.fr)
Pierre Francois (pierre.francois @ insa-lyon.fr)
Rob Wilton (rwilton @ cisco.com)
Daniel Voyer (davoyer @ cisco.com)
Deepya Mandadi (dmandadi @ blueplanet.com)
Sivakumar Sundaravadivel (sivakuma @ blueplanet.com)
Jérémie Leska (jeremie.leska @ 6wind.com)
Samuel Gauthier (samuel.gauthier @ 6wind.com)
Irfan Mohammad (irfan @ arrcus.com) -
Draft Specifications Message Broker
https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration
https://datatracker.ietf.org/doc/html/draft-ietf-nmop-message-broker-telemetry-message
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-anydata-validation -
Draft Specifications YANG-Push
https://datatracker.ietf.org/doc/html/rfc8639
https://datatracker.ietf.org/doc/html/rfc8641
https://datatracker.ietf.org/doc/html/rfc9196
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yp-transport-capabilities
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-library-augmentedby -
Project Info
https://www.network-analytics.org/yp/, validate and verify -
5 YANG-Push Publishers
-
2 YANG-Push Receivers
-
2 YANG-Push Network Telemetry Message
-
1 YANG Message Broker Producer and Schema Registry
-
3 YANG Message Broker Consumers
implementation in the area of YANG data schema validation and obtaining latest YANG-Push subscription state. Subscribe to YANG data on YANG-Publisher, obtain and register all YANG modules necessary to build YANG schema tree, register YANG schemas to Schema Registry and verify YANG notifications against scheme trees and produce and consume from Message Broker.
- Repository
https://github.com/network-analytics/ietf-network-analytics-document-status/tree/main/126/Hackathon
https://github.com/NetGauze/NetGauze/releases/tag/v0.12.0
https://github.com/pmacct/pmacct
https://github.com/CESNET/libyang/releases/tag/v5.4.9
¶ Demo of Agent Transfer Protocol (server-mediated messaging for the Internet of Agents)
-
Champions
Xiang Li (lixiang@nankai.edu.cn)
Lu Sun (sunlu25@mail.nankai.edu.cn)
Yuqi Qiu (qiuyuqi@mail.nankai.edu.cn)
Zuyao Xu (xuzuyao@mail.nankai.edu.cn) -
Project Info
The draft <ATP: Agent Transfer Protocol> (https://datatracker.ietf.org/doc/draft-li-atp/) defines the Agent Transfer Protocol (ATP), a server-mediated communication protocol for messaging between autonomous agents across administrative domains. Following the federated, server-mediated model used by SMTP for electronic mail, ATP specifies agent identifier resolution and public-key discovery, a sender authentication mechanism (Agent Transfer Signatures, ATS), recipient-side keying with payload-covering signatures (Agent Transfer Keys, ATK), and a DMARC-style alignment check between ATS and ATK. The error model defines outcomes for cross-domain delivery failures.
This project will produce an interoperability demonstration of ATP, so as to validate the practicality of the protocol architecture and identify potential areas for further standardization. -
Related documents
https://datatracker.ietf.org/doc/draft-li-atp/
¶ Adding PQ capabilities to SSH protocol
-
Champions
Alicja Kario (hkario@redhat.com)
Dmitry Belyavskiy (dbelyavs@redhat.com) -
Project Info
We are interested in providing PQ capabilities to the SSH protocol.
-
We are implementing the draft GSS-API Key Exchange with hybrid ML-KEM (https://datatracker.ietf.org/doc/draft-kario-gss-keyex-pqc/) for OpenSSH (https://github.com/beldmit/openssh-portable/tree/beldmit-f45-103p1-gsshybrids, based on existing patches implementing GSS-API Key Exchange in OpenSSH) and libssh (https://gitlab.com/pzacik/libssh-mirror/-/tree/gssapi-kex-pqc)
-
We are implementing pure ML-DSA signatures (https://datatracker.ietf.org/doc/draft-sfluhrer-ssh-mldsa/) for OpenSSH and libssh.
Docker image with a build: https://github.com/beldmit/openssh-ietf126-hackathon
Also Fedora/Red Hat builds of OpenSSH and libssh upstream supports hybrid ML-KEM/NIST variants using OpenSSL as backend, interoperability with Putty is tested and reached.
¶ Interop testing of new ACME server and client, Akamu
-
Champions
Alexander Bokovoy (abokovoy@redhat.com) -
Project Info
We are interested in testing new ACME server and client, Akamu, which both support PQ capabilities and Merkle Tree Certificates.
We are implementing new ACME infrastructure for FreeIPA and Dogtag PKI projects, https://codeberg.org/freeipa/akamu. It allows to issue certificates in x.509 and Merkle Tree Certificate formats for both classic and PQ cryptography. Akamu also provides MTC cosigner support.
¶ Interop testing of PQC enabled Kerberos PKINIT
-
Champions
Julien Rische (jrische@redhat.com)
Alexander Bokovoy (abokovoy@redhat.com) -
Project Info
We are interested in testing implementation interoperability for post-quantum PKINIT support.
We are working on adding PQC PKINIT support to MIT Kerberos, based on https://datatracker.ietf.org/doc/draft-bokovoy-kitten-pkinit-pqc/
¶ PermitReceipt Reference Evaluation for AI-Agent and Workload External Effects
-
Champions
Yong Bok Lee, Meridian Verity Group, [scott@meridianverity.com] -
Project Info
This project provides a runnable synthetic reference evaluation for PermitReceipt-based permit-before-commit authorization of AI-agent and workload external effects.Related Internet-Draft:
https://datatracker.ietf.org/doc/draft-lee-orprg-permit-receipts/Repository:
https://github.com/meridianverity/permit-receiptPublic evaluation release:
https://github.com/meridianverity/permit-receipt/releases/tag/v2.2.1-public-evalThe evaluation exercises deterministic canonicalization, action-digest binding, policy-epoch checks, scope checks, status and freshness checks, anti-replay handling, and fail-closed denial before a protected external effect is committed.
The project includes a provider-neutral synthetic agentic-commerce profile as one example effect family. It does not process live payments, store payment credentials, call live processors, or provide production payment processing, wallet, issuer, PSP, network-token, or settlement-rail functionality.
Hackathon goals:
- Review whether the PermitReceipt field model is understandable and useful.
- Review canonicalization and action-digest binding behavior.
- Review negative vectors and fail-closed denial behavior.
- Identify missing conformance and interoperability vectors.
- Discuss whether future work should separate requirements, architecture, data model, conformance, and wire-profile documents.
- Collect implementation and reviewer feedback for a future revision of the Internet-Draft.
Expected outputs:
- GitHub issues or pull requests for unclear fields, missing vectors, or implementation gaps.
- Candidate conformance-vector additions for future repository updates.
- Input for a future revision of the Internet-Draft.
Coordination:
- Remote/asynchronous coordination via GitHub Issues and IETF Hackathon communication channels.
- Synchronous review slot to be listed in the Team Schedule.
¶ In-Network Telemetry Aggregation Using IOAM Aggregation Trace and Template Options
-
Champions
Ramon Bister (ramon.bister@ost.ch)
Alexander Clemm (ludwig@clemm.org) -
Project Info
iOAM (in-situ Operations, Administration, Maintenance) has gained popularity as a mechanism to collect telemetry data from a network. However, what is of interest for many use cases is not so much raw telemetry data records from nodes themselves, but aggregates of telemetry data across the nodes of the path traversed by a packet. For example, aggregating packet dwell times can be indicative of end-to-end latency, identifying the interface with the deepest (maximum) queue depth along a path can expose bottlenecks, aggregating environmental indicators can help assess CO2-intensity of paths to optimize pollution-aware routing.
This hackathon project aims to demonstrate and extend a solution that allows to aggregate inband network telemetry data using new proposed extensions to iOAM for some of the mentioned use cases. The starting point is a PoC for those new iOAM extensions implemented using P4 on BMv2 switches on Ubuntu.
In summary, our goal is to
- raise awareness and interest in the proposed solution
- add support for new use cases, incorporating new aggregations and possibly new instrumentation for data that can be aggregated
- provide a demo for existing and extended use cases
Depending on interest, there are other possibilities that could also be pursued, such as implementing a companion app to actively probe aggregate telemetry and/or to support an intent assurance use case for intent-based networking.
The following are the primary drafts related to this Hackathon Project:
-
Aggregation Trace Option for In-Situ Operations, Administration, and Maintenance (OAM) (https://datatracker.ietf.org/doc/draft-cxx-ippm-ioamaggr/) defines a new option type that allows to aggregate IOAM data along a network path using aggregation functions such as sum, average, minimum, or maximum.
-
In Situ Operations, Administration, and Maintenance (IOAM) Template Option (https://datatracker.ietf.org/doc/draft-mbci-ippm-ioam-template-option/) allows to define a fixed-length IOAM Option-Type that can be updated by transit nodes along a path, the contents of which is defined by a template. It is possible to define templates to provide functionality equivalent to the Aggregation Trace Option, which supported as well.
A link to the repository of the PoC used as a starting point will be provided prior to the hackathon.
¶ Add Operational State Visibility to IETF-L3VPN-SVC with Telemetry
-
Champions
Ian Farrer ian.farrer@telekom.de
Kris Lambrechts kris@netedge.plus -
Project Info
The newly formed ONSEN WG is chartered with the creation, extension and maintenance of abstracted service and network YANG modules, such as the L3VPN service model. Currently, this model only includes nodes for configuration of service functionality ('config-true'). The ONSEN WG is chartered to extend the abstracted models to include state data to provide real-time visibility of how a provisioned customer service is currently performing based on collected telemetry, or operational state polling.
The goal of the Hackathon is to extend the existing service configuration functionality of the StratoWeave open-source network orchestration platform to:
- Add telemetry collection via a YANG Push 2 collector
- Implement the necessary intermediate automation logic to aggregate/evaluate collected telemetry
- Create and implement the relevant augmentations to the ietf-l3vpn-svc YANG model to make L3VPN service health visible via RESTCONF at the northbound interface
https://datatracker.ietf.org/doc/draft-wilton-netconf-yang-push-2/
https://datatracker.ietf.org/doc/html/rfc8299
https://github.com/stratoweave
Don’t see anything that interests you? Feel free to add a project to the list, sign up as its champion, and show up to work on it. Note: you must login to the wiki to add content. If you add a new project, we suggest you send an email to (hackathon@ietf.org) to let others know. You may generate interest in your project and find other people who want to contribute to it.
TEMPLATE: Copy/paste and update the following template to add your project to the list:
### Your Project
- **Champions**
name and email
- **Project Info**
project description
To edit the wiki, log in using your IETF Datatracker login credentials. If you don't yet have an IETF Datatracker account, you may get one by going here and requesting a new account.