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

Joao Damas <> Wed, 09 May 2018 07:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AA09126C3D for <>; Wed, 9 May 2018 00:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l1R0SOsqohPE for <>; Wed, 9 May 2018 00:39:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AE1A12D965 for <>; Wed, 9 May 2018 00:39:59 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joao) by (Postfix) with ESMTPSA id CBD8C62030A; Wed, 9 May 2018 09:40:47 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Joao Damas <>
In-Reply-To: <>
Date: Wed, 9 May 2018 09:39:56 +0200
Cc: Tim Wicinski <>, Suzanne Woolf <>, dnsop <>
X-Mao-Original-Outgoing-Id: 547544396.277154-fdb475bb7aced9cdda2f8847a7acb56e
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Job Snijders <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 May 2018 07:40:03 -0000

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 point out a couple of things here:

- there is an established way for drafts to progress to RFCs and within the RFC levels. The progression from proposed to full Standard absolutely requires implementations (plural)
- the issue is not specific to any give wg, it is an IETF-wide issue and so the right place for discussion of improving this aspect of standards development is the IETF list rather any specific wg list
- in the specific case in the subject, there is funding available to support final implementation of this idea on three code bases. This won’t be released until we are past a successful last-call (because that’s how it works) and so stalling this specific draft on behalf of a way more general idea and discussion is actually having the opposite effect of what the discussion’s goals are. It is delaying final implementation.

Just my 2 cents


> On 8 May 2018, at 10:49, Job Snijders <> wrote:
> 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 draft back to the WG Chairs at this
>>>> point for your review for potential submission as an RFC.
>>> 1/ While this is a step in the right direction, I'm not yet entirely
>>> impressed by the 'Implementation Experience' section. Is it somehow
>>> hard to write an implementation report that describes which
>>> implementations comply with the BCP 14 / RFC 8174 terms used in
>>> draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some
>>> blocker in this regard?
>> Is it a implementation report or a compliance report?
> Well, the current section on the implementations isn't much of either,
> it is very sparse. This working group should try to raise the bar for
> RFC publication, not explore what the bare minimum is. 
> I've used this example before: what I was hoping for is reports that
> allude to the BCP14 terms and implementation's compliance similar to
> what is done here:
> Overviews like these are easy to consume for humans, and are derived
> from extensive tests like the one you showed below.
> I'd like to note that describing people's intention to implement in a
> section called 'Implementation experience' of course doesn't add much
> value. :-)
>> To actually do a full compliance report for this draft it would
>> require including a complete DNSSEC compliance report and in turn a
>> complete STD 13 compliance report to meet this “MUST”.
>>   DNSSEC-Validating resolvers that implement this mechanism MUST
>>   perform validation of responses in accordance with the DNSSEC
>>   response validation specification [RFC4035].
>> A exhaustive compliance report would run to a couple of thousand tests
>> without doing a DNSSEC compliance report due to the combinatorial
>> nature of this draft.
>> You would need validate as secure zone, a validate as bogus zone, a
>> validate as insecure w/ signatures, a validate as insecure w/o
>> signatures.  You then for all of these need zones with and without A
>> and AAAA records at the test names where without includes both NODATA
>> and NXDOMAIN.  You then need to multiply that by servers configured to
>> validate and those configured not to validate.  Then you need to
>> multiply this by having the functionality enabled or disabled.  You
>> then need to do a test for each of the conditions in the list of
>> conditions that must be met for the modified responses to be returned.
>> You also need to do that where the label looked up after a CNAME and a
>> We skipped some of these tests when we built our system tests by I
>> believe we hit enough of them to be happy that the code is operating
>> correctly.
> Yes, I think you are touching upon the core of the issue. Discussing
> _how_ to test a specification is exactly the type of discussion to be
> held in this working group.
> Its commonly accepted that even seemingly simple specifications may be
> stringing together a number of complex features. Extensive testing and
> demonstrations of such testing are a necessity to be able to claim
> 'running code and rough consensus'.
>> S:rootkeysentinel:Mon May  7 17:55:35 UTC 2018
>> T:rootkeysentinel:1:A
>> A:rootkeysentinel:System test rootkeysentinel
>> [snip]
> Thanks for sharing this!
> So, the current status is that there is no longer zero, but now a single
> implementation of draft-ietf-dnsop-kskroll-sentinel-12?
> I see progress, but not last call material.
> Kind regards,
> Job
> _______________________________________________
> DNSOP mailing list