Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Support for RFC7550 in kea (Tomek Mrugalski)
2. Re: Support for RFC7550 in kea (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Fri, 31 Jul 2015 16:12:55 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Support for RFC7550 in kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 28.07.2015 12:57, Marcin Siodelski wrote:
> The question becomes, do we want Kea to have a configuration parameter
> that allows for falling back to this original behavior (prior to
> RFC7550)? I have implemented this parameter and I even have tests for
> this. But, on reflection I tend to think that this switch should be
> removed and the only supported behavior should be per RFC7550. The
> reasons why:
Agree. This is the new way of how the protocol is supposed to work.
Fortunately, the likelihood of backward incompatibility is very small.
And that was confirmed by Tim Winters from UNH-IOL, who did extensive
interop testing.
If we get specific complains from actual users (I find that highly
unlikely), then we may consider adding such a knob.
Let's drop the switch.
Tomek
------------------------------
Message: 2
Date: Fri, 31 Jul 2015 16:26:07 +0200
From: Marcin Siodelski <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Support for RFC7550 in kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 31.07.2015 16:12, Tomek Mrugalski wrote:
> On 28.07.2015 12:57, Marcin Siodelski wrote:
> > The question becomes, do we want Kea to have a configuration parameter
> > that allows for falling back to this original behavior (prior to
> > RFC7550)? I have implemented this parameter and I even have tests for
> > this. But, on reflection I tend to think that this switch should be
> > removed and the only supported behavior should be per RFC7550. The
> > reasons why:
> Agree. This is the new way of how the protocol is supposed to work.
> Fortunately, the likelihood of backward incompatibility is very small.
> And that was confirmed by Tim Winters from UNH-IOL, who did extensive
> interop testing.
>
> If we get specific complains from actual users (I find that highly
> unlikely), then we may consider adding such a knob.
>
> Let's drop the switch.
Ok. Thanks.
I have actually already dropped it and the ticket is now awaiting review.
Marcin
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 17, Issue 1
**************************************
