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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 05 October 2020 16:03 UTC

Return-Path: <shollenbeck@verisign.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 765CC3A0DD1 for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 09:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 whlnof3m8tIp for <regext@ietfa.amsl.com>; Mon, 5 Oct 2020 09:03:42 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 F364D3A0DF6 for <regext@ietf.org>; Mon, 5 Oct 2020 09:03:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2324; q=dns/txt; s=VRSN; t=1601913822; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=Op4pt2USgOJg87EIOJnfgLb+//UdcerpEF45ZVTcWao=; b=LZ9Q10FH8NpCI50IDs5aJspUbVT3U2UiVsm0H5RbdY0/wNB/xsRC6zkt pBX/IvxMBM92h9rQpXY6/E+8jmOhk9thmO4qBhqOXWEPzGsqXwvZbaU2e EiWKVVzIO5PqYbo6eqoXHlZ0tAEuAcXovNOqaoF+/Dx4dgdDAdV1qmXcc Jv4zmSFw7aTAN0xvoxoDJJwx9G4J9T3RvPxMKtIgOCs9MkedBD3r3LRv+ saQ7aZ8gji2Tsgsu3VZptIxAUvaiEJso/9fY1NSlS0je87BzngnHOJ7Hq VE3BORvbcadMCdSwc5GqT/65mrxMkOPCjJr5kv8RXC0/xu2fsDgBjFDdc A==;
IronPort-SDR: 4DbadKNkRYSgC5Aa5Le4mq4UgIn2BS/w4AJv8IG/YgPL4MMslHiTi2gQ6KMD4GTzNYhM1Qtg2H pTrb7R1MSLHeS27fgdCAo/oVCxbBLUz6f7vPh/PVZGbzWcKhuxYnETdCBMw8vCQuiZcHSOEXJh 7CWBB9X7XovPu+vtSqVMOzyjlIMM5CxyByXZ0mfeNIJSM9szu2m2Y5H702LE2UPdjqlxvzr7iB TqBiHRMwB6aXiCvXUSxJrA/z2TUvQnoYWgVtuEjnf4So+k5q3cquFeiiMuUuszsyLdQYHyruhy ziE=
X-IronPort-AV: E=Sophos;i="5.77,338,1596499200"; d="scan'208";a="3259924"
IronPort-PHdr: =?us-ascii?q?9a23=3A48Z5GBX8w/yUXwGNluxh3jSJAXzV8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYZRaPvqdThVPEFb/W9+hDw7KP9fy5Bipcu93Q7DgrS99lb1?= =?us-ascii?q?c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUh?= =?us-ascii?q?rwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrrwjdrMYbjZVtJqs1xR?= =?us-ascii?q?bCv2dFdflRyW50P1yYggzy5t23/J5t8iRQv+wu+stdWqjkfKo2UKJVAi0+P2?= =?us-ascii?q?86+MPkux/DTRCS5nQHSWUZjgBIAwne4x7kWJr6rzb3ufB82CmeOs32UKw0VD?= =?us-ascii?q?G/5KplVBPklCEKPCMi/WrJlsJ/kr5UoBO5pxx+3YHUZp2VNOFjda/ZZN8WWH?= =?us-ascii?q?ZNUtpUWyFHH4iybZYAD/AZMOhYsYfzukcOoxW9CwmiBuzvyyNHiHD50qAhz+?= =?us-ascii?q?QuCgPG0BA8E94SsnnZqsj+OqcIUeCyyanF1TvPYfFR2Tf57IjHbBYhruqSUr?= =?us-ascii?q?1scsrd0VQkGR7ZgVWXtYzlIz2Z3fkKvmiA7+pgUuavi2o5pAF3uTeg2Nsjio?= =?us-ascii?q?rSi4IL1F/E7yR5wJ00Jd23Tk53e8KrEJxVtyyDMYZ9X8wtTX1ytikg1r0GpY?= =?us-ascii?q?C0fDIMyJk/yBDSd+CKf5WU7xzsSeudPDl1iW5qdb+9mxu/71SsxvD9W8Wq0F?= =?us-ascii?q?hHoSVLnsfOu3wQyRHe98eKRPt880qvxzuC1gbe4fxHL0AsjafXNoItzqQtmp?= =?us-ascii?q?cRv0nPBDL6lUX4gaOMeUgp+fCk5/n7brn8u5ORNZN4hhvjPqkhmcGzG/k0Pw?= =?us-ascii?q?sIUmOG4+qzzqfj8lf8QLhSi/02lbTWv47CKMQAo665HxdV0oE+6xajFzum0M?= =?us-ascii?q?oXnX0ALF9dZR+Jk5DnN0zOL/7gAvmwgkignCpxy/DYIrLhBY/NLmDZnLj7YL?= =?us-ascii?q?lx8VBcyBAozdBZ/Z5bFrYBIPfrVk/wstzXEAM5PhSpz+r7Etlxy4ETVGyVDq?= =?us-ascii?q?OEMK7fv0WE6+0sLuWUYY8aojf9K/wr5/70in85nEcQfbKp3ZsQbHC4GuppI0?= =?us-ascii?q?OCbnXyntgBEnwHvhQgQ+zwiV2CSj9TZ3m0X64m+j47D4emAZ/ZRo+xmLyBwD?= =?us-ascii?q?u7HppOa2BEEF+MCmrnd4ScW/cXcy+dONVhkj0CVbS7TY8uyw2uvhfgy7V7Nu?= =?us-ascii?q?rU5jEYtZX72dhw/eLTjxAy9TtuA8SZ1GGNQW90nnkWSDAr26Byuk19ylaf0a?= =?us-ascii?q?Rin/NYE8ZT6+lIUgcmLZTc1fB1C8juWgLdedeEUFmmTc+iATEvT9IxxcQDbF?= =?us-ascii?q?h5G9WjlRDDwyWrD6UJmLyMAZw+6rjc0GTpJ8Zh13bG07Esj0M4TctAK2Knib?= =?us-ascii?q?J/+hPSB4HXj0WZmbymdaMG3C7Cpy+/yj/Ek0ZFVAI0GYfMWH0ELAOCr9v++0?= =?us-ascii?q?fOZ6GjE7U8MwRHj8WFL/0OIpfrhE5KRe/4EN3EYmT3nWqsT17cxLqXYIvyYE?= =?us-ascii?q?0UxiTbTk4Jj1ZXtTyDPBI/AWGlpGzQFjFiEnruYl+q+u9k7nKnBAdgygiQbk?= =?us-ascii?q?on07279AQYifu0SvIPmLkComEgt2MwVByy1tbICtyoqg5gZ7lMJ9g65R0PgW?= =?us-ascii?q?3QsxJ8OLStK6F5mk5YeANy6QemnQ96BYhQjeAroW8kig1oJujQhElMeD6Iwb?= =?us-ascii?q?jxN6HZbG7o80b8RbTR3wSU8NGS/qoJ4vkzqBGrhwquClZouyF8095R13aa7J?= =?us-ascii?q?jBDyIMXIjwSUc48V5xoLSMMXp13J/dyXA5afr8iTTFwd98QbJ9khs=3D?=
X-IPAS-Result: =?us-ascii?q?A2HgAwAnQ3tf/zCZrQpgHgEBCxIMQIYdCoQzkTecJgsBA?= =?us-ascii?q?QEBAQEBAQEIAS8EAQGESgIXgiMmOBMCAwEBCwEBAQUBAQEBAQYDAQEBAoZRg?= =?us-ascii?q?jcpAYNqAQEBAQMjEVEEAgEIEQQBAQMCJgICAjAVCAgCBAESCK1zdoEyikSBD?= =?us-ascii?q?iqGW4JEhC2BQj6BEYMQPoQlgy+CYASQE4MmowqBCgMHgmePVosCK6EfkxSgF?= =?us-ascii?q?gIEAgQFAhWBa4F7cIM5UBcCDZwtATh0NwIGCgEBAwmNN4ERAQE?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 5 Oct 2020 12:03:40 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1979.003; Mon, 5 Oct 2020 12:03:40 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "Gould, James" <jgould@verisign.com>, "jasdips@arin.net" <jasdips@arin.net>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "galvin@elistx.com" <galvin@elistx.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Thread-Index: AQHWmy3vfeyhdS9JvkeXoVF1lYwy36mJK15w
Date: Mon, 5 Oct 2020 16:03:40 +0000
Message-ID: <75e3564dff244013abb9de2cd7fed22e@verisign.com>
References: <A823DBB3-CF78-4FC2-8F3A-D1065A5331F2@verisign.com>
In-Reply-To: <A823DBB3-CF78-4FC2-8F3A-D1065A5331F2@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Y43DYAcHsAPVNM98XQJChLVOESU>
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: Mon, 05 Oct 2020 16:03:43 -0000

> -----Original Message-----
> From: Gould, James <jgould@verisign.com>
> Sent: Monday, October 5, 2020 11:41 AM
> To: jasdips@arin.net; Hollenbeck, Scott <shollenbeck@verisign.com>om>;
> mario.loffredo@iit.cnr.it; galvin@elistx.com; regext@ietf.org
> Subject: Re: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-
> rfc7482bis
>
> >> The phrase 'registry-unique identifier' connotes a unique lookup key for
> entities, irrespective of their type. It puts the onus on a registry to ensure so.
> Does that not suffice?
>
> There are cases where the entity lookup key is not unique, since the RDAP
> entity object can support multiple independent registry objects (contact and
> registrar).  The recommended text provides guidance for this use case:
>
>   The <handle> parameter represents an entity (such as a contact,
>   registrant, or registrar) identifier whose syntax is specific to the
>   registration provider.  For example, for some DNRs, contact
>   identifiers are specified in [RFC5730] and [RFC5733], and registrar
>   identifiers are specified using the IANA Registrar ID assigned by
>   ICANN.  The server SHOULD define a scheme for the <handle> parameter
>   to differentiate between the supported entity object types (e.g.,
>   contact and registrar), such as using different <handle> formats,
>   using a <handle> precedence order, or a combination of formats and
>   precedence order.
>
> 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.

Scott