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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 24 September 2020 16:32 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 435C63A105A for <regext@ietfa.amsl.com>; Thu, 24 Sep 2020 09:32:09 -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=unavailable 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 E1eLQM2znWXI for <regext@ietfa.amsl.com>; Thu, 24 Sep 2020 09:32:07 -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 042EA3A1065 for <regext@ietf.org>; Thu, 24 Sep 2020 09:32:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2432; q=dns/txt; s=VRSN; t=1600965128; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=t4mO97WdtalFBLf0oVJpaGkeQ/tTNPY5zzoD/P1JsRs=; b=UPwiE3KiTMUTWQ8a5YbpNEsfk5qeciOhnM9D4bcen/QJ2gtFJcsfGHUF bYvVm3/uir5Z7aDsDyCtG097hMyOek41mQZIY28l3xE0SzoDmf3PvrOC7 sgeXvkg+hgqG0hAhsdAeGznI2fAbcrGclodjKVHEg+ROPOxkG7it+WFbd vWcsv8qFw9os8pZ1/C46TZV96ul0UcV19o3/xwdZFM9c6byb9XgsUrTUO Yvv5ValJ2YP+0etJ1R59ouvSc6TQ46v2Y1E10PaA6nGvA6vkCAU+ejSoR t/WoFAZYz1UBhzgH+MffGUZbAznxT9l1YvBkzi0E4mVmhQN3RctB0ZAtJ g==;
IronPort-SDR: pXZg+zkrmCq03465QsIpQA/OSUIlvNRVk/zi5F4BJBUPIYTn1ea0w4NXveLy4pdhYlr9dFbadX ARSTsrLz7deutFb7NbbioCvpUJ8ua9hXHSU7JzCTdWU6EoTAXX09UhFTQ9bjFg+6Ii7zT03rC7 7ZnGvYUEpFffv6DIe9PlhBpGNzAQtNdHnhVfXupSEamOJcUoel4s1vFt9YbaQ+tBuvEds4GdZ8 4M3uSEUHDtCvzHo+0mz6nM/Uy7RfokM6RS1+c03upI0ayllE8VU92Ym0XpQ16EZZLmQMoE/uXC pZs=
X-IronPort-AV: E=Sophos;i="5.77,298,1596499200"; d="scan'208";a="3122929"
IronPort-PHdr: =?us-ascii?q?9a23=3Azw+X8BE0R0qJWnWF/DpK651GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ76psizbnLW6fgltlLVR4KTs6sC17OJ9fmwEjxfqb+681k6OKRWUB?= =?us-ascii?q?EEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAA?= =?us-ascii?q?jwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba5wIRmssAnctcYajIhgJ60s1h?= =?us-ascii?q?bHv3xEdvhMy2h1P1yThRH85smx/J5n7Stdvu8q+tBDX6vnYak2VKRUAzs6PW?= =?us-ascii?q?874s3rrgTDQhCU5nQASGUWkwFHDBbD4RrnQ5r+qCr6tu562CmHIc37SK0/VD?= =?us-ascii?q?q+46t3ThLjlSEKPCM7/m7KkMx9lKJVrgy8qRxjzYDaY4+VO/h/fqzBct0VSn?= =?us-ascii?q?FMXtpKWCxDHo+wc5cDAugHMO1Fr4f9vVwOrR6mCAWiBu3vzTtIhnvo0q08yO?= =?us-ascii?q?suDx3J3A84E9kTrXrbsNL1NLsOUey70aLFyi7Db/NR2Tf57IjHbBYhruqSUr?= =?us-ascii?q?1scsrc0lcvGB3fjlWRsozlPjyV1uIXv2eH6OpgUPuihmg6oA5+vjah3N0jip?= =?us-ascii?q?XVho0L0FDE8z10zokpKNCkVUJ2fdGqHYZNuyyUK4Z7TcEvTn12tSom17ELuI?= =?us-ascii?q?C3cigFxZoo2RLSaeGLfpaV7x/sVOicIDl1iWxkdb+5mh288lCgx/XhWsWoyl?= =?us-ascii?q?pGsyhIn9fWunwQ1xHe5NKLR/R+80u5xDqDyxrf5vxGLEwoj6bXNpEsz70qmp?= =?us-ascii?q?YOsknOGDL9ll/sg6+MbEok//Cl6+HgYrr7uJCRL5R0igTiMqQ2ncy/HPg4Ph?= =?us-ascii?q?AOX2eF/eS806Xu8FDlTrtSk/E5krHXvp/bKsgHu6K1GRFV3Zok6xalFzeqys?= =?us-ascii?q?4XkmQdIFJbYhKHlI7pN0vSL/D/CPezm1WskDF1yPDaJrDtH4nBImLenLrjc7?= =?us-ascii?q?tx8VNQxQo9wNxF6J9ZCakNIPfpVU/wsNzYAAU5Mwuxw+v/E9V91oQeWWaLAq?= =?us-ascii?q?CHNqPdqkGH6f4sI+SXeo8apiz9K/k+5/7vgn85n0URcrWu3ZsScHy4BOhpI1?= =?us-ascii?q?2FYXrwhdcMCWUKvgU5TOz3jF2NTCZeanmuU6Ii+D47EoOmDZzCRoCihryNxj?= =?us-ascii?q?u0HppTZm1dF1+MFG3nd5+YVPsWaSKdPNNhkjIeWbimUY8h2gmktBXmxLp/Mu?= =?us-ascii?q?rU5ioYuIri1Ndr++3Tmwo/+iZyD8SB1GGNTmd0knkORz8yxKp/u1Byyk+f0a?= =?us-ascii?q?hkhPxVDcZT6O1GUggkOp/c0/d3C9HsVQLdcNeFUlGmQs+pAWJ5ctVkid0BZF?= =?us-ascii?q?t5F4D+1g7OxSuxArAT0beMAbQ496vG1D7wKtpzjXHc2+Np21spRdZLOTj63r?= =?us-ascii?q?By7QnIBoHP1U6eko6mcK0G12jM+XuNi22UsxccGERxXLnLdXkZekzXq5L/4g?= =?us-ascii?q?mKG76jFboPOw1dzs+EbK1OPJmhx09LS/rzJPzfbn6/3WCqClzAkqmBY4f6Z0?= =?us-ascii?q?0c0TnTTk8enFZA02yBMF10JiClp2/YBjFlFhanWEjr7fU04CegTkgwywyMZU?= =?us-ascii?q?Bq1JKr9wQUnv2TTbUY2bdS63RpkCl9AFvoh4GeMNGHvQc0JKg=3D?=
X-IPAS-Result: =?us-ascii?q?A2FTAADFyGxf/zCZrQpfHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?T0FAQELAYRNCoQykUKaJIF9CwEBAQEBAQEBAQgBLwQBAYRLAheCGSU2Bw4CA?= =?us-ascii?q?wEBCwEBAQUBAQEBAQYDAQEBAoZRgjcig3IBAQEBAyMRUQQCAQgRBAEBAwImA?= =?us-ascii?q?gICMBUICAIEARIIvGF2gTKKYoEOKgGGWoZugUI+gRGDED6CXASBRYMvgmAEk?= =?us-ascii?q?A2DJockm1eBCQMHgmePUIp8K6ENkwSgAwIEAgQFAhWBWwiCA3CDOVAXAg2OK?= =?us-ascii?q?xeOJHQCNQIGAQkBAQMJjmWBEQEB?=
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; Thu, 24 Sep 2020 12:32:05 -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; Thu, 24 Sep 2020 12:32:05 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "jgould=40verisign.com@dmarc.ietf.org" <jgould=40verisign.com@dmarc.ietf.org>, "ietf@antoin.nl" <ietf@antoin.nl>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Thread-Index: AQHWkETi85mKUvEe8UKJ/oRiQn20uKl3/6gw
Date: Thu, 24 Sep 2020 16:32:05 +0000
Message-ID: <e770a58145ec4c84b0dd769ef86cfe5d@verisign.com>
References: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl> <335D8D72-0A90-4E99-B21E-D5E991D61A96@verisign.com> <d10f32c645454c358f50e043e5ab508b@verisign.com> <C368041A-5CF3-4EE6-9848-9E15F55D6945@verisign.com>
In-Reply-To: <C368041A-5CF3-4EE6-9848-9E15F55D6945@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/_Z6jE64bkCz_H2q5ANlD04oYBu8>
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: Thu, 24 Sep 2020 16:32:09 -0000

> -----Original Message-----
> From: Gould, James <jgould=40verisign.com@dmarc.ietf.org>
> Sent: Monday, September 21, 2020 2:27 PM
> To: Hollenbeck, Scott <shollenbeck@verisign.com>om>; ietf@antoin.nl;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> Scott,
>
> Yes, lumping the registrar object with the contact object under a single RDAP
> entity object interface is the rub.  We solved the problem in the RDAP
> Profile, by supporting entity lookup by IANA ID (number) and registrar name
> (string) for the registrar objects, and by ROID (“((\w|_){1,80}-\w{1,8}") for
> the contact objects.  Where there is overlap, which is registrar name (string)
> and ROID ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My
> recommendation is to provide guidance in the section 3.1.5 "Entity Path
> Segment Specification" for this real world 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 SHOULD could be a MUST, but the point is to provide guidance to
> implementers of the protocol.

I'd like to see some discussion of this suggestion, too. What do people think? Is it necessary?

Scott