Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

Job Snijders <> Wed, 09 May 2018 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB468124217 for <>; Wed, 9 May 2018 05:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.23
X-Spam-Status: No, score=0.23 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dSo_T6fK5t1y for <>; Wed, 9 May 2018 05:56:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B9E01241FC for <>; Wed, 9 May 2018 05:56:22 -0700 (PDT)
Received: by with SMTP id a67so24442556wmf.3 for <>; Wed, 09 May 2018 05:56:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=1ko59wjeD+9dxwjRlTPspVzLW0H0SBW22QPNKmqyiB4=; b=D9iQRN/u/JsGtEu0Hj6d2t8y4my6Sbj/L82cAhyePOeGJzxLKGKAfiCwzde+VkC1Qo mknnE2Po9VwptknP74DcXevoubes4K3Dc6o0ps+VJqkXscXkjfxsBW6FZxDaKTbodGUS CmyrSzJEBN7NqLi9XQiTc/yLskeqsTdOOKuCUsvxEzb0G2JitCNgsrIsXHw2VAsrh04w Eukk0bGIJQjRcWl+lNYCGuXDB4DoGgEI/LmF1FoFMnq+4KOdwYyn4vDH018NL8exROXZ tLNQRZJDKjxKA/89WQAqrT6w96SJX6XiCfNfwbnWn+q7dAsYuJpeU2wEVsszN81gmHUn Rfkg==
X-Gm-Message-State: ALQs6tChPAsKt6zbwAPnl69Lff9pzSx35sWHpatRaI8XweZKzYrwkHZf 6QgaCPtoKpI6uc9OWchl0G9iKg==
X-Google-Smtp-Source: AB8JxZpK5IyTFUaeoWEh7SGhwQUihlmplR4n9quTaNxuQ1sO8VZADQZ+ICS5T55YJ1dD8byb7Kz4aw==
X-Received: by 2002:a50:b485:: with SMTP id w5-v6mr61153274edd.100.1525870580439; Wed, 09 May 2018 05:56:20 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:393e:d093:404b:b7d6]) by with ESMTPSA id d29-v6sm9062450eda.52.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 05:56:19 -0700 (PDT)
Date: Wed, 9 May 2018 14:56:18 +0200
From: Job Snijders <>
To: Joao Damas <>
Cc: Tim Wicinski <>, Suzanne Woolf <>, dnsop <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.9.5 (2018-04-13)
Archived-At: <>
Subject: Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
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: Wed, 09 May 2018 12:56:24 -0000

Dear Joao,

On Wed, May 09, 2018 at 09:39:56AM +0200, Joao Damas wrote:
> While I do agree with you that having implementations early on is a
> very desirable requirement, though I would disagree with making it a
> hard requirement (see the case of aggressive negative caching and how
> it unfolded as an example), for any new idea brought to the IETF I
> would like to point out a couple of things here:
> - there is an established way for drafts to progress to RFCs and
>   within the RFC levels. The progression from proposed to full Standard
>   absolutely requires implementations (plural)

>From a rhetoric perspective you are quite creative in making a
_seemingly_ reasonable point: "why don't we kick the can down the road
and require implementations on the 'proposed standard' -> 'internet
standard' barrier?". But in my opinion you are misrepresenting the
'established way', this is reason for concern. The IETF TOA is a
foundational document, let's look at
section "A.5 Documents": 

    IETF Standards Track specifications are not considered to be
    satisfactory standards until interoperable independent
    implementations have been demonstrated. (This is the embodiment of
    the "running code" slogan.) 

Now let's look at
and in the upper left corner we see: "Intended status: Standards Track".

Publishing draft-ietf-dnsop-kskroll-sentinel as RFC on the Standards
Track - without implementations - is, plainly said, not very IETF-like.
But I'm happy to observe that the feedback received during WGLC was
taken serious and at least one implementer got to work, with indications
that more will follow.

> - the issue is not specific to any give wg, it is an IETF-wide issue
>   and so the right place for discussion of improving this aspect of
>   standards development is the IETF list rather any specific wg list

You seem to be attempting to move the elephant in the room to a
different room (generalizing the issue to an IETF wide scope), this
distracts from the issue at hand. Bert Hubert's talk about the "DNS
Camel" should have made it clear to anyone that DNSOP itself has a
problem. Each working group has to come up with strategies to maximize
the quality of their publications; in the case of DNSOP one of the
aspects of the solution is fairly obvious: require running code. This is
not an IETF-wide issue.

The IETF norm is to demonstrate interoperable independent
implementations, and if you'd like to argue there should be an exception
for the DNSOP working group, the onus is on you to take that discussion
to the IETF list.

> - in the specific case in the subject, there is funding available to
>   support final implementation of this idea on three code bases. This
>   won’t be released until we are past a successful last-call (because
>   that’s how it works) and so stalling this specific draft on behalf of
>   a way more general idea and discussion is actually having the opposite
>   effect of what the discussion’s goals are. It is delaying final
>   implementation.

You may be holding the argument upside down: not having implementations
delays having a high quality protocol specification, which delays RFC
publication, which (in the diffusion of innovations theory) delays the
early & late majority. When not even "innovators" and "early adaptors"
can get behind a given draft, that draft is already in trouble.

There is no need to _release_ said implementations to the public. The
implementers are right to not publish releases containing features that
have not yet been standardized.

A common approach is to have implementations sit on feature/beta
branches, so that you can demonstrate that there is interopability, to
have discussion about how to test & validate that the implementation
confirms to the protocol specification. Implementer feedback is crucial
in constructing a protocol specification. If there are zero
implementations of a concept a lot of the discussion about that concept
is merely theoretical.

This is not a chicken-egg situation. If someone believes this draft is
good and serves a purpose benefical to the Internet community, they will
attempt to implement the draft and during that development process
feedback is collected which the working group can consider to either
improver wording, remove non-essential parts, or re-architect the whole

Kind regards,