Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Dick Franks <> Tue, 27 March 2018 01:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC0EC128D2E for <>; Mon, 26 Mar 2018 18:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U9RjhoHgKbBc for <>; Mon, 26 Mar 2018 18:37:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17355126DC2 for <>; Mon, 26 Mar 2018 18:37:12 -0700 (PDT)
Received: by with SMTP id f14so20684913wre.8 for <>; Mon, 26 Mar 2018 18:37:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2QxNQCxcvQlf9R4DDeWQY4igbqYG/NLtBOKjom/fbrU=; b=tFLQA0SDfOWtrAlDTBHpyl+osH6q/YdP23ywq4w7uhOQIFf1Jpxs1h6rHgviprz6HS SvoCBkP5AKrnD+NAyBIgdsBIoxufKA+vwVy9OUDfQagJqOkUcrA0otHeJ7AnD+oJs14M Q3VPu45qPkX37WCZeQ3x8DoMQdfoTgcRy5/W0UiJZUkEPqMjAx5uQEyK+N+IcMNTQZ0g qhcbjBbbwpA+ap8MBWofxPrtQm52FO+jHfpIy2LkFWl5kOf3anYXjt/Ybt/WEFk05qqH f0tNEDbfupMdSBNXbI4Q2DfTAP9VEbqb4DAHcMNdmjLUSWwNcr8XoPr33JBom+PpLE7J 0jgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2QxNQCxcvQlf9R4DDeWQY4igbqYG/NLtBOKjom/fbrU=; b=EGUI+av1H39j0iaAHD/TiSusX6Yg3nZf/M74HSAtMpJ14fEwhi1mZ0HWFopo1pCtOo 47jXCnUY8t0Q0ZAzE8fW0ousUg3tW/vRkJGIqJYVK8KYlI1v5GWYzXffOCav4ckuaIMu xgzmbJ3ja+eoH/fDB+KSmjWGo305QxNk8hah34ct6Bw1ZsyYCeq0V0EWPJ97ZYt2LjlR bQdPIBqbpj1SwKIKWLRIdHxJVQMVJbeKb/DcjM0WNldMIQJvYI+bylacHdnBbIcNVJDz 0mr0petA3G0gOBcYf8UcEM/AoBmSgwprH+ekimAdoar44YERuOP9S8GEsF3bJ30pvoiM tGLA==
X-Gm-Message-State: AElRT7ENL8vLuTzZ9R1CclAxldF85PQ3hTpN9yY3wDApQTCwkTZvk6CU fXaalyAAga9SlqFeKIJ+nkJI8+gd6RHBSPiuIHE=
X-Google-Smtp-Source: AG47ELv7F6DvPyqEMwxDP/J1MoeXKhp8HvGCOXp2ieLZfpprbutSxz80CnDUzZm45EpiImmS+1aeYMsb+ngEnathmlI=
X-Received: by with SMTP id j14mr22811298wrh.138.1522114630630; Mon, 26 Mar 2018 18:37:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 26 Mar 2018 18:36:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Dick Franks <>
Date: Tue, 27 Mar 2018 02:36:29 +0100
X-Google-Sender-Auth: lKJUat6rDEmSJPWqDJo0DyCrpQk
Message-ID: <>
To: Paul Vixie <>
Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <>, dnsop <>, Paul Wouters <>
Content-Type: multipart/alternative; boundary="089e082fcdb8ddc14d05685aed4c"
Archived-At: <>
Subject: Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Mar 2018 01:37:14 -0000

On 26 March 2018 at 22:36, Paul Vixie <> wrote:

> i've had my symbolics 3640 online quite a bit in the last 30 years, and it
> still makes WKS queries, and i have used WKS responses to control it. the
> software still works as well as it was designed to do, but the vendor is
> long out of business. however, read on.

It still works because the end-points understand WKS.  There is no need for
the other nameservers en route to parse the rdata beyond knowing how long
it is.

Ondřej already decided to remove WKS from further consideration.

The focus of this draft is on MB, MG, etc. not the general case of RR

please see down-thread where deprecation turns out to be both undesirable
> for the reasons i've given, and additive to developmental complexity since
> there would be _more_ DNS RFC's to read, and suboptimal compared to
> declaring a core subset of DNS technology as "mandatory to implement" and
> simply leaving WKS (and its hypothetical friends) out of that core subset.

I fail to see how this changes the number of RFCs to be read.

Nobody has yet defined a core subset; all we have is a camel-load of DNS
technology most of which appears to be "mandatory to implement",
and a mountain of RFCs which are very unlikely to be 100% consistent with
each other.

Expelling one or more items from the "mandatory" set necessarily involves
writing an RFC to add to this mountain, and sometimes obsoleting an old one.

The result is a smaller set of "mandatory to implement" DNS technology.

Repeat this process until nobody can make a good case for further
expulsions;  what remains is the core subset.

Right now, neither you, nor anyone else, can have more than the foggiest
idea what that eventual core subset will look like.

But one thing is certain, if we continue bickering about crap like WKS and
MB, we will make no progress at all.