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

Joao Damas <joao@bondis.org> Wed, 09 May 2018 07:40 UTC

Return-Path: <joao@bondis.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA09126C3D for <dnsop@ietfa.amsl.com>; Wed, 9 May 2018 00:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1R0SOsqohPE for <dnsop@ietfa.amsl.com>; Wed, 9 May 2018 00:39:59 -0700 (PDT)
Received: from smtp1.bondis.org (smtp1.bondis.org [194.176.119.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE1A12D965 for <dnsop@ietf.org>; Wed, 9 May 2018 00:39:59 -0700 (PDT)
Received: from [192.168.1.139] (28.red-2-136-163.dynamicip.rima-tde.net [2.136.163.28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joao) by smtp1.bondis.org (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 <joao@bondis.org>
In-Reply-To: <20180508084904.GF91015@vurt.meerval.net>
Date: Wed, 9 May 2018 09:39:56 +0200
Cc: Tim Wicinski <tjw.ietf@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>, dnsop <dnsop@ietf.org>
X-Mao-Original-Outgoing-Id: 547544396.277154-fdb475bb7aced9cdda2f8847a7acb56e
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8933821-B920-4942-AB67-57F7591B858E@bondis.org>
References: <CADyWQ+EE9YCCM03wKvd-HefpoQVqhOfeeLKLV8L2LJj+tqmEzA@mail.gmail.com> <CACWOCC936z-4j8e+d7bvhfr_Mk8tk64tkuiRDTRtrqrBTJBKJw@mail.gmail.com> <CAHw9_iLgTvPHe5jeL-0QZJ4+cxes8bBpCEULuDKThpjXoKzrbA@mail.gmail.com> <20180406134501.GC49550@vurt.meerval.net> <4A943DE7-81BC-41AC-93F7-4EC0975DF6B6@gmail.com> <5E7C31BE-EA5F-4A68-96FE-975CFAF77E42@apnic.net> <20180507190705.GP91015@vurt.meerval.net> <4E18F085-59CE-4DD8-A5CB-44E8F2D246E7@isc.org> <20180508084904.GF91015@vurt.meerval.net>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wORE9RLhdvae68_oueIxdmn5mf4>
Subject: Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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

Joao

> On 8 May 2018, at 10:49, Job Snijders <job@ntt.net> 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: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations
> 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
>> DNAME.
>> 
>> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop