IETF Logo Mail Archive

Re: [DNSOP] .arpa

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 23 March 2017 16:32 UTC

Return-Path: <ajs@anvilwalrusden.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 937611299A1 for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 09:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=l7wSxssm; dkim=pass (1024-bit key) header.d=yitter.info header.b=OsRw3SQZ
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 82Lbt-vTeUXf for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 09:32:42 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3E8129869 for <dnsop@ietf.org>; Thu, 23 Mar 2017 09:32:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 0C064BB82E for <dnsop@ietf.org>; Thu, 23 Mar 2017 16:32:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1490286729; bh=MPB08fGp9eImqdnpwpHmYGibbvQOT4t5qV88rMmiXXQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=l7wSxssmmBhPIDnMElVjNyG7uRVcwBat3YsFukbbgbk3nl4vr+2vG0QtqHc50rQ5M Bsl2cj1/9luhjx2FcgvzQVvU8YkW91C4fXtGBGRTgeV7UDKtWcQa5qpy9FDUVYd8+H FhP5w8L/N/pl6YO4fGfEvIn2iKVxZP5eEJTSQwwA=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFWL1IipU4rK for <dnsop@ietf.org>; Thu, 23 Mar 2017 16:32:07 +0000 (UTC)
Date: Thu, 23 Mar 2017 12:32:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1490286727; bh=MPB08fGp9eImqdnpwpHmYGibbvQOT4t5qV88rMmiXXQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=OsRw3SQZHA8sao8qufpyVHXjOm4G9PW/69VLhLGDb4EkhkMRCy5wEz4sEcN77VYoW jZEX8SzF6w4oC1JrfOEbXTmeedtFHBYvV1OUkqaTaJps5niSvU4PTTooewTp9qMEkV 01nr4Ip1d2zPO+F5aPkmwYQwiz2PyZwZ4FllScPk=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20170323163205.GD19105@mx4.yitter.info>
References: <20170323042741.79108.qmail@ary.lan> <2C6B4EB6-D0F0-44A8-95E4-68DF32244639@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2C6B4EB6-D0F0-44A8-95E4-68DF32244639@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oN4kpsyGS1w-4eEV_DnpOkZVO60>
Subject: Re: [DNSOP] .arpa
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 23 Mar 2017 16:32:43 -0000

Hi,

On Thu, Mar 23, 2017 at 08:34:14AM -0400, Ted Lemon wrote:
> 
> The working group is aware of the "wait many years" part of this approach, and is willing to try and see.   If the working group sees no progress over the course of the next few years, we may shift to the latter approach.
> 

As a comment on the document, then (that is what we're discussing,
right?), I'd note that the plan for allocation of a special-use name
contained in the draft does not state clearly (at least in my reading)
whether it is conditional on receiving the relevant unsigned
delegation.  If it _is_ so dependent, then that would be important to
know.  If it is _not_ so dependent, then probably some additional text
is needed (maybe in the security considerations) about the likely
failure of DNSSEC or resolution in such a context.

I hope that's helpful,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

v2.23.0 | Report a Bug | By Email