Re: [DNSOP] raising the bar: requiring implementations

Matthijs Mekking <matthijs@pletterpet.nl> Fri, 30 March 2018 07:44 UTC

Return-Path: <matthijs@pletterpet.nl>
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 4DF31124BAC for <dnsop@ietfa.amsl.com>; Fri, 30 Mar 2018 00:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 W8RWhMx3TOv0 for <dnsop@ietfa.amsl.com>; Fri, 30 Mar 2018 00:44:44 -0700 (PDT)
Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEBF1205D3 for <dnsop@ietf.org>; Fri, 30 Mar 2018 00:44:43 -0700 (PDT)
Received: from [IPv6:2001:981:19be:1:395e:64ed:1228:ed55] ([IPv6:2001:981:19be:1:395e:64ed:1228:ed55]) by smtp-cloud8.xs4all.net with ESMTPSA id 1oiFfYNv44EsM1oiGfNSMK; Fri, 30 Mar 2018 09:44:41 +0200
To: dnsop@ietf.org
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> <20180328194836.GB14536@jurassic>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <1051cb8d-e4e0-fcf0-05e0-70d6a159372a@pletterpet.nl>
Date: Fri, 30 Mar 2018 09:44:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180328194836.GB14536@jurassic>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfMlU7J6xkt0qQJnVXwGxfKVRWtU8KOLzTyXu4VmpxOB8JCmtDkUFBdY9WNyZAh62fBgMD6ywpQiAwtyrCkLFfP5bhFK7kkoH4lyEKWBtQH3j8CTkr5s0 hxUwswdfNATayjo05xrKZFSuXH/oq7/MYVBkw6JktcF3MddUOqCLSoCU0XFMxCxsszlfFo1mNRrp4Yc0iB4TE8BjDCmCih9qaMvV7U1UdZSn/4YYI3+BO7CK U2jlcGFEbbf5hBaZa/NZ2/GP1F1ZrPv9VqxH/DHHHbE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UXxVmmmkkfX67sJl_t5XkHLztiM>
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: Fri, 30 Mar 2018 07:44:46 -0000

I can agree with the argument that if implemented in a major open-source 
DNS implementation it would weigh in more to the discussion, but 
limiting to is far too restricting in my opinion.

Best regards,
   Matthijs


On 03/28/2018 09:48 PM, Mukund Sivaraman wrote:
> 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
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>