Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

Job Snijders <> Fri, 06 April 2018 13:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 984C61270A3 for <>; Fri, 6 Apr 2018 06:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LR6XBb64S_z4 for <>; Fri, 6 Apr 2018 06:45:16 -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 796771201FA for <>; Fri, 6 Apr 2018 06:45:16 -0700 (PDT)
Received: by with SMTP id e79so1776953ioi.7 for <>; Fri, 06 Apr 2018 06:45:16 -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=kJapTu/ysompYLM09PtZA8oCntpmo+aMIP6Qganaqk4=; b=XmDFowP5eLTQj8Rhv4MGOCa14+sVXDn628n58VY+1vF7tHB8pAoS+6irsJdvEGbWM3 BOcGJS41Njj6TXedWZwCyoNmkeNFLSvB3lc7Uei7vX1cWCzmzAHYW+EOghfikObQTBBG 1cOMWR1sokrEkFjDb/9O2maz9n/pSjuH4r/McVqZ8E+tybaKK9mm54yfWUZI+IbgtQ+F S+1EeixFvxzb08Z9hpk7vTev/Ugn7w6rYKBXRllhtYsz1Jjg6HK+3jKmJxmMKh4VdEl7 XC8u4v+3+WpABoNkOP4XwdrIdQCxA4dgWGFVTpw7njxJm5N7Af6FYN92w2uf2KuwI5tR 8BHw==
X-Gm-Message-State: ALQs6tADnIbQ7tzaJP9u8YWQBSYNlJBp1p+q9lWt22yoXbidhITqaMLx 7BSyopCOO2dwXSvGIyYiIW3evA==
X-Google-Smtp-Source: AIpwx4+KC13iktlQn8tuCz8GzOqQ2MkCXwESwMjeYdFyRgBwn2xX/EQA4B5RslM3VM2jgm9oXq/aUg==
X-Received: by with SMTP id w99mr24947904ioe.13.1523022315422; Fri, 06 Apr 2018 06:45:15 -0700 (PDT)
Received: from ([]) by with ESMTPSA id e9sm6706280ioj.47.2018. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Apr 2018 06:45:14 -0700 (PDT)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id c7d168f3; Fri, 6 Apr 2018 13:45:01 +0000 (UTC)
Date: Fri, 6 Apr 2018 13:45:01 +0000
From: Job Snijders <>
To: Warren Kumari <>
Cc: tjw ietf <>, 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.4 (2018-02-28)
Archived-At: <>
Subject: Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
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: Fri, 06 Apr 2018 13:45:19 -0000

Dear Warren,

On Fri, Apr 06, 2018 at 08:37:15AM -0400, Warren Kumari wrote:
> On Thu, Apr 5, 2018 at 1:15 PM, Job Snijders <> wrote:
> > While the chair notes awareness of the point I raised, I’d like the
> > be explicit to avoid any confusion.
> >
> > This document is *not* ready for publication. There is no
> > implementation report available for review and consideration.
> [with absolutely no hats]

The authors of draft-ietf-dnsop-kskroll-sentinel (combined) have at
least 40 years of IETF experience. As such I'm not hesitant to hold them
to the highest standards. Cowboy hats notwithstanding. The protocol
specification will be better for it, and the working group will gain

> I get that you believe that this is wrong, but DNSOP currently has no
> requirement for there to be an implementation report (nor for there to
> be any implementations). 

The working group chair asked for feedback from the working group:

    tjw wrote:
    "Please review the draft and offer relevant comments.  If this does
    not seem appropriate please speak out. if someone feels the document
    is *not* ready for publication, please speak out with your reasons."

Naturally, I did what was asked of me.

> The way to change this is by proposing that this change (done), having
> the discussion (ongoing) and then having the chairs declare consensus
> and that they will require this going forward. It would also be useful
> for there to be clarity about what exactly is required, and for what
> sort of documents (e.g how does one implement attrleaf? or SUDN?), and
> when this would go into effect.

While you are right that it is useful to define what is required for
what sort of document, but I'd like to observe that at this moment, we
are looking at a draft with 0 (zero, null, nada) implementations*, and
also no implementation report draft which stipulates what should be
tested. So your specific question is perhaps somewhat moot. Whatever the
answer is, it will be larger than zero.

    [* Petr was kind enough to provide the working group with an update
    on the progress of a knot implementation, he shared that knot is not
    compatible with the draft-ietf-dnsop-kskroll-sentinel-07 specification ]

> A number of people have told me that they wait until something becomes
> an RFC before being willing implement it (some of this may be because
> a significant number of adopted document have simply expired and not
> been published) - suddenly requiring implementations is a large
> change, and deciding it now and retroactively applying it to documents
> which were about cooked seems a little unreasonable. 

"Documents which were about cooked" ?!?! Is this some kind of special
pre-WGLC status? Perhaps the word we are looking for is 'undercooked'? :-)

I have trouble following the line of thought here. Perhaps you can share
your thought on why IDR doesn't seem troubled by these concerns? Companies that
apply "Won't implement until RFC"-policies risk staying behind on the
innovation curve. That is their choice.

I've not seen any attempt to retroactively apply common sense without
following proper process. The process to obsolete/deprecate published
RFCs is well known, and if someone chooses to write a deprecation draft
where the main reason is "lack of implementations" they are free to do

IETF protocol specifications without implementations are worthless. The
IETF TOA lists the phrase "running code" five times. Section A.5 states:

    "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.)"

draft-ietf-dnsop-kskroll-sentinel-07 targets "Standards Track". The
current state of draft-ietf-dnsop-kskroll-sentinel and my understanding
of the IETF slogan "rough consensus and running code" are incompatible.

> I'd also note that this somewhat disenfranchises participants who a:
> don't code and / or b: don't work for a vendor.

I fail to see what disenfranchisement you are referring to. Can you
elaborate? You don't need to have code abilities to create a protocol
specifications, but you'll need to work with protocol implementers. I'd
like to keep the IETF process as inclusive as possible.

> I'm (of course) fine if the WG / chairs decide that DNSOP needs
> implementations before progressing documents, but your wording makes
> it sound like you believe this this is already the case, and not
> simply your (strong) preference.

I am aware DNSOP does not have a policy of requiring implementations,
and I find this lack of policy regrettable. I believe this document is
not ready for WGLC, for the reasons I listed.

Kind regards,