Re: [DNSOP] Current DNS standards, drafts & charter

tjw ietf <tjw.ietf@gmail.com> Wed, 28 March 2018 13:58 UTC

Return-Path: <tjw.ietf@gmail.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 EA94112711B for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 06:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UJ7_4NwPDEyn for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 06:58:34 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C191C1270AC for <dnsop@ietf.org>; Wed, 28 Mar 2018 06:58:33 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id x4so5456852wmh.5 for <dnsop@ietf.org>; Wed, 28 Mar 2018 06:58:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7N6mM3j0XDvrsW74BA04vuM3Sbo7lx/6c9Kf1kU2ycQ=; b=eHX/4fKMJRDc2wA8fsNt94Y9xcGmKC7UcPXRurF9xOwAFwByyQzIYuRY/PYHOL6Skj GywzsMlCHyOS4dshzYgI4FAzlddMK7IuHh/z8FGL2iMMbZmw2jrVi48AaPbu+OjBgiZ4 EfTvwlrgD8iqQVw8h56nRAXDk+JkEj7JC0VnfCHCpFManWp6d8Hn/badghZoODRfLs4X gCJNN/WWGxlNERz6Gg04U6onHY70pwD1tqoFbvLYt8EDIwucEvDXfTYo13jzSESPEoJS AxDPIJcrR1sJ8zijh+EkwM/q/IZXDazqnXIuM5ITPCTbvmOLTqiDOFbkj5Xzxh6IdkjR ktcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7N6mM3j0XDvrsW74BA04vuM3Sbo7lx/6c9Kf1kU2ycQ=; b=geCuya7mn15WGjosqkTwSBUfxR08iiWy0CtgmxdU790ExI2pIrYu4177IxoNciibRU jmEqsANd2YD35sN8IigekUhJa+5moyOKTza3qZ/gzcmbh9LvZSjedXvfLAyJaYTqZPIh Q0Nlwq4nsWOgmfKdtZpFiDlz4aXhFdy1RTH/ZttIFAhLLv7YnSUgly4Pbi74R+RChT0f d3lrSgW98DY5mUVOz8RsMxIFkInyvTBMjfrzJ8dK2JPWhgL1ISigHL/K2q3Gycfhz9nm XVQyhyth/bbqga0muEGcZUJk4q0EFW+bcUlxG1Mr4UTAWpEPUe5ER12Zwvhi3GpH9TH5 QTJg==
X-Gm-Message-State: AElRT7EeNgrCg/43OHfB1NYmt+nIyQ/RoVi2JX+/Fw82Y4AYLJJR6VzZ h+bgCmti7fGC4OqWFHbbbEEZnFRABez0Uw9rC84=
X-Google-Smtp-Source: AIpwx4+8HQyBX0g6tjiQMw0X8N0PCDwYBzEMMt7LxpqbgEQRNXHopBTtAj229muY0QdJ78tnu0sQkdg8sJ4PE793fUc=
X-Received: by 10.28.128.206 with SMTP id b197mr2620312wmd.48.1522245512335; Wed, 28 Mar 2018 06:58:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.52 with HTTP; Wed, 28 Mar 2018 06:58:31 -0700 (PDT)
In-Reply-To: <937cde61-3e8e-ea65-b2fd-ed4030f2e311@gmail.com>
References: <20180326154645.GB24771@server.ds9a.nl> <CA3D81B6-164F-4607-A7E6-B999B90C4DA8@gmail.com> <5852643C-B414-4C3E-A1B9-553054D3DD46@isc.org> <CAAiTEH8aA3J1j4iUQDisDHiUJXopykKkssuhOK=v+iVV_XZWyA@mail.gmail.com> <5ABAB891.3010306@redbarn.org> <937cde61-3e8e-ea65-b2fd-ed4030f2e311@gmail.com>
From: tjw ietf <tjw.ietf@gmail.com>
Date: Wed, 28 Mar 2018 09:58:31 -0400
Message-ID: <CADyWQ+GCj=n3eBMwGKq-K0Aisz-_UvdpD0OC09vch=+4uMUkeg@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>, Matthew Pounsett <matt@conundrum.com>
Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@isc.org>, Suzanne Woolf <suzworldwide@gmail.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141e2fe06187005687967b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YmT7P7_9rbUaKIQz5WNJwPDwnVs>
Subject: Re: [DNSOP] Current DNS standards, drafts & charter
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 13:58:37 -0000

I should qualify my comments on Route 53 - I don't think they are something
we should emulate, more of an example of how 3rd party vendors get away
with an overly-minimal set of resource records.   The words I have to
describe them are generally not polite.

Tim


On Wed, Mar 28, 2018 at 4:38 AM, Tim Wicinski <tjw.ietf@gmail.com>; wrote:

>
> I have looked at the same problem Bert has, but he did present it much
> better than I could.  When I started thinking about this, I approached it
> from the point of view of "If I have to give a co-worker a document on how
> to build a DNS Server (Authoritative or Resolver), what would I need to
> give them".   I also have spent a lot of time watching the 793bis work in
> TCPM, which has been moving along slowly and methodically.  I felt what we
> would come up with would be
>     1. a DNSOP document which would be an implementation list for building
> an Authoritative or Resolver
>     2. a roadmap to work on 1034bis and 1035bis, which would be a new WG.
>
> I also realized that the second item would be brutal, painstaking, not
> "sexy" for most IETF standard types.
>
> I've had lots of experience dealing with the concept of "technical debt"
> and a lot of this is very similar.  But we also need someone who has the
> skill set of a project manager, who knows how to lay out workflows.  That's
> not something a bunch of programmers always have.
>
> Summary - Paul is on the right track here.    A good example is looking at
> what Route 53 implements (for better or for worse) and realize they
> implement some real minimal subset.   I think it's too small, but it's an
> interesting argument.
>
> tim
>
>
>
>
> On 3/27/18 17:33, Paul Vixie wrote:
>
>> i see no purpose in change documents, which would add to the set of
>> things a new implementer would have to know to read, and then to read.
>>
>> rather, we should focus on a DNSOP document set that specifies a minimum
>> subset of DNS which is considered by the operational community to be
>> mandatory to implement. any implementer can remove anything else and still
>> be checklist-compatible when customers are baking things off.
>>
>> if someone wants to implement iquery or WKS let that be crazy rather than
>> broken -- on-the-wire patterns still described, code points still reserved,
>> but unlikely to find anybody to actually interoperate with.
>>
>> vixie
>>
>> re:
>>
>> Matthew Pounsett wrote:
>>
>>>
>>>
>>> On 27 March 2018 at 03:49, Ondřej Surý <ondrej@isc.org
>>> <mailto:ondrej@isc.org>> wrote:
>>>
>>>
>>>     Again, from experience from dnsext, I would strongly suggest that
>>>     any work in this area is split into CHANGE documents and REWRITE
>>>     documents, with strict scope. Documents rewriting existing RFCs
>>>     while adding more stuff at the same time tend to not reach the
>>>     finish line.
>>>
>>> Does this include combining documents?  For example, it would probably
>>> make sense to combine some of the clarifications documents into any
>>> rewrite of 1034/1035.
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>>
>