Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

Wes Hardaker <wjhns1@hardakers.net> Fri, 08 July 2016 21:26 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A36C12D196; Fri, 8 Jul 2016 14:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jR2bSrwMSeoU; Fri, 8 Jul 2016 14:26:47 -0700 (PDT)
Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79F812D1DD; Fri, 8 Jul 2016 14:26:43 -0700 (PDT)
Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id C081622737; Fri, 8 Jul 2016 14:26:41 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Ben Campbell <ben@nostrum.com>
References: <20160706222617.26800.68512.idtracker@ietfa.amsl.com>
Date: Fri, 08 Jul 2016 14:26:39 -0700
In-Reply-To: <20160706222617.26800.68512.idtracker@ietfa.amsl.com> (Ben Campbell's message of "Wed, 06 Jul 2016 15:26:17 -0700")
Message-ID: <0lfurjyg6o.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TjlabN0jHTE1UQU8AZl6qVGjkdI>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org, dnsop-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 08 Jul 2016 21:26:49 -0000

"Ben Campbell" <ben@nostrum.com> writes:

> - I support Terry's discuss.

Fixed (see response to Terry)

> - 1.2, 2nd paragraph: Is "full non-support" effectively different from
> "non-support" in this context?

CHanged to "Detecting complete lack of support", which I hope works for you?

> Do we have reason to expect the github project to be maintained for the
> life of the RFC?

I wondered about including such a URL.  I doubt github or olafur will
ever drop the repository, however.

> - 3.1.1 et. al. : Do we have reason to believe the dnssec-tools.org
> domain will be maintained for the life of the RFC?

I think for some of the tests we may be able to use the root of the DNS
instead.  However, in some cases we need specific data types.

I have no intention of ever dropping the signing of dnssec-tools.org,
and my co-workers have backup responsibility for it and the means to
sign it should I get thrown in jail by the protocol police, eg.

> The first paragraph seems to say that the document does not accomplish
> it’s goal. Is that really the intent? (And doesn't the document at least
> do some of that?)

I'll get back to you after discussing that sentence with its author.

> "... we can determine what MUST be done in order..."
> Spurious 2119 MUST

Agreed, fixed.

> "short-circuit any unnecessary fallback attempts.":  Does "short circuit"
> mean the same as "avoid" in this context?

Good wording replacement; done.

> "problems with the name server MAY manifest": Spurious 2119 "MAY"

Yep, fixed (someone else caught it too).

> - 5.1, "It MAY be possible...": Spurious 2119 "MAY"

Fixed.

> -5.1.2: s/real/really

Good catch.

> - 6: "A newly established network connection MAY change state...":
> Spurious 2119 "MAY"

Yep.

> -8: Seems like there could be  more to say about the potential
> consequences about the “fail or proceed without security” decision in 6
> and 6.1.

I think the world is very much at a loss as to the best thing to do in
that case.  And is likely very case specific.  Military installations
tend to be a bit more strict about continuing through to a unacceptable
security certificate, eg.  I'm not sure we can enumerate every context,
but rather say each local policy will need to do what is appropriate for them.

-- 
Wes Hardaker
Parsons