User Tools

Site Tools


98hackathon

IETF 98 Hackathon

The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards.

When: Saturday March 25, 2017 and Sunday March 26, 2017
Where: Swissotel Chicago
Signup for the Hackathon here: Hackathon Registration
View the list of registered Hackathon attendees: Attendees

Keep up to date by subscribing to https://www.ietf.org/mailman/listinfo/hackathon
The Hackathon is free to attend.



Agenda (subject to change)

  Saturday, March 25
      09:00: Room opens - Pastries and coffee
      09:00: Posters of all technologies on display
      09:30: Hackathon kickoff 
      09:45: Form Teams
      12:30: Lunch
      15:30: Afternoon break - Snacks provided
      18:30: Progress check and sharing
      19:00: Dinner
      22:00: Room closes and is locked
  Sunday, March 26
      09:00: Room opens - Pastries and coffee 
      12:30: Lunch 
      13:30: Hacking stops, prepare brief presentation of project
      14:00: Project presentation to other participants and judges
      15:00: Recap and suggestions for improvements
      15:30: Awards presented, prizes given
      16:00: Hackathon ends

For your planning purposes, be aware that we will also have:

  • Space reserved in the IETF Lounge throughout the week of IETF, March 27-31, for people to gather and collaborate on hackathon activities
  • A table at Bits-N-Bites on Thursday, March 30, for hackathon participants to share their projects with the IETF community at large

Meeting Materials


Technologies Included in Hackathon (more can be added)

YANG/NETCONF/RESTCONF

  • Champion(s)
    • Benoit Claise
  • Project(s)
    • yangcatalog.org: Joe Clarke, Benoit Claise, Einar Nilsen-Nygaard (remote, tentative)
    • improve YANG model monitoring tools at http://www.claise.be/ : Benoit Claise
    • pyang plugin - mapping combined config/state YANG models to split config/state models (IETF and/or OpenConfig structure): Rob Wilton
    • yanglint in http://yangvalidator.org/: Radek Krejčí (tentative)
    • L3SM Yang in ONOS: Gaurav Agarwal
    • RFC 6470,7895 and 7950 implementations for yuma123 and new 2.10 release and Debian package: Vladimir Vassilev

Universal Acceptance (see www.uasg.tech for background on Universal Acceptance)

  • Champion(s)
  • Project(s)
    • Identify the applications that the IETF uses that are UA relevant – that is that they deal with a domain name, including domain names in email addresses.
    • Prioritise the application for ease of remedy or maximum benefit – ideally one and the same.
    • Review the code, including code libraries. If newer libraries are available that include UA Ready routines, then make the upgrade and deploy the UA ready routines.
    • Where routines are not available in the existing or more current library, then make the relevant code changes to make the application UA Ready.
    • Consider updating the underlying library with UA ready routines.

ANIMA

  • Champion(s)
  • Project(s)
    • Interop testing of Autonomic Networking Infrastructure components - try to get prototypes to work together.
    • bootstrap testing of: voucher creation, exchange and validation, pledge/Join Registrar interaction, Join Proxy/Join Registrar discovery, Pledge/Join Proxy Discovery

TLS 1.3

  • Champion(s)
  • Project(s)
    • OCSP + SCT cross-compatibility
    • 0-RTT + HTTP/2
    • Delegated Credentials
    • Exported Authenticators

COSE/JOSE

  • Champion(s)
  • Project(s)
    • Test vectors for JWT/CWT documents
    • OSCOAP Interop Testing
    • EDHOC development

DNS/DPRIVE/DNSSEC/DANE

  • Champion(s)
  • Projects
    • Discussion/design session on how DNS implementations can/should manage the root KSK rollover (considering both 5011 and alternative mechanisms). For example, this is non-trivial for a library like getdns.
    • DNS Client RPZ-like filter (Create GUI to control a local resolver and configuration and filter DNS traffic at the client. Useful when using an un-filtered/un-censored recursive e.g. a DNS Privacy service.)
    • DBUS API and nss-resolv support for Stubby https://getdnsapi.net/presentations/stubby-nanog68.pdf
    • Asyncio support in getdns Python binding
    • DNS-over-TLS service monitoring (e.g. Nagios plug-in). Using getdns seems a reasonable choice (or the Go DNS librray since Go has a good TLS package?). Must be able to specify: expiration date for the cert (like the check_http plugin), the qname, qtype, the pinned key… Bonus: being able to test the TLS configuration (no weak cipher, etc)
    • TLS chain extension (draft-ietf-tls-dnssec-chain-extension-01)
    • IPv6-only prefix discovery for DNS64 (RFC 7050)
    • Others welcome

PCE / ONOS

I2RS RIB

  • Champions(s)
  • Susan Hares
  • Project(s)
    • GateD implementation of I2RS RIB
    • GateD implementation of Topology

OpenBMP

  • Champion(s)
  • Projects(s)
    • Point-in-time peer snapshots with both machine and human readable diffs
    • Alert on prefixes that match dynamic, adaptive, and/or static conditions
    • Integrate BGP data with other data, such as geo-coding, RPKI, community mappings, etc.
    • More projects welcome

LoRaWAN Wireshark dissector

  • Champion(s)
    • dominique.barthel@orange.com
    • laurent.toutain@telecom-bretagne.eu
  • Project(s)
    • improve our Wireshark dissector for LoRaWAN to be used in the LPWA Working Group.
    • the current code can be found at (TBD).
    • we'll add dissection of the various options of the LoRaWAN frame headers, as well as the various MAC commands (which appear either in the header options list or as a payload).
    • the LoRaWAN frames are authenticated and the payload is encrypted. In the Over-The-Air-Authentication mode, session keys are derived from a preshared key and a nounce. We'll discuss ways by which our dissector could learn these keys to be able to MIC-check and decrypt the frames. Prior experience from contributors with other protocol dissectors would be very valuable.
    • we currently don't sniff the LoRaWAN frames off-the-air, but transport them inside another proprietary protocol: we'll provide such pcap files.
    • we'll be able to run live experiments (remotely) on the LoRaWAN commercial network in France.

Interface to Network Security Functions (I2NSF) Framework

Don’t see anything that interests you? Feel free to add your preferred technology 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 technology, we strongly suggest that you send email to hackathon@ietf.org to let others know. You may generate interest in your technology, 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-Technology-Name

  • Champion(s)
    • tbd
  • Project(s)
    • tbd

To request a wiki account, please click on the login button on the top right corner of the page, and choose register. If you need a new password please click on the login button on the top right corner of the page and choose Send new password.


Participant Preparation and Prerequisites

  • Bring a laptop on which you are comfortable developing software
    • Some projects may require installing additional software
  • Familiarity with the technology area(s) in which you plan to participate will certainly help
  • Champions will have posters describing their project(s) and be available to answer questions at the start and throughout the hackathon
  • Your laptop is the default development platform for each technology
  • Anything else that is required will be provided, such as VMs you can install on our laptop or access from your laptop
    • Installing and becoming familiar with VirtualBox or something similar will help
    • Note to champions: if planning to make use of VMs, please bring on USB drives to make available to others as download times can be painful
  • Specific coding languages are called out for some of projects (e.g. Python, Java), but this is heavily dependent on the project(s) you choose
  • Wireless access to the IETF network will be provided, and from there to the outside world
  • Wired access to the IETF network is available by request only
  • Git/GitHub is commonly used for open source projects. Familiarizing yourself with it is recommended.
  • Champions for each technology are encouraged to share any other things they think would be helpful in preparation for the hackathon

Remote participation

  • Participating in person is preferred, but we understand not everyone can travel. If you want to participate remotely, please contact the champion(s) for that project to determine how best to coordinate.
  • Jabber Room: hackathon@jabber.ietf.org

IPR and Code Contribution Guideline

All hackathon participants are free to work on any code. The rules regarding that code are what each participant's organization and/or open source project 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.

98hackathon.txt · Last modified: 2017/02/22 06:13 by jinyongkim