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

Suzanne Woolf <> Fri, 06 April 2018 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58DB31201F8 for <>; Fri, 6 Apr 2018 14:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 QgWjMwpKNoZs for <>; Fri, 6 Apr 2018 14:49:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 566351200B9 for <>; Fri, 6 Apr 2018 14:49:46 -0700 (PDT)
Received: by with SMTP id b198so2794375qkg.9 for <>; Fri, 06 Apr 2018 14:49:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sUOwlFqSAPX+rbYsfYVVAJF+5+nb5Am4UHnEM6FWw38=; b=uFst48MULRgmylwEbH4UOncpzdIzVOnByHbzkIhClTgraPEAnOm4Dte4SqU8yMYk2t 8cNexyUl0+WVtL2nEdo7H9k7e39LF+aDhK5fVlJ15SMIHootxBVj9QbcLydpjz3HdNg1 xV5PDE/otO9HVd96C9LKfKpV5YvhMQ2fDILQCNxoQZt4k5L4FC+RxlMtEIHS9aV1bjcT CtrSRfKrFlkD0wM2/zPGtJNKNNx+vsLlq/si1ecaQl5lfJ/rJl1OzNVWr6QnCg0BT0nK Ya7rMMaN7SPbp9IWy/9fls1XRN8Ji8CU7zrfpSJdR6QE6/WDaOVq+E9H6fdxAJK82F/Y p4GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sUOwlFqSAPX+rbYsfYVVAJF+5+nb5Am4UHnEM6FWw38=; b=PH0NWKTa/NOEYmQa8sZlQLQUrLV/6heg/zngKCNIbl/UGl11m76MW2/UVXEnDYhXu8 5Cuw64NiEYiY3DHDUIXPb9/v/FSOy+C+XX1FrkRUlOkULoFzWGEdTsjm7eHNgU++22kh Uh3vcGO88kL7+WVXp4xJJ0NjuZVF/3ijzjHefYDlW2YIMwKimrsRJytXwIuag+GkN474 v7Gc443ZcbcCWuOBkXuGeH0V5nimT1NR+AnLNuZuDscuToMQ3N7owmjolquEQImJ4cqK VSrilzr+TvM6vwubZxzNaUhaq8JIU7mQ+FiSIoEhkDfGfw09ZvHiq39dIBG7y2QDgJBK qnSg==
X-Gm-Message-State: ALQs6tBu1ReKrg9UQ49LvrIF+/mJRMroJbSoAVZH0bCgAFhiqaYr3ZIU Ilme9EXx9x2hOdmLc3CS5Cs=
X-Google-Smtp-Source: AIpwx49nNfDOXjlPT/sJ1T4kOVhRCwj7rywItGmAub+T3mdaY4jeLzhs5p3hiYLb2CELGOBAJ+3F/w==
X-Received: by with SMTP id o85mr37956304qkl.217.1523051385370; Fri, 06 Apr 2018 14:49:45 -0700 (PDT)
Received: from ?IPv6:2601:181:c300:3d20:bdab:3ffc:4df4:7f65? ([2601:181:c300:3d20:bdab:3ffc:4df4:7f65]) by with ESMTPSA id f14sm9429420qte.70.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 14:49:44 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Suzanne Woolf <>
In-Reply-To: <>
Date: Fri, 6 Apr 2018 17:49:42 -0400
Cc: Warren Kumari <>, tjw ietf <>, dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Job Snijders <>
X-Mailer: Apple Mail (2.3445.5.20)
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 21:49:48 -0000


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. 

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

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. 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?

Suzanne (&Tim)