Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

> 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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

> 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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

> 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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

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

[DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

Hi WG Chairs (and WG) 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 of current implementation > status” as