Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

Suzanne Woolf <suzworldwide@gmail.com> Thu, 09 July 2015 13:23 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5281A9080; Thu, 9 Jul 2015 06:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn2CUS8gWqqh; Thu, 9 Jul 2015 06:23:49 -0700 (PDT)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4128A1A9078; Thu, 9 Jul 2015 06:23:49 -0700 (PDT)
Received: by qgep37 with SMTP id p37so22878693qge.1; Thu, 09 Jul 2015 06:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xu0NZ6jOTkQ4W9ooOGC8B61Da37i0xNfr8Me8/Utr0U=; b=yQ6Kb+m2d93S7d/wyu/A+shDnT+SEeQdAJRACC67PT4eAgwWJZodXk5MxQOP13JQEY eFSltELfndj2PRVTq5FA73cJfK/HQD2945JVo/muKkmZHS5NV4QiXGPeBMXLyJ5zNVBy UL9tn/hN2F8w2pB7RTDhg5wbJMHI4mIqpkKX2ihBBBs2B+HRXm5tJeeOBbaI4C6b00mn +ZU19ORFVMDN/+MitvMRXJQEeh1PyiqYBI7Pl843gCIL0mUeg0pT4GjAJXgFqJP6Myg+ ng2vmEwgUARZDFAbrOezoybvoEK9NIBjTYl+yuUdFhrsA5TWOyQPQ2Ztsmq79YvUflWs Z0PA==
X-Received: by 10.140.128.206 with SMTP id 197mr25808758qha.23.1436448228443; Thu, 09 Jul 2015 06:23:48 -0700 (PDT)
Received: from ?IPv6:2601:181:c002:25ee:903c:9570:6e47:b69? ([2601:181:c002:25ee:903c:9570:6e47:b69]) by smtp.gmail.com with ESMTPSA id g6sm3631599qgd.10.2015.07.09.06.23.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jul 2015 06:23:47 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <20150709031114.GA78479@isc.org>
Date: Thu, 09 Jul 2015 09:23:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <16533673-B804-4F47-9427-3D2701E66344@gmail.com>
References: <20150708225400.20543.78092.idtracker@ietfa.amsl.com> <CAHw9_iJ9LPDhhdDby4QW6K354P7rEuxOjTbAVdSmd2td7AAJnw@mail.gmail.com> <20150709031114.GA78479@isc.org>
To: Evan Hunt <each@isc.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/C9usiz2EfANWWDul6v6yCzk6T3A>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, draft-ietf-dnsop-negative-trust-anchors.ad@ietf.org, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, dnsop <dnsop@ietf.org>, Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>, draft-ietf-dnsop-negative-trust-anchors.shepherd@ietf.org, draft-ietf-dnsop-negative-trust-anchors@ietf.org
Subject: Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2015 13:23:51 -0000

(No hats, and no strong feelings-- a minor point.)

On Jul 8, 2015, at 11:11 PM, Evan Hunt <each@isc.org> wrote:

> On Wed, Jul 08, 2015 at 09:50:09PM -0400, Warren Kumari wrote:
>> Less flippantly, it is in this email:
>> https://www.ietf.org/mail-archive/web/dnsop/current/msg13004.html  I
>> don't think that we have a really good motivation for a week, other
>> than that is feels sort of like a good, human scale timeframe to
>> recheck on things. We really want there to be a limit on the lifetime,
>> a week felt right...
> 
> Yep, that's pretty much it, right there.  A day isn't enough (we had
> feedback from customers to this effect) but anything longer than a week
> strikes me as much too likely to fall off operators' radar.  Though the
> limit is arbitrary, I do believe that we need to assert *some* limit,
> on this approximate time scale.

OK, so….vendor feedback from customers sounds like a motivation that's perfectly appropriate to document. "There's limited experience with what this value should be, but at least one large vendor has documented customer feedback suggesting that a week is reasonable based on expectations of how long failures take to fix or to be forgotten. Operational experience may further refine these expectations." 

Agreed that there MUST be an expiration set (Sec. 2) but MUST (or even MUST NOT) always seems weird to me on a specific value, especially given that there's a SHOULD in Sec. 2 about letting the operator set the duration. 

How about: "NTAs MUST expire automatically when their configured lifetime ends.  The lifetime SHOULD NOT exceed a week."

This allows for enforcement in code if Evan wants, without requiring it. :-)


Suzanne