Re: [DNSOP] raising the bar: requiring implementations
Mukund Sivaraman <muks@isc.org> Thu, 29 March 2018 20:05 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 8AEB4127601 for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 13:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 ZuTXsycksZix for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 13:05:45 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4CB12E03C for <dnsop@ietf.org>; Thu, 29 Mar 2018 13:05:45 -0700 (PDT)
Received: from jurassic (unknown [182.156.108.210]) (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 E6C5632C0790; Thu, 29 Mar 2018 20:05:41 +0000 (UTC)
Date: Fri, 30 Mar 2018 01:35:35 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Suzanne Woolf <suzworldwide@gmail.com>
Cc: tjw ietf <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Message-ID: <20180329200535.GA11358@jurassic>
References: <20180324110756.GE69302@vurt.meerval.net> <9a03dbfb-a4c7-9ca2-22c4-d00a0d0d0223@nlnetlabs.nl> <CADyWQ+G7oR5M9pHgj5Ty+4yL1nsep2mpujLiE7nf__kVmN13fQ@mail.gmail.com> <20180328151939.GA19504@jurassic> <DA663930-380B-4A81-880E-4F8A3DB9FF25@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DA663930-380B-4A81-880E-4F8A3DB9FF25@gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GRjkF9vF4LxR5GaI-YF-K2WxJUs>
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: Thu, 29 Mar 2018 20:05:48 -0000
On Thu, Mar 29, 2018 at 03:18:45PM -0400, Suzanne Woolf wrote: > > On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman <muks@isc.org> wrote: > > > On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: > >> I would say that most things we have adopted in the past few years do have > >> some implementations to reference. > >> Not when drafts are adopted, but generally before we head to WGLC I've > >> always wanted to see someone > >> who implemented the option in some manner. > >> > >> But yes, agree. > > > > I'd raise the bar even higher, to see complete implementation in a major > > open source DNS implementation when it applies. Sometimes implementation > > problems are very revealing (client-subnet should have gone through > > this). > > This is actually quite a good example of another problem: > Client-subnet was documented for Informational purposes; it was > already in wide use in the public internet and had an EDNS opt code > codepoint allocated from the IANA registry. > > Nothing that happened in DNSOP or the IETF changed that, and I > strongly suspect nothing that happened in DNSOP or the IETF could have > changed it. We found issues in the client-subnet description (in the draft stages) that were corrected before it became RFC - this involved some behavioral changes. However, the opportunity was not given to address fundamental design issues, so what's in the RFC largely documents the implementations preceding it and still has issues. I didn't think client-subnet was in wide use when it came to dnsop. Even today it doesn't look like it's in wide use. You have asked an interesting question, because what happens if something is already being used and there's no chance to update/correct problems because that would make it a different protocol? IMO, we should not put anything through dnsop that does not allow reviewing and correcting problems. It is pointless for dnsop to shepherd a draft to RFC when there's no possibility to influence it. During later stages of the draft via dnsop, we implemented client-subnet (resolver side) and found various problems. Some of these were addressed in the draft, but it was revealing how poor the state of the design/draft was. This is why I strongly suggest: A code contribution of a _complete implementation_ of everything described in the draft to one of the open source DNS implementations should come sometime during adoption, so that (a) issues in production implementation are revealed (b) it can be tried in the real world to understand how it behaves. As you're a co-chair: When Bert did that Camel presentation, I felt hooray, here's one of us who's talking about what the steady churn of ideas and RFCs is doing to DNS implementations. We finish implementing one draft and at almost breathless pace, a few more drafts queue up. It's not sustainable, esp. as all the existing features also need to be maintained for years. Introducing a new RR type that doesn't involve additional processing is relatively trivial and nobody objects about it. Introducing something like TCP pipelining, or rather, out-of-order query processing, may seem trivial when describing the change, but implementing it may need fundamental restructuring of the implementation. Proper implementation of client-subnet needs change everywhere within a nameserver from the client message parsing code to the data structures used for cache, and how cache lifetime is managed. Implementations are being stretched and bent 5 different ways to adapt to the length and breadth of all these newfangled DNS items that literally are showing up at an alarming pace. Bert really hit the spot at the right time. Something needs to be done to check what becomes an RFC. A good way is to require an open source implementation. If draft authors cannot supply that or convince an open source implementation to write support for it, it can go back to where it came from. Mukund
- [DNSOP] raising the bar: requiring implementations Job Snijders
- Re: [DNSOP] raising the bar: requiring implementa… Petr Špaček
- Re: [DNSOP] raising the bar: requiring implementa… Willem Toorop
- Re: [DNSOP] raising the bar: requiring implementa… tjw ietf
- Re: [DNSOP] raising the bar: requiring implementa… Mukund Sivaraman
- Re: [DNSOP] raising the bar: requiring implementa… bert hubert
- Re: [DNSOP] raising the bar: requiring implementa… Matthijs Mekking
- Re: [DNSOP] raising the bar: requiring implementa… tjw ietf
- Re: [DNSOP] raising the bar: requiring implementa… Tony Finch
- Re: [DNSOP] raising the bar: requiring implementa… Job Snijders
- Re: [DNSOP] raising the bar: requiring implementa… Paul Vixie
- Re: [DNSOP] raising the bar: requiring implementa… Frederico A C Neves
- Re: [DNSOP] raising the bar: requiring implementa… Frederico A C Neves
- Re: [DNSOP] raising the bar: requiring implementa… Mukund Sivaraman
- Re: [DNSOP] raising the bar: requiring implementa… Mukund Sivaraman
- Re: [DNSOP] raising the bar: requiring implementa… Mukund Sivaraman
- Re: [DNSOP] raising the bar: requiring implementa… Arsen STASIC
- Re: [DNSOP] raising the bar: requiring implementa… Tony Finch
- Re: [DNSOP] raising the bar: requiring implementa… Tony Finch
- Re: [DNSOP] raising the bar: requiring implementa… Jan Komissar (jkomissa)
- Re: [DNSOP] raising the bar: requiring implementa… Phillip Hallam-Baker
- Re: [DNSOP] raising the bar: requiring implementa… Suzanne Woolf
- Re: [DNSOP] raising the bar: requiring implementa… Mukund Sivaraman
- Re: [DNSOP] raising the bar: requiring implementa… Phillip Hallam-Baker
- Re: [DNSOP] raising the bar: requiring implementa… Matthijs Mekking
- Re: [DNSOP] raising the bar: requiring implementa… Petr Špaček
- Re: [DNSOP] raising the bar: requiring implementa… Petr Špaček
- Re: [DNSOP] raising the bar: requiring implementa… 神明達哉
- Re: [DNSOP] raising the bar: requiring implementa… tjw ietf
- Re: [DNSOP] raising the bar: requiring implementa… 神明達哉
- Re: [DNSOP] raising the bar: requiring implementa… Andrew Sullivan
- Re: [DNSOP] raising the bar: requiring implementa… Evan Hunt
- Re: [DNSOP] raising the bar: requiring implementa… 神明達哉