Re: [DNSOP] raising the bar: requiring implementations

Phillip Hallam-Baker <> Thu, 29 March 2018 19:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B8811242EA for <>; Thu, 29 Mar 2018 12:05:22 -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 QO90i6DhYzTC for <>; Thu, 29 Mar 2018 12:05:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED863120725 for <>; Thu, 29 Mar 2018 12:05:20 -0700 (PDT)
Received: by with SMTP id w12-v6so7466432otj.7 for <>; Thu, 29 Mar 2018 12:05:20 -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=5fqO1qD5oMZ9nexwM9oMPRSR2WnA1tnIvHrIhk6lelo=; b=q3ZpukQ5G5BQtg0EnuPzjBVSG4m0AztCZ4k4CvKyg5DbphALtFPor03T2YpDxWyj27 Y4+vhoqFYi95r0nK8MTdvhTRzqpf72EChBzWfJ6SMqGiJ8T8SoSpotplv8YAxhwpbrYl NvP7Zh16S9/1HZ/E9TXW9Uy1IMxzDEbD05+csndV0+BL3zxJ6ZtE9G7tvx6z9GIy7Im0 tDOo+XYg0x2p+jCX0gEtbGvEv69F4U4C2Iuxl8SNuxHzx7boQU4DA3TbmYgxJPy4fSfW uGF765pJ9EMITij2owjIQ/2LqKLwzGNo759cYfm1rBLL8sgD6VC8GZ099Rop4ybERDHQ 8D+A==
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=5fqO1qD5oMZ9nexwM9oMPRSR2WnA1tnIvHrIhk6lelo=; b=r0ZEPyAgdHUL+uPS+yd0LH9MB40gdssTvhvdZkaz0IxHkUg4jxFW7DTiQFZH7aJ/VE Tb6jDxvg6OcDb34L74dpzrZcrAkAVoucZpYCzOscQKeEB1RtDVnstKkEyvYOnKlpK3zH SQEPHbL85BTx/KlKPh7/FLNoO8skk7JYxbpKkwNo3J9Hl4wzVPQl0rRjTZ9BlX198zCy R3FURPPL7UlDeSDTP01r2TmxOw4Hrd1rl2kz1Y4uQya2Fo6D0zEk0tMucWS+W6TbkcHB W9+Rt7RHB5sOLVQj474AwtpEkcDW5EDI+pBr2H4gIlfFxN2f/CvBxvRje8poKcCJQT6/ qAwg==
X-Gm-Message-State: AElRT7FIG351Dmss9TEaRdhYnupCwLnM2IUWBLRwjA56VQZqfzNdHln0 9pizzskWCCj7TLUWSclTzU7czbnWcjaMVbBhabQ=
X-Google-Smtp-Source: AIpwx4/s/ou2ykaISBBgoDcrEDj7U0q7W99DCxFxC9aELzPFXD+3iPRbTcRETSMsnFObL2/I8HI4mzZ3ZDsM2fVmVa8=
X-Received: by 2002:a9d:4a52:: with SMTP id d18-v6mr966344otj.380.1522350320265; Thu, 29 Mar 2018 12:05:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 12:05:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <20180328151939.GA19504@jurassic> <> <>
From: Phillip Hallam-Baker <>
Date: Thu, 29 Mar 2018 15:05:19 -0400
X-Google-Sender-Auth: o4X0vRdDcBZHApTXrzHGOrR4Ldw
Message-ID: <>
To: Paul Vixie <>
Content-Type: multipart/alternative; boundary="000000000000102cf4056891ce48"
Archived-At: <>
Subject: Re: [DNSOP] raising the bar: requiring implementations
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: Thu, 29 Mar 2018 19:05:22 -0000

On Wed, Mar 28, 2018 at 2:45 PM, Paul Vixie <>; wrote:

> i'm in general agreement with each of the assertions made at each layer of
> quoting above, but i have two quibbles.
> first, they aren't reference implementations. not even BIND, which for
> many years i called a reference implementation, is not one. a reference
> implementation is a special kind of beast, it's something that if you don't
> interoperate with it, you are in the wrong. we have a specification, and we
> judge the quality of that specification by the ease with which
> interoperable non-reference implementations can be made.
> second, i think it's 2018, and  can require that at least one of the
> demonstrated interoperable implementations be source-available. (not open
> source; we don't care about license, only transparency.)

​Quite, a reference implementation is not a production implementation. In
fact it may well not even be standards compliant because the most important
parts of an implementation to test are what happens when messages are not
as expected.

Production implementations should be forgiving in what they accept and
conservative in what they generate. Reference implementations should be the

I generate my deployment and reference implementations from the same source
but they are not the same thing.