Re: [regext] WGLC: draft-ietf-regext-org-02

Patrick Mevzek <pm@dotandco.com> Thu, 24 May 2018 05:37 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A8120727 for <regext@ietfa.amsl.com>; Wed, 23 May 2018 22:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_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=dotandco.com header.b=qEsDLyV+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KoVaTt8N
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 d43SjuVZDgB3 for <regext@ietfa.amsl.com>; Wed, 23 May 2018 22:37:53 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5531200E5 for <regext@ietf.org>; Wed, 23 May 2018 22:37:53 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E80D621C5A for <regext@ietf.org>; Thu, 24 May 2018 01:37:52 -0400 (EDT)
Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Thu, 24 May 2018 01:37:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=gh6KPdf/W4TNlEIiqX4hIVrWmRL/N joYyRar/8e1A2w=; b=qEsDLyV+F6lFkIGce2mjsqQUumQ9NJ+KLWat7Ay4MSNB6 Y23+meLeko9f7gHrE2G7N8tnUxyJtYJHZxy8ECPxGbhxl3vb6RJ6hzE9DL5e/LjM CxhTuxujDVtk7WodhIkRwCqWUvR2Cz7chKYvZ+B/0MJj2PzfYLO7zUvR9rLlGQd2 9NdTOYhQVTEusx8OZY7ub2G09pLF2bopzLV+RBPrsZP3AIIrTNQrnoI8obDL44h4 zAaI0X6oLawN+dNQsXlRagxNdfbKM7Jsxhtu4iKMu3xMS5S704Wi1ayPvi4VECcv Vq8/aIr72Ve1AU5I+GyRas/HGrPFyWOOWx9j6LE8Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gh6KPd f/W4TNlEIiqX4hIVrWmRL/NjoYyRar/8e1A2w=; b=KoVaTt8NT+cC4YKaf71atE tLSWk/CxES7d6GsiJniXaxhDZ9BG05Sc/ECOFLz6SdCx9fyLGqQ+DdvTk0ocTnzZ KEo4xFJBUKml1xgKQanyoazRHMjZIYW89bVS4zOVKcDxxrFPTaIAiS7JKf6NvK6c JRL4qLsFX1S5hd7Mj4sl7++qU4WY7xWd+d6JXMbTvOQCsKYb9jsVUlL9i9XjY1n4 TK7qVPEuW4GF8KJiq6z1LySK3pnNqsfqocQSGVafx/BdrwsKT8psi90gi3lpcjIy rBPOSSETnMH+ru6K022dwXcqhaTzMx19kG7O7EylzhcAryeDQB1/nxkk3Mp/cKUg ==
X-ME-Proxy: <xmx:sE8GW3B1nrJAlrTmqsZ45ZKumSPoE0ZCkIfIy4osvTq2iW-r4XVMmg>
X-ME-Proxy: <xmx:sE8GW0-YDIBWNe6nkCiiD12WdLcZdZq1JNKdwHrchiEH0YjUaujIsQ>
X-ME-Proxy: <xmx:sE8GW__bhfVMMHm7zWEH4zugo7QRdy0PIiNN_8fB2yN7mVffu-Qr-A>
X-ME-Proxy: <xmx:sE8GWzdJhKcQxbyZ_h1DBoMPrPwuohmsxWtbqO8VYkpc6YDn2HNrsA>
X-ME-Proxy: <xmx:sE8GWwESMMgEeIVq4LyqEUaM-cyojIXmSdVR39wjZ8xVAlKgSk97vQ>
X-ME-Proxy: <xmx:sE8GW6VRcSubeYpqmFtIsKcQpYYw2elZL6fvWYCt6KHkz3DMOy9DjA>
X-ME-Sender: <xms:sE8GWxOF9NkQmsQT9Jku0V1bDiUZ95ukmRq5KhlvUZ_yBNMy8xvHqSmGwCA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id A80D19E196; Thu, 24 May 2018 01:37:52 -0400 (EDT)
Message-Id: <1527140272.2865446.1382983760.6F139993@webmail.messagingengine.com>
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-a224ff37
References: <80ED56C6-75F7-4DED-927B-E0AB528A71EE@elistx.com> <656C123C-9ECF-434D-948D-4E704ED3E75C@elistx.com> <1526872740.790268.1378875200.662ECDF2@webmail.messagingengine.com> <A9E94F6D-1C51-47C4-B74D-22D40841317C@dnsbelgium.be> <B0F071B4-DF2D-4E46-9002-C7FFAA5DAC25@dnsbelgium.be> <D349683C-99D6-49F4-B1C3-83C4A0B1790C@verisign.com>
Date: Thu, 24 May 2018 07:37:52 +0200
In-Reply-To: <D349683C-99D6-49F4-B1C3-83C4A0B1790C@verisign.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/WmGdr9LRWcyFHMCva3gg69-DO5c>
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 05:37:55 -0000

On Wed, May 23, 2018, at 14:05, Gould, James wrote:
> I would like to understand the concern around the use of the roles.  
> There are cases where an organization can play multiple roles 
> (registrar, privacy proxy, dns provider, etc.) that helps defined what 
> kind of links can be made to it.

Just an example (I do not wish really to revive the discussion) among others:
Imagine a registrar A for registry B, typically a ccTLD.
Registrar A creates an organization O in this registry B
It happens that O is a dns provider, let us say.
So it is created with this role.

Later O becomes ICANN accredited, for example. This is another role.

What totally escapes me: why shoud this be reflected in any way, through registrar A in registry B because O is provisioned there?

In short my main problem, and why I can not support this, is that I do not see the use case, besides for one registry that needs it to handle resellers, I doubt having seen another registry saying it will use it, so we are just paving the way to enable storing more data, where the world goes instead towards storing less or more carefully (see the current dramas around GDPR)

Not everythint that can be done should be done. This is the main point I will try to address in a separate email since it is a generic issue, not specifically related to this proposal.

-- 
  Patrick Mevzek