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

Warren Kumari <> Sat, 07 April 2018 02:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D17A5126E01 for <>; Fri, 6 Apr 2018 19:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 TbWxDtVpE1nl for <>; Fri, 6 Apr 2018 19:10:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2ED21267BB for <>; Fri, 6 Apr 2018 19:10:32 -0700 (PDT)
Received: by with SMTP id r131so6189258wmb.2 for <>; Fri, 06 Apr 2018 19:10:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dOAzxoyTuskEHUtwwVdwy0cWctcd0vJUYfq73q9FB1E=; b=O9XCkFQPeE98g/WXQaRAj6e8UEYrieqDHEI+XcVZhdRt0655fmkUGTNlovjrP/WCHA vLhxGiSq2RZ/IzKqMjlQerWJPbKeZXnC2aG2qOcMFpwSlSoo5GMCAYKkuEhnVbDw0yzZ o894ZUWHWhIVsHKYOgIxp9MkSXW/hTcWaQx9wgcVNm94FAh2BlshMWbF7pZO9Q5+rrIk WfrXyzWrXNhFGCaW4uvRRvj6J3O+DHlcwtp6O2juJCzy7wH+kITILwQTVjpSVM3fdBr/ aYKrFrYKlDOsqvKBfgqjiz6/hYpPZKpipv/QRJd0IdN1V0e+5Q4rfrbeCGgSbWvXrwvu nCyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dOAzxoyTuskEHUtwwVdwy0cWctcd0vJUYfq73q9FB1E=; b=k28HIHP314h+XNVpLJC7bXICSQ8gkIfg/84Vvk8njua+teo75tMii5Q6UOD/J7vNWS 8kW3QZ5kAy0XtwgY3CAv5LfeyvVfgpTVCMnqf3Cf/HArHu9C2oty4NJYaMYJq76bHVuw 7F9qaZzMmQ34DOknnUUkJNt5kGtKslmmXlEchSaiqTxQCB36tWsQvl6cfi4IgbUG+1yj lRzQYLCYtATDB4sLvG1rRHUaX/tfM65rbl8UcZoLy3NGKK05VfN1qK8MbcqK1J4wpkNu j7nzM4W37jpvdwK70+1Xh/XLMMrhkSudAWXJUNi9EQhBBi9qiTN6PEs8kyfHFCBQFY96 TSXA==
X-Gm-Message-State: ALQs6tDJ0+EaZ9ufMFeVfOBx46E9wzgi0oUdD91DjKF77arn++9CjBE4 ARE6eMBTSKnKnUALkwlJZkcoHo8/Bma4o6GUlFdtmJvq/2g=
X-Google-Smtp-Source: AIpwx4/2xHnPu3jqZY7FfYW4k3E+2Jja1hzwL2Q2jhlPshmuxLuIylmPcf6mz/6vcf+acYH10fR2y1FxXIJLjTMWhpY=
X-Received: by with SMTP id x13mr13684855wmc.71.1523067030764; Fri, 06 Apr 2018 19:10:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 6 Apr 2018 19:09:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Warren Kumari <>
Date: Fri, 6 Apr 2018 22:09:50 -0400
Message-ID: <>
To: Suzanne Woolf <>
Cc: Job Snijders <>, tjw ietf <>, dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Sat, 07 Apr 2018 02:10:36 -0000

On Fri, Apr 6, 2018 at 5:49 PM, Suzanne Woolf <> wrote:
> Hi,
> Thanks all for vigorous discussion, but I think it would be helpful to separate comments on draft-ietf-dnsop-kskroll-sentinel from general comments on WG guidelines for future documents.

Yup, I fully agree -- these have become conflated. (This drove the
irritated tone of my prior email.)

>> On Apr 6, 2018, at 9:45 AM, Job Snijders <> wrote:
>> On Fri, Apr 06, 2018 at 08:37:15AM -0400, Warren Kumari wrote:
>>> 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.
> The fact that we don’t have a rule about all documents doesn’t mean an issue can’t be raised about a specific document.

Yup, and they have been raised about this document.

> While it’s often disappointing to editors when the WG raises significant issues in WGLC, that’s kind of what WGLC is for.
> We’re hearing that having an RFC will be helpful to promoting implementation, and also that this draft may not be ready to be advanced for publication because it doesn’t include implementation experience.

Yeah, it is disappointing, but the authors are big boys and girls, and
after sobbing into our pillows for a little bit we'll be okay... :P

It seems to me that there is a fairly strong signal from the WG for
*this* document should have an implementation section -- speaking only
for myself, this seems like a reasonable request.

Again, for *this* document I understand that the WG wants an
implementation section, and so we should add one - I'm not sure we'd
be able to have that done by April 19th, and so I'm not sure if the
chairs want to consider pausing the WGLC.

> This is something the WG needs to comment on further, because it seems substantive to me so it will have to be addressed one way or another before we advance the document— but those inputs are somewhat in disagreement.
> Editors: Please take “concern about a description of current implementation status” as WGLC input, and consider what you might be able to add to the draft to address it.
> WG vendors/implementers: Can folks who have implemented kskroll-sentinel, or considered implementing it, please speak up on your concerns/plans?

Yup, that would be helpful  - bits I know of are that Knot has an
implementation based on an earlier version (with a different label),
and Petr says that it will be some time before they are able to update
it; I've never touched Lua, if I get a chance I might try patch their
implementation with the new strings ("Hold my beer" / "How hard can it
I think I heard that ISC was considering adding support, but was
planning on waiting till RFC / some sort of LC.

On the "other" side of this there are a few "client" implementations
-- the infamous, Ray Bellis has, and Paul Hoffman also has code
(which I have embarrassingly misplaced).

Once we have more details, these could be folded into the
implementation section...


> Thanks,
> Suzanne (&Tim)

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.