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

Tim Wicinski <tjw.ietf@gmail.com> Wed, 28 March 2018 08:38 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 D14BE124C27 for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 01:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 rpr3WikfqaKy for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 01:38:32 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 5010B12E741 for <dnsop@ietf.org>; Wed, 28 Mar 2018 01:38:29 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id r131so3572073wmb.2 for <dnsop@ietf.org>; Wed, 28 Mar 2018 01:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=yXezdw/BHctS7H2y2NJ5Kld1DWAHH684/UxJm4ZHFJk=; b=KDk29fDx34hVf+xJ6DESqFjWChwb/2d+x89RG3+OdSyMEtkXmDxZFC4I9MfmJY3Sbu uQxHWZAWvEtOr4GvpMRCsCiuHd3fdm/hdReKRyu8Qa5XwExoZMhlAl/YqbaB7P0W5GRB 3GtXZLO8cJr2HJHEVpgfTgDEwVnrT4IGXWIswV14OsyAFmGijKYiIJUTfknfStwNw7xz BKgbR7I3L1V4a6c5UqYVeuFwrf3OgtgKwbv5kRWDTohrP4KalGonU/VSBmDTKgrmn7z+ pFCmAEgVOSFjzGzBgfKiNGgd7kTSzsMbyGC8MfeP2z8iwk831Iobec5nimtASSnyhBbi qedw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=yXezdw/BHctS7H2y2NJ5Kld1DWAHH684/UxJm4ZHFJk=; b=a1+7HB/QDZ9e87KO86MVgO/5qFPLGQsh0I61+pU4+7y42bV1cAYudjXGsP53/2/80p n63ijdQZzuWYQVN7+1W0TLpzXI1XB1qBpQF4LCiORaIeoIbfRarTMb/z2FXz/HvLChim xwvQ6e9tT3Q06uJogCfjJbYqfR9Lk+EQ4U8l1PBI4lku3aMtTmc3ktg+WQBvQ7Dmf5Yy phCM54i2tXxJXy+SCq8rDvR1bF1/IGpxFEal7XzdyH8OLFYJcCIgWklj2l09ufrHl1d2 4MC7g2eluNqzyqTNn/9LEu65RM+0IFKNLI5MhBos9LMB+JSiQnlGYt14R18wF6ywdsB1 Im/A==
X-Gm-Message-State: AElRT7ESu/UIugBUNVxlSu2ZEb4dldr/HO74TkuYHmzE55CWcJOpzk6a /GOtpk3PDn1CWxWe2YqDyT0QhA==
X-Google-Smtp-Source: AIpwx49HQ9WjoAJ0Aps9E+eo+yAtJOpgxpDibvdVZT6j60q11JDArwhqaUgs8U6oBXZ0Gb83qVnYxg==
X-Received: by 10.80.173.75 with SMTP id z11mr2531667edc.306.1522226307728; Wed, 28 Mar 2018 01:38:27 -0700 (PDT)
Received: from twicinski-ltm.internal.salesforce.com ([62.17.146.144]) by smtp.gmail.com with ESMTPSA id e56sm2240097edb.84.2018.03.28.01.38.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 01:38:26 -0700 (PDT)
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>
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>
From: Tim Wicinski <tjw.ietf@gmail.com>
Message-ID: <937cde61-3e8e-ea65-b2fd-ed4030f2e311@gmail.com>
Date: Wed, 28 Mar 2018 04:38:24 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <5ABAB891.3010306@redbarn.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dpoUdIQzHItPM7ONftgC2OF7KKk>
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 08:38:34 -0000

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
>