Re: [dhcwg] DHCP hackathon in Berlin?

[Tomek Mrugalski <[e-mail]>]

Just a small update regarding hackathon.

Bernie and I received a couple of responses so far. One new topic has
been proposed and seems to be getting some traction: RFC7550/RFC3315bis
changes. There will be at least two server implementations to be tested:
Cisco's CNR and ISC's Kea. We're lacking client support, so the plan is
to hack a client during the hackathon. It seems the easiest open source
client to modify is Dibbler, but we're also looking at the ISC DHCP
client modification.

There's a team from Tsinghua university that's interested in developing
YANG module for DHCPv6 server. The code to be extended is Kea.

We also have one newcomer (both to IETF and to hackathon) who is
interested in participating! Welcome!

Please keep in mind that IETF is about rough consensus and running code.
We usually focus on the consensus part, but here's your chance to help
with the running code as well.

Tomek

On 11.05.2016 18:44, Tomek Mrugalski wrote:
> Hey DHCP hackers!
> 
> The IETF meeting in Berlin is not that far off. We'll have an
> opportunity to meet and hack some DHCP code, if we desire so. As usual,
> the question is whether there are enough people interested in hacking
> DHCP? Hackathons traditionally happen during the weekend before IETF, so
> it means July 16-17 this time.
> 
> Please respond if you're interested in participating. Feel free to
> propose the topics.
> 
> Looking at the current topics in DHC, it seems we have 2 areas that
> could definitely benefit from a hackathon. The first one is secure
> DHCPv6. We did some successful experiments in Prague (Kame client was
> interoperating with Kea server), but that was based on an old version of
> draft-ietf-dhc-sedhcpv6-12, which has changed significantly since then.
> 
> Another prospective topic for a hackathon is YANG module. One of the
> concerns raised against draft-ietf-dhc-dhcpv6-yang-01 (or rather general
> comment against any attempts of configuration standardization) was that
> it may be difficult to find a common denominator between existing DHCP
> implementation's configurations. Having a working code
> would definitely be a strong argument in favour of moving this draft
> forward.
> 
> Other topics are certainly welcome as well. Having two or more people
> working in the same feature are better than focusing on independent areas.
> 
> If you're interested in participating, but don't have a code base you'd
> want to work on, feel free to contact me and I'll give you some pointers
> to easily accessible open source implementations that are hackers friendly.
> 
> Tomek
>