[DNSOP] on 'when to implement' (was: Re: Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel)

"Peter van Dijk" <peter.van.dijk@powerdns.com> Tue, 08 May 2018 09:11 UTC

Return-Path: <peter.van.dijk@powerdns.com>
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 03EE5120227 for <dnsop@ietfa.amsl.com>; Tue, 8 May 2018 02:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 4ItYSnNgArBt for <dnsop@ietfa.amsl.com>; Tue, 8 May 2018 02:11:34 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3319F1201F2 for <dnsop@ietf.org>; Tue, 8 May 2018 02:11:34 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 539AE6A26A; Tue, 8 May 2018 11:11:32 +0200 (CEST)
Received: from [10.87.0.4] (unknown [145.15.244.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 23EC53C18E3; Tue, 8 May 2018 11:11:32 +0200 (CEST)
From: "Peter van Dijk" <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Tue, 08 May 2018 11:11:32 +0200
X-Mailer: MailMate (1.11.2r5479)
Message-ID: <D802B91D-A8DC-4DF7-BF7B-E93E79028BE9@powerdns.com>
In-Reply-To: <09F25B8D-25CA-47C4-B1A1-DA56B86D68F8@isc.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> <CAHw9_iLTJUdTt_YnuC+sw2aNB10iGZ4bbcmOnf4i-y5Zssu0qw@mail.gmail.com> <20180407062714.GA63728@isc.org> <09F25B8D-25CA-47C4-B1A1-DA56B86D68F8@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iNoPT3n-PbiinzssZjtWqRppZOY>
Subject: [DNSOP] on 'when to implement' (was: Re: Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel)
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: Tue, 08 May 2018 09:11:36 -0000

On 24 Apr 2018, at 15:02, Ondřej Surý wrote:

> And the MR was peer-review and merged into BIND master branch with 
> intent to backport the feature into older release branches.
>
> I don’t think it’s a useful or helpful to change the rules for 
> existing adopted work.

Nobody is changing the rules (yet - but we can dream!); some people are 
just being more vocal about the real need for implementation experience.

> We need to have a discussion on the mechanisms that would allow 
> implementors to know when to start the implementation of existing 
> draft.

I don’t think what we need here is more ‘procedure’. Either a 
draft manages to get (at least one) implementer involved early - or the 
draft is most likely not worth pursuing.

> From implementors point, it makes little sense to start implementing 
> before the protocol change is almost fully baked (aka WGLC and 
> further), because until then the protocol might change considerably.

It makes little sense to call a protocol change ‘fully baked’ if 
nobody has checked that implementation is even possible.

> So, if we require implementation report further down the road, it 
> needs to be more clearly defined than people suddenly shouting “this 
> is not ready” when WGLC starts.  And while the attempt to implement 
> something is certainly useful to get valuable feedback, it also 
> imposes some costs (with undefined limit) on implementors (especially 
> the open source implementors) and it sort of discards the whole 
> “Proposed Standard” -> “Internet Standard” classification at 
> global IETF level.

The costs are the very best reason to demand implementation experience 
before calling something ‘fully baked’. If a draft has real merit, 
somebody will invest time/money. If it does not have merit, nobody will 
implement, and the draft will die the death it deserves. In other words, 
a draft needs to put its money where its mouth is. This way, drafts that 
actually help operations (this is dnsOP, after all) will get the 
attention they need, while other drafts may wither away - and that’s a 
good thing.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/