Re: [DNSOP] [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

Melinda Shore <> Fri, 15 February 2019 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85BF4130FF2 for <>; Fri, 15 Feb 2019 11:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cY8cfEK18VId for <>; Fri, 15 Feb 2019 11:47:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::544]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBD3B131004 for <>; Fri, 15 Feb 2019 11:47:28 -0800 (PST)
Received: by with SMTP id q206so5279100pgq.4 for <>; Fri, 15 Feb 2019 11:47:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z54FQAJNdCSUIrYq2YsY99KsIFBu5Cuxhv42fPIuKKY=; b=YgDe0EwfLjvp1hX57up2cr0j7hq3UbA+A713fPYzlL7YRm0IuIpQgv3MzDVsZU2GKR fFHvWNEpHRXy5CNLBR0rxJE1rve7yRWcYZtnT1kTt6Sqw+2kzEx5bBHd6n8mPMQYS2DT L+pYgS3dxEyHFWqcU6343iwjavVb1l/1aMWResuv3akj+FHFGMHoPnVenKUro4EJ1eaH BweUMzj89H3qNWCMwezfZlYHpXemOspa+Q5Ob4Ut46Xz6A3Aksyk5ojM9IKKDVtAgyBM Ii/14qAXv4paRQ4JUBJP28eKTweTuzIM7sqfN9Jo9i0zBg9oCqLrY/3/Vr+BaG+t7YdG sFug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z54FQAJNdCSUIrYq2YsY99KsIFBu5Cuxhv42fPIuKKY=; b=ToC45aHlZ8D8iOO3S0YApbOFWIfGGTFD33bDtFlYK2HGCW6NimcYE/rIbkvpyqzF8D P2jaNt7L9gnr0+7Rw3SB8H6OvnsG0fZoJMXP8Wh9klmVkYvWAn5rW+APcbzOivbYwp/S H5mPRL8AAfToAyLMJp/gCxLkCM7bQ2ylunHDrQx/TDOLvXbk3mIVetoXvR6qrZQljhZ6 y3FCheLwpH4hut6o5gCsJdDQ2eF484fHveGTfoPtSPlBqtlSLHpUauydsrc1W2bc6Vvr 9w+AKmqX5nLDTqXfrLSryuvCUYhar9C/+haUmaeaudeeC7oaPXNMwsEjlw1g99KK3oFI wLLw==
X-Gm-Message-State: AHQUAuaqV43j8jAd+TCQ8kOZjsEZ9vKm8CA99HGaR48pA6LrpdpPNaEa mE/lwZD5tajrLHHQR5AbT4Tb
X-Google-Smtp-Source: AHgI3Ia2LrvCoROuELnnvXrpITQGRY8Qs+IT1HjQdFp00fpp0vYXqAsR/5nOY0cc9xQ8AhMB86g/cg==
X-Received: by 2002:a63:b94c:: with SMTP id v12mr6839382pgo.221.1550260048170; Fri, 15 Feb 2019 11:47:28 -0800 (PST)
Received: from Melindas-MacBook-Pro.local ([]) by with ESMTPSA id p2sm8361866pfp.125.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Feb 2019 11:47:27 -0800 (PST)
To: Paul Wouters <>, Stephane Bortzmeyer <>
Cc: IETF DNSOP WG <>,, Alexander Mayrhofer <>
References: <> <> <> <>
From: Melinda Shore <>
Message-ID: <>
Date: Fri, 15 Feb 2019 10:47:26 -0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Feb 2019 19:47:32 -0000

On 2/15/19 9:46 AM, Paul Wouters wrote:
> This technically also allows one to separate the two DNS zones more
> clearly (and could even be managed by a different group)
> I'm really on the fence for this document. On the one hand, it is good
> to have a memorable decentralized identifier, but on the other hand if
> you rely on DNS (and DNSSEC), is this identifier really still
> decentralised in the "we don't trust the USG or Verisign" way ?

I think the question of whether or not to provide
decentralized identifiers and whether or not this proposal
delivers on the "decentralized" claim is out of our hands,
as the core spec (which has a lot of additional problems)
comes out of the W3C.  I think the IETF's involvement is
probably limited to their use of DNS in the resolution


p.s. and it's probably worth pointing out that this work is
being done in a W3C community group, so until it looks like
it's actually going to be published as a WC3 spec I'm not
sure I'd like to see IETF working group resources being
spent on this.

Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F