Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 14 July 2016 02:57 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 83C9112D625; Wed, 13 Jul 2016 19:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jVLOi4SDMkvp; Wed, 13 Jul 2016 19:57:23 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 7F3B412DA71; Wed, 13 Jul 2016 19:57:22 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id j17so62004444ywg.0; Wed, 13 Jul 2016 19:57:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GBOxhbsCREmrx5YWqSs2gZ83P0DMkZUnGBVxouaCsxQ=; b=sf6YnoQ7XnKfEfGYizv8vjC6fLp1DkOSBy/b5xl7dK5tlzW096QDkQqk00maVdO3wa /kI0kTtLskz+2DIOGsc91pOi3BBFWNe/rP7JWgodb33G/dscSEqNpBD831a0l8zwYsB4 2hvm1U7KMF/yvN9gjgocof9+3j54E77Dy9/bBeoE9b80qfRAYfRQr/GaTuAscE6f8wRh WfaGWdi4vzR+n++yeA7rajJ52w7dGKeU8YckZv6ktkpetWUvan2tJVE0d7mKSmWSQpnT 0IFWrazO/6e2aveIoVgGlFHuEVcJPkL7mkyZykk8DXOLa8WUeQMbla24HKVdQhic695G N+Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GBOxhbsCREmrx5YWqSs2gZ83P0DMkZUnGBVxouaCsxQ=; b=MIirhTd9l6Gf5PqV5w0wn8s8DbSxZfw+PgRgoD+xI3CWfvHVcqjj0Ln7RT9LzwkPcW u1/V78LZ5nxS/SvDpv4AUf+i02DTFhAM4l1VLVImGKQq0UjOAMRvdhkMSfTelv6SlDS1 ejzMpMk2Q74kdrMXP4sXOAYptwjbJRAcwkeT97DSCsj0kPAfqIoOKiHFJZ3RcPeZezgJ dl84hcG3zUZsQSK5qG34zslwA0JsHEA4+c1Umjdf3fKY/6iFsWnpm3mrpyN0NMa2y0PG Eu1Uqvnx5ZYyNcfpm1C+AU4gIceNw2q2LDY7h5FmbjB7223/f4gjpsQRlMJM3UUVUMj1 qc1g==
X-Gm-Message-State: ALyK8tKmw/RCozuhHxgrnQn05SeaVTcdpUXRk9uJSFwb1/Clf8j6qqlu+/1LgSICvbtF2Zq3NunMn+GSs5tdEQ==
X-Received: by 10.37.230.202 with SMTP id d193mr8069046ybh.111.1468465041815; Wed, 13 Jul 2016 19:57:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.231.82 with HTTP; Wed, 13 Jul 2016 19:57:21 -0700 (PDT)
In-Reply-To: <D3AC09DC.95840%terry.manderson@icann.org>
References: <20160706042557.22326.91200.idtracker@ietfa.amsl.com> <0ly45bsn4e.fsf@wjh.hardakers.net> <D3AC09DC.95840%terry.manderson@icann.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 13 Jul 2016 21:57:21 -0500
Message-ID: <CAKKJt-dWcaxmwSi9ANDX+wf6+Q16Q-7U8S9T3XamvPzQP1Fy4A@mail.gmail.com>
To: Terry Manderson <terry.manderson@icann.org>
Content-Type: multipart/alternative; boundary="94eb2c0afb0e2ec60605378fa9f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/y8-CD6J5vTAl47pi0-e4a831HLc>
Cc: "tjw.ietf@gmail.com" <tjw.ietf@gmail.com>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, Wes Hardaker <wjhns1@hardakers.net>, "dnsop@ietf.org" <dnsop@ietf.org>, "draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org" <draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and 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: Thu, 14 Jul 2016 02:57:25 -0000

This is Not My Yes, but ...

On Wed, Jul 13, 2016 at 12:28 AM, Terry Manderson <terry.manderson@icann.org
> wrote:

> Hi Wes,
>
> Thanks for responding.
>
> I'll trim to only the the remaining items needing a response, and express
> my appreciation at the clarified items.
>
> On 9/07/2016, 9:53 AM, "iesg on behalf of Wes Hardaker"
> <iesg-bounces@ietf.org on behalf of wjhns1@hardakers.net> wrote:
>
> >"Terry Manderson" <terry.manderson@icann.org> writes:
> >
> >
> >> s1.2 is https://github.com/ogud/DNSSEC_ALG_Check going to be a fully
> >> stable URL?
> >
> >Per discussion in another thread: probably.  Olafur certainly won't
> >delete it as the owner, and I doubt github will die anytime soon.
> >
> >The only other choice is to remove the helpful reference.
>
> Thanks.
>
> >
> >I've changed it to "validating resolver daemon" instead.  Make more sense?
>
> It does.
>
>
> >
> >> s3.1.1, please use the example domain for such examples, ie example.com
> ,
> >> and once you have used it do you really need to repeat it for each
> >> 'existing' text until you get to the non-existent tests and so on up to
> >> 3.1.14.
> >
> >Well, here's the deal: example.com won't work and the domain in question
> >actually does work.  Some of them can probably be replaced with the root
> >server, but many others require somewhat specialized tests pointing to a
> >special domain.  That one is known to be the only one that likely will
> >work for some tests at this point.  The question is, what to do about
> >that?  Can we list a known one?  Must we list a useless one instead?
> >Should we pre-declare the problem?  I've been waiting for this to come
> >up :-)
>
> Personally, my advice would be to pre-decalre the issue, and why it's an
> issue and why some special domain is needed and describe the semantics of
> the FQDNs needed for the appropriate tests (including an appendix zone
> file?), and then use example.com as the label which needs to be
> substituted by the person constructing the tests/zone. The benefit here is
> that some folks might like to replicate such a construct in their own
> infrastructure, and this document might give them that guidance.
>
> Does that make sense?


Terry, I like where you're headed, but just to ask the obvious question,
are you thinking the draft would, or would not, also contain something like
"at the time this document was approved, a domain used for this test was $
someactualworkingdomain.com"?

I didn't mention the domains mentioned in this draft in my ballot, but I
was watching when you brought it up ... so I'm still curious.

Thanks,

Spencer


> Thanks
> Terry
>