Re: [HR-rt] [regext] Human Rights Review of draft-ietf-regext-verificationcode

Peter Koch <pk@DENIC.DE> Fri, 05 October 2018 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84F7D130E69; Fri, 5 Oct 2018 03:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 sSEYIIt9ymzt; Fri, 5 Oct 2018 03:49:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04024130E51; Fri, 5 Oct 2018 03:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 76C60196; Fri, 5 Oct 2018 12:48:57 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 76C60196
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1538736570; bh=8TNPRMD9QTrFEJTP0bX6QXQ+rdWdp+fGLW4fMLt11O4=; h=Date:From:To:Cc:Subject:Message-ID:Sender:From:Sender:To:CC: Subject:Message-Id:Date; b=a6M+hiQD1hVWdftZQ6A5+r9BCC8WeS6pNiveM60zVJA5vMzmqGdZ3+t/6qqEryUoJ /eBLtXdQecPhBERpapq5F4snQHITDVOMQdN0vPRt2UNAjjJl4SqKPmVhgpyfH6yDZt No9Rxw53g7dxuavyzbXX1hWCUY2kdResFG6zjCzQRxHdWWHbXxseqHUP44xLcrBrZs moPGtNMByUQUhPLNcYolUiKZQjECn2OaUpFjy8PfmkpIJuKxPIWfaeQJcEJGtrRP6C +LE5keHea+hdZsFjRkYZAtvg+yVhoODylcwQM6Rl9pcvRItgavOwQpXRhmadrgD11d 3yKpM6hZC7Jfg==
Date: Fri, 5 Oct 2018 12:48:57 +0200
From: Peter Koch <pk@DENIC.DE>
To: "Hollenbeck, Scott" <>
Cc: "''" <>, "''" <>, "''" <>, "''" <>, "''" <>, "''" <>
Message-ID: <>
Mail-Followup-To: "Hollenbeck, Scott" <>, "''" <>, "''" <>, "''" <>, "''" <>, "''" <>, "''" <>
References: <> <20181003134215.GA23633@mir> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: Peter Koch <>
Archived-At: <>
Subject: Re: [HR-rt] [regext] Human Rights Review of draft-ietf-regext-verificationcode
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Human Rights Protocol Considerations Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Oct 2018 10:49:42 -0000

Scott, all,

On Thu, Oct 04, 2018 at 12:26:25PM +0000, Hollenbeck, Scott wrote:

> > context of technical issues with the draft.  The registration of domain
> > names in some jurisdictions may be subject to various requirements that
> > involve verification by a party other than the registry.
> >
> > Could you please be so kind to link to some of these legal requirements?
> There are several examples of registry operators that require verification as part of their domain registration process. Here are a few ccTLD examples:

while in fact we do have some requirements - as laid out in this FAQ snippet,
none of those involve third party validation, let alone at registration time.


> Any one of these registries could use the verification code approach if it were available.

Technically speaking, we do not use EPP, so we cannot serve as an example.
Conceptually, since no ex-ante validation is involved, this extension would
not be of interest for us.

> In addition, Section 3.7.2 of the 2013 ICANN Registrar Accreditation Agreement (RAA) says, "Registrar shall abide by applicable laws and governmental regulations".

I'm not sure how this would help make the case. It doesn't need ICANN nor
the RAA to bind registrars to applicable law and regulation. In the opposite
direction, I don't think that each and every "local" requirement
(automatically) has to result in a standardized extension.

I do think, though, that this WG - and the IESG - might want to be extra
careful regarding the boundaries between protocol and policy.