IETF Meeting Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
==== 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, [[https://datatracker.ietf.org/meeting/98/floor-plan?room=vevey-1-2|Vevey1/2]]\\
**Signup for the Hackathon here:** [[https://www.ietf.org/registration/ietf98/hackathonregistration.py|Hackathon Registration]]\\
**View the list of registered Hackathon attendees:** [[https://www.ietf.org/registration/ietf98/hackathonattendance.py?sortkey=3&login=%0A|Attendees]]

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

==== Agenda ====
    Saturday, March 25
        08:00: Room open for setup by projects champions    
        09:00: Room open for all - Pastries and coffee provided
        09:00: Posters of all technologies on display
        09:30: Hackathon kickoff 
        09:45: Form Teams
        12:30: Lunch provided
        15:30: Afternoon break - Snacks provided
        19:00: Dinner provided
        21:00: Room closes and is locked
    Sunday, March 26
        09:00: Room opens - Pastries and coffee provided
        12:30: Lunch provided
        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
        17:00: Tear down complete
    
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 ====

     * IETF 98 Hackathon Prep Call, Tuesday, March 14, 2017
       * [[http://https://cisco.webex.com/ciscosales/lsr.php?RCID=fe85a4bb239041baaafacd6997d2cb44|Play recording (39 min 21 sec)]] Recording password: Yu2jXt4y
     * Presentations can be accessed from [[https://datatracker.ietf.org/group/hackathon/meetings/]]
       * Send presentations you want uploaded to Charles Eckel <eckelcu@cisco.com>
     * Code can be accessed from [[https://github.com/ietf-hackathon|IETF Hackathon Github]] or from links provided within project descriptions below.
       * Request to be added to IETF Github organization by sending your Github ID to Charles Eckel <eckelcu@cisco.com>

----
==== 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čí
       * SDO plugins in http://yangvalidator.com : Mahesh Jethanandani
       * L3SM Yang in ONOS: Gaurav Agarwal
       * RFC 6470,7895 and 7950 implementations for yuma123 and new 2.10 release and Debian package: Vladimir Vassilev
       * yangexplorer and YDK - integrate YDK with yangexplorer to generate python code for attributes/actions selected in yangexplorer : Mahesh Jethanandani


**Universal Acceptance (see www.uasg.tech for background on Universal Acceptance)**
     * Champion(s)
       * Don Hollander <don.hollander@uasg.tech>
       * Joseph Yee <jyee@afilias.info>
     * 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.
       * EAI - UTF8 Support in IMAP (RFC6855)


**ANIMA**
     * Champion(s)
       * Brian Carpenter <brian.e.carpenter@gmail.com>
       * Michael Richardson <mcr+ietf@sandelman.ca>
     * 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
       * [[https://www.cs.auckland.ac.nz/~brian/graspy/|Prototype Code]]
              
**DTLS**
     * Champion
       * Hannes Tschofenig <hannes.tschofenig@arm.com>
     * Project: I would like to spend one day on the DTLS Transport-Agnostic Security Association Extension (draft-mavrogiannopoulos-tls-cid-00) and record layer optimizations. This is useful for version 1.2 and 1.3. On the second day I would like to focus on DTLS 1.3 (draft-rescorla-tls-dtls13), specifically the epoch handling and the ACK message handling. 

**TLS 1.3**
     * Champion(s)
       * Nick Sullivan <nick@cloudflare.com>
     * Project(s)
       * draft-19 - https://tools.ietf.org/html/draft-ietf-tls-tls13-19
       * OCSP + SCT cross-compatibility - https://tlswg.github.io/tls13-spec/#certificate
       * 0-RTT + HTTP/2
       * Delegated Credentials - https://tools.ietf.org/html/draft-rescorla-tls-subcerts-01
       * Exported Authenticators - https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-01

** NETVC **
     * Champion(s)
       * Timothy B. Terriberry <tterribe@xiph.org>
     * Project(s)
       * AV1 
         * Git repository: https://aomedia.googlesource.com/aom
         * Bug tracker: https://bugs.chromium.org/p/aomedia/issues/list
         * Gerrit: https://aomedia-review.googlesource.com/
         * Contributor's Guide: http://aomedia.org/contributor-guide/
       * Daala: https://git.xiph.org/?p=daala.git
       * Thor: https://github.com/cisco/thor
       * Are We Compressed Yet: https://github.com/tdaede/awcy
       * rd_tool (AWCY backend): https://github.com/tdaede/rd_tool
     * Resources:
       * Are We Compressed Yet: https://arewecompressedyet.com/
       * Video test sets: https://media.xiph.org/video/derf

**COSE/JOSE**
     * Champion(s)
       * Jim Schaad <ietf@augustcellars.com>
     * Project(s)
       * Test vectors for JWT/CWT documents
       * OSCOAP Interop Testing
       * EDHOC development

** DNS/DPRIVE/DNSSEC/DANE **
   * Champion(s)
     * Sara Dickinson <sara@sinodun.com>
     * Allison Mankin <allison.mankin@gmail.com>
     * Benno Overeinder <benno@nlnetlabs.nl>
     * Melinda Shore <melinda.shore@nomountain.net>
     * Others welcome
   * 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. [[https://www.monitoring-plugins.org/|Nagios]] plug-in). Using [[https://getdnsapi.net/|getdns]] seems a reasonable choice (or the [[https://miek.nl/2014/August/16/go-dns-package/|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 

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

**LoRaWAN Wireshark dissector**
     * Champion(s)
       * Dominique Barthel <dominique.barthel@orange.com>
       * Laurent Toutain <laurent.toutain@telecom-bretagne.eu>
     * Project(s)
       * the overall goal is to improve our Wireshark dissector for LoRaWAN to be used in the LPWA Working Group.
       * development
           * as a first step, we'll add dissection of the various options of the LoRaWAN frame headers, as well as the various MAC commands (which can appear either in the header options list or as a payload).
           * the current C-code source can be found at https://github.com/ltn22, which also includes instructions for recompiling Wireshark with the custom dissector
           * the LoRaWAN 1.0.2 specification can be obtained from http://www.lora-alliance.org/For-Developers/LoRaWANDevelopers.
       * validation
           * in short: we'll provide pre-baked pcap files; we'll also be able to generate pcap files as needed, from a live LoRaWAN network.
           * caveat: per current setting, we don't sniff the LoRaWAN frames straight off-the-air, but transport them inside another proprietary protocol. That's the way the dissector is made to work with us right now. We'll provide the corresponding pcap files. If you have pcap files with raw LoRaWAN frames (or even an actual sniffing device that you want to bring to the meeting), we'll make sure that the dissector accommodates your case.
           * caveat2: in order to run Wireshark on //our// pcap files, you'll need our proprietary protocol dissector in addition to LoRaWAN's. It can be found at https://github.com/Orange-OpenSource/sensorlab-dissector
           * we'll be able to run live experiments (remotely) on a LoRaWAN commercial network in France (one node in the city of Grenoble and one in the city of Rennes) to capture the traces we need to debug the dissector.
       * open question
           * the LoRaWAN frames are authenticated and the payload is encrypted.
               * in the Authentication-By-Personalisation mode, the device and the servers are pre-provisioned with a network session key and an application session key.
               * in the Over-The-Air-Authentication mode, both session keys are derived from a pre-shared root key and a nounce provided by the network server.
           * in either case, the dissector needs to know the session keys in order to be able to display the decrypted content.
           * we'll discuss ways by which our dissector could learn these keys in order to be able to MIC-check and decrypt the frames. Both ABP and OTAA modes will be discussed.
           * prior experience from contributors with dissectors for other authenticated/encrypted protocols would be extremely valuable.  

 **Interface to Network Security Functions (I2NSF) Framework**

    * Champion(s)
        * Jaehoon Paul Jeong <pauljeong@skku.edu>
        * Jinyong Tim Kim <timkim@skku.edu>
        * Jung-Soo Park <pjs@etri.re.kr>
        * Tae-Jin Ahn <taejin.ahn@kt.com>
    * Project(s)
        * I2NSF Framework for provisioning Network Security Functions (NSFs)
        * Firewall in I2NSF Framework using Software-Defined Networking (SDN)
        * Deep Packet Inspection (DPI) for VoIP-VoLTE Security Service in I2NSF Framework
        *  Working Group Drafts
            * https://tools.ietf.org/html/draft-ietf-i2nsf-framework-04
            * https://tools.ietf.org/html/draft-hares-i2nsf-capability-data-model-00
            * https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-00
            * https://tools.ietf.org/html/draft-jeong-i2nsf-sdn-security-services-05
            * https://tools.ietf.org/html/draft-kim-i2nsf-security-management-architecture-03
            * https://tools.ietf.org/html/draft-kim-i2nsf-consumer-facing-interface-dm-00
            * https://tools.ietf.org/html/draft-hyun-i2nsf-nsf-triggered-steering-00
            * https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-im-00
            * https://tools.ietf.org/html/draft-ahn-i2nsf-communications-security-use-case-01  

**Captive Portal**
     * Champion(s)
       * Kyle Larose <klarose@sandvine.com>
       * Others welcome. :)
     * Project(s)
       * Finish up the icmp I-D (https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01) in coova-chili
       * Try out various client solutions for consuming the icmp message.
       * Try to find security holes in the icmp I-D, and plug them (the output being suggestions to improve the I-D)
       * Work on defining and implementing a REST API for https://tools.ietf.org/html/rfc7710.

**AMT/multicast**
     * Champion(s)
       * Jake Holland <jholland@akamai.com>
       * Others very welcome
     * Project(s)
       * The current code is at https://github.com/GrumpyOldTroll/amt
         * (forked from mboned's reference implementation: http://www.utdallas.edu/~ksarac/amt/ )
       * Port amtrelayd to at least one wifi router under OpenWRT or similar
       * Add and test IPv6 support
       * Conformance tests vs. RFC 7450
       * Interop testing with other AMT implementations (Cisco, Juniper, etc.)
       * Stream some video through the relay
       * Make a libamtgw library for embedding AMT gateway functionality in client apps
       * Anything else that might make this technology easier to adopt and deploy

**tcpinc: TCP-ENO, tcpcrypt**
     * Champion(s)
       * Kyle Rose <krose@krose.org>
     * Project(s)
       * Working on a Linux kernel implementation of ENO
       * I welcome anyone else's help or independent contribution

**WebRTC**
     * Champion(s)
       * Carol Davids <davids@iit.edu>, IIT
       * Alan Johnston <alan.b.johnston@gmail.com>, IIT
    * Project(s)
       * WebRTC emergency services with location provided using the pidf-lo xml format from beacons or from browser
       * Includes WebRTC and SIP callers, WebRTC PSAP (Public Service Answering Point) call taker, and indoor location provided by BlueTooth LE beacons and a Location Server/Database or W3C Geolocation APIs
       * Based on https://tools.ietf.org/html/draft-ietf-rtcweb-overview and https://tools.ietf.org/html/draft-aboba-rtcweb-ecrit and https://tools.ietf.org/html/draft-marshall-ecrit-indoor-location
       * Using open source components such as NGINX, Kamailio, and Node.js and cloud APIs Agora.io
       * Handle end-to-end WebRTC and SIP-to-WebRTC emergency calls with location information
       * Repository https://github.com/IETF-Hackathon/webrtc-e911-psap


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. 
       * A basic tutorial is provided in this post: https://mailarchive.ietf.org/arch/msg/92hackathon/lM8Ag_is4a00PsudnzaqdV1vhoE
     * 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.
IETF Meeting Wiki

User Tools

Site Tools

Page Tools
