Re: [DNSOP] raising the bar: requiring implementations

Mukund Sivaraman <muks@isc.org> Wed, 28 March 2018 19:48 UTC

Return-Path: <muks@isc.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 100D7126DC2 for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 12:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 Az-k_SJbYhyK for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 12:48:55 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC8D126D05 for <dnsop@ietf.org>; Wed, 28 Mar 2018 12:48:41 -0700 (PDT)
Received: from jurassic (unknown [49.203.219.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 4CDCE32C0A4F; Wed, 28 Mar 2018 19:48:39 +0000 (UTC)
Date: Thu, 29 Mar 2018 01:18:36 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: dnsop@ietf.org
Message-ID: <20180328194836.GB14536@jurassic>
References: <20180324110756.GE69302@vurt.meerval.net> <9a03dbfb-a4c7-9ca2-22c4-d00a0d0d0223@nlnetlabs.nl> <CADyWQ+G7oR5M9pHgj5Ty+4yL1nsep2mpujLiE7nf__kVmN13fQ@mail.gmail.com> <20180328151939.GA19504@jurassic> <a1a97166-453f-08bb-72d4-120012bfa6bd@pletterpet.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <a1a97166-453f-08bb-72d4-120012bfa6bd@pletterpet.nl>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MUcBDJ9bdHR05yR6R-DjGVBOKMk>
Subject: Re: [DNSOP] raising the bar: requiring implementations
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, 28 Mar 2018 19:48:57 -0000

On Wed, Mar 28, 2018 at 05:29:18PM +0200, Matthijs Mekking wrote:
> As mentioned in the meeting, I am in favor of requiring implementations
> before drafts become standards.
> 
> However, I would be opposed to limit acceptable implementations to the few
> major open source DNS implementations (define major). It should be
> acceptable for other organizations or just persons to contribute a reference
> implementation.

It depends on the topic of the draft of course, esp. where in operations
it applies. If it is nameserver territory, I absolutely want to see an
implementation in *any* of the major DNS implementations. By major, I
mean the popular ones (e.g., PowerDNS, NSD, Unbound, Knot, etc.) This is
because:

* A full-fledged nameserver is somewhat different from a toy
  implementation in performance and scalability (this point is from
  experience with a bad implementation of a draft)

* The rest of us want to see proof that it can be implemented (not just
  a promise or mention of implementation) and play with it and observe
  operational characteristics _freely_, and determine whether a draft
  will really improve things in the way it says it will. E.g., take all
  the multiple-answer drafts that are making the rounds.. in Singapore
  there was a presentation of a grand matrix of them, but who knows how
  they actually perform?

It's 2018. We aren't living in the dark ages with a single DNS
implementation.

If a draft is for nameserver software to implement, and if the authors
cannot implement it by themselves, they can persuade one of the open
source vendors to do so. If they are unable to persuade any, that should
be enough consensus about how significant that draft is. Speaking for
myself, we in our DNS implementation add support for several drafts
early in the draft stage because they look necessary or interesting, or
because we want to know how they behave early on.

		Mukund