At Wed, 23 May 2018 14:39:40 -0400,
Warren Kumari wrote:
> Just so the WG knows, the authors (myself in particular) had some
> productive discussions with Job at the RIPE meeting in Marseille.
> As a reminder, this mechanism is designed to measure the *user* impact of
> the KSK roll - this means
On Thu, May 17, 2018 at 9:27 AM Joao Damas wrote:
>
>
> > On 17 May 2018, at 13:29, Job Snijders wrote:
> >
> > On Mon, May 07, 2018 at 07:07:05PM +, Job Snijders wrote:
> >> 3/ Section 3 states: "The responses received from queries to resolve
> >> each of these names would allow us to infer
> On 17 May 2018, at 13:29, Job Snijders wrote:
>
> On Mon, May 07, 2018 at 07:07:05PM +, Job Snijders wrote:
>> 3/ Section 3 states: "The responses received from queries to resolve
>> each of these names would allow us to infer a trust key state of the
>> resolution environment.".
>> From
On Mon, May 07, 2018 at 07:07:05PM +, Job Snijders wrote:
> 3/ Section 3 states: "The responses received from queries to resolve
> each of these names would allow us to infer a trust key state of the
> resolution environment.".
> From what I understand, in today's DNS world we can only reasonab
Hi Benno,
On 9 May 2018, at 09:12, Benno Overeinder wrote:
> There are now 2 implementations of kskroll-sentinel:
> 1) peer-reviewed and merged in the BIND master branch;
> 2) released with Unbound 1.7.1 last week.
>
> (And the draft mentions the implemention early versions of this
> technique
To followup on myself, and was dropped with quoting email.
On 09/05/2018 15:12, Benno Overeinder wrote:
>
> Implementation reports/observations for BIND and Unbound have been sent
> to the mailing list.
>
For the future, if the DNSOP working group likes to see an
implementation report in a more
Hi all,
(Speaking as implementer/NLnet Labs.)
To update all readers of this thread.
On 09/05/2018 14:56, Job Snijders wrote:
> Publishing draft-ietf-dnsop-kskroll-sentinel as RFC on the Standards
> Track - without implementations - is, plainly said, not very IETF-like.
> But I'm happy to observe
Dear Joao,
On Wed, May 09, 2018 at 09:39:56AM +0200, Joao Damas wrote:
> While I do agree with you that having implementations early on is a
> very desirable requirement, though I would disagree with making it a
> hard requirement (see the case of aggressive negative caching and how
> it unfolded
Hi Job,
While I do agree with you that having implementations early on is a very
desirable requirement, though I would disagree with making it a hard
requirement (see the case of aggressive negative caching and how it unfolded as
an example), for any new idea brought to the IETF I would like to
On Tue, May 08, 2018 at 11:05:50AM +1000, Mark Andrews wrote:
> >> We have also taken the implementation comments posted to the WG
> >> mailing list and collected them in a new section titled
> >> "Implementation Experience” in the light of Suzanne’s request
> >>
> >> So we would like to pass this
> On 8 May 2018, at 5:07 am, Job Snijders wrote:
>
> On Thu, May 03, 2018 at 06:15:49PM +1000, Geoff Huston wrote:
>> We have submitted -12 of this draft which we believe incorperates the
>> substantive review comments made during the WG Last Call period that
>> were posted to the WG Mailing Lis
On Thu, May 03, 2018 at 06:15:49PM +1000, Geoff Huston wrote:
> We have submitted -12 of this draft which we believe incorperates the
> substantive review comments made during the WG Last Call period that
> were posted to the WG Mailing List.
>
> > Editors: Please take “concern about a description
I reviewed the -11 to -12 changes and they look good to me.
The document is ready to go in my opinion.
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 3 May 2018, at 10:15, Geoff Huston wrote:
>
> Hi WG Chairs (and WG)
>
> We have submitted -12 of this draft which we believe incorperates the
> sub
Geoff Huston wrote:
On 4 May 2018, at 3:06 am, Paul Vixie wrote:
what are the implications for older (pre-KSKROLL) validators when
icann eventually rolls the key?
I assume that you are referring to security-aware resolvers that do
not perform the actions specified in this draft. There are
> On 4 May 2018, at 3:06 am, Paul Vixie wrote:
>
> what are the implications for older (pre-KSKROLL) validators when icann
> eventually rolls the key?
I assume that you are referring to security-aware resolvers that do not perform
the actions specified in this draft. There are no implication
On 3 May 2018, at 10:06, Paul Vixie wrote:
what are the implications for older (pre-KSKROLL) validators when
icann eventually rolls the key?
None. That is, they will either be ready or they won't be, and this
draft doesn't change that. This draft is about signaling, not about
actually being
what are the implications for older (pre-KSKROLL) validators when icann
eventually rolls the key?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi,
On 03-05-18 10:15, Geoff Huston wrote:
> We have also taken the implementation comments posted to the WG mailing list
> and collected them in a new section titled "Implementation Experience” in the
> light of Suzanne’s request
This draft is by now implemented in Unbound and is in version 1.
18 matches
Mail list logo
