Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

"Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> Wed, 07 October 2020 08:46 UTC

Return-Path: <Thomas.Corte@knipp.de>
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 8E8363A16BF for <regext@ietfa.amsl.com>; Wed, 7 Oct 2020 01:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 iCaVOyiuYku4 for <regext@ietfa.amsl.com>; Wed, 7 Oct 2020 01:46:55 -0700 (PDT)
Received: from kmx5a.knipp.de (kmx5a.knipp.de [195.253.6.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C693A129E for <regext@ietf.org>; Wed, 7 Oct 2020 01:46:54 -0700 (PDT)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx5a.knipp.de (Postfix) with ESMTP id 4C5ny46hc1z4tyV for <regext@ietf.org>; Wed, 7 Oct 2020 10:46:52 +0200 (CEST)
Received: from dhcp203.intra.dtm.knipp.de (dhcp203.intra.dtm.knipp.de [195.253.2.203]) by hp9000.do.knipp.de (Postfix) with ESMTP id 88E367207B for <regext@ietf.org>; Wed, 7 Oct 2020 10:46:52 +0200 (MESZ)
To: regext@ietf.org
References: <A823DBB3-CF78-4FC2-8F3A-D1065A5331F2@verisign.com> <75e3564dff244013abb9de2cd7fed22e@verisign.com> <20201007011718.GA5771@tomh-laptop>
From: "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de>
Organization: Knipp Medien und Kommunikation GmbH
Message-ID: <e099761c-3650-472a-4a5a-d821dc9d1a4a@knipp.de>
Date: Wed, 7 Oct 2020 10:46:52 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <20201007011718.GA5771@tomh-laptop>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: /
X-Rspamd-Server: v1117
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:195.253.0.0/16, country:DE]; LOCAL_WL_IP(0.00)[195.253.2.54]
X-Rspamd-Queue-Id: 4C5ny46hc1z4tyV
Authentication-Results: kmx5a.knipp.de; none
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Y4ypypJ_hP7SfJW0byXlH5T-oLY>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 07 Oct 2020 08:46:58 -0000

Hello,

On 10/7/20 03:17, Tom Harrison wrote:

>>> The question is whether the RDAP protocol should provide guidance with
>>> how to handle overlapping non-unique handles.
>>
>> I don't think it should. A Jasdip pointed out, the definition of a
>> handle notes that they're supposed to be registry-unique.
> 
> I agree with Scott and Jasdip on this point.

I think it's problematic to have a standard like this (which will
eventually have to be implemented by all ICANN-regulated registries)
impose such a requirement (unique handles across all object types) out of
the blue when there are already hundreds of databases out there that were
not build with this assumption in mind.

Sure, a migration of non-unique handles is possible, and we did that when
ICANN demanded a specific ROID prefix per TLD, but that was a minor
change as the ROID isn't really used for operationally addressing
anything. Renaming contact IDs and/or registrar IDs would have more of an
impact, as it would also require all registrars to update their own
databases/configurations as well to reflect the new handles.

If "using a <handle> precedence order" means that a server can choose to
e.h. just deliver the contact when there's a registrar with the same
handle, that's an acceptably lenient interpretation. Otherwise, no
assumption about the uniqueness of entity handles should be made long
after the fact.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbH                    Thomas Corte
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                      E-Mail: Thomas.Corte@knipp.de
Germany