Re: [DNSOP] raising the bar: requiring implementations

Phillip Hallam-Baker <> Thu, 29 March 2018 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C18F1250B8 for <>; Thu, 29 Mar 2018 14:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pyu5bDUff-cY for <>; Thu, 29 Mar 2018 13:59:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3721412D956 for <>; Thu, 29 Mar 2018 13:59:58 -0700 (PDT)
Received: by with SMTP id t16-v6so6331859oih.3 for <>; Thu, 29 Mar 2018 13:59:58 -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=4dqtM9kChxUQqiOtA0udJPNQHq16GOvp7hupk0eXcf0=; b=LXlvCku3QayNGQn67icjpK+V3vMIWa7FQESWN1JXkjImj2fxjj6vJIsFhsHx9w7Oy6 tVp1hDpKiR8Dd0mcXc3LK3bsqTMHSM9s9Jol5iTINcCq3TrV6NVoKk8JkrULkoeA6E3u A4769LOP48CtCr/X9zoqccUmHJ60hhUHyuiA/9WonyJt0BhiAPm7fO5msQKCAtXZyR23 n09sYzCOyhqNVATMWDLCa9fXhhtLsF/387VcW4Qchl+gLcAThfhCfAJA28qlQKU1dzu5 WOnR9h+6oEKV87UvhLEzZR7OpzzcYzHxGjDvXgQ6xnaDx9OG/aXqvGdCeM3GSYy2XDhl XXkQ==
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=4dqtM9kChxUQqiOtA0udJPNQHq16GOvp7hupk0eXcf0=; b=Qmg8Nm2roJ4ISVfrvajf5ZATrdVwRDKV31E5uHC6CsmCbxgUpBC1yTAqtMPubBsFgk 3WbV74CfQUvx/xoaBhKfBLlrltPT7G3ED/FySp0vZcOhGOjIGCe5L2uvD1mCnyPVzWIm j/jxdVnar6X7gwD8RdEyDENg6WznVNYAxjPTYenjE1aV81cK0Si1pP8q3Sai3nEehPD7 gOmTzimMIBW9IVtQbfeKqNKZB+aLA1B9qu2a4oSUzw+5P7lbYCaCXXmcWotVUulq7GE1 z/qcB98EKln2B5m/pTY8kuEDftm6EDasTWx77dhxyeIqxJJRGdcUHJRj3wt3vylGy+TX iDfw==
X-Gm-Message-State: ALQs6tAHQQJwfJu7vs5vpsLhYTJZ4chKp7wfT2xK5Yp001xF4gOX8WG6 rdZkOmoQDKaNOOHhjzRPkxAghgND6fBrq13TZxk=
X-Google-Smtp-Source: AIpwx4/DQnzkIfDNjbA1hhZ+jMP9Mmje/RmffqGWUYu6Z7mcSj9F8FKFB7mkzYIEGjVme/P3/vFAlK83LvR+uerciZ0=
X-Received: by with SMTP id r198mr5660184oie.180.1522357197308; Thu, 29 Mar 2018 13:59:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 13:59:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <20180328151939.GA19504@jurassic> <>
From: Phillip Hallam-Baker <>
Date: Thu, 29 Mar 2018 16:59:56 -0400
X-Google-Sender-Auth: yTAu-c-c2tOJ4NlRMBd3-wqS_04
Message-ID: <>
To: Suzanne Woolf <>
Cc: Mukund Sivaraman <>, tjw ietf <>, dnsop <>
Content-Type: multipart/alternative; boundary="001a113cd5e0f786ee0568936761"
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 21:00:07 -0000

On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf <>

> Should we refuse to document such things because they’re not in well-known
> open source codebases, or have otherwise not passed tests of goodness?
> It’s not a rhetorical question. Given that people are extending the
> protocol outside of the IETF or any other formal process, in order to solve
> their own technical and business problems, it makes sense to ask ourselves
> periodically whether we should be encouraging them, trying to stop them, or
> something in between.

​There are in fact precedents for doing something of the sort. But not ones
that I think we should follow.

DNSSEC would have been implemented as part of the VeriSign ATLAS roll out.
The reason it was not was it simply could not be deployed using the tech
available with the spec as it was at the time without a major increase in
cost and complexity.

A blanket requirement for open source implementations may well have the
same effect.

Operating systems at Internet scale is vastly more complex than running
systems at network scale. It is not just the genius of the original
Internet designers that has allowed the Internet to scale from 100 nodes to
10 billion. There is a vast amount of unseen engineering work that is
equally heroic and some of that infrastructure comes with some very
specific constraints.

Some of the most useful work in IETF is making closed systems more open.
Often those projects require some extra slots to carry information that is
needed for some legacy system. I see no value to saying folk can't have a
smooth transition path from proprietary to open.