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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 21 September 2020 18:01 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 AF7FA3A08E2 for <regext@ietfa.amsl.com>; Mon, 21 Sep 2020 11:01:57 -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 MezIjhYsYqqR for <regext@ietfa.amsl.com>; Mon, 21 Sep 2020 11:01:53 -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 A782D3A0B23 for <regext@ietf.org>; Mon, 21 Sep 2020 11:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2332; q=dns/txt; s=VRSN; t=1600711314; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=RXNFy/DQmBNk4MC6iyJCefMEOsdx2wRS7RldTbg6goA=; b=C4nYKylkgYV8f7MGl0bOOmTnsAiA4GwAddgmPZT84a2mwKRWJr9idsvj UxYgMKh6ei7choEZlhvRVIoDKxpvDeqFN3fdU98OyOHopUq8rPKPjx/Q6 jGUCa4RlCKi+UBLUMEeiiHZilBmnBkYem2lVk2cYp/gbtoj7hkvPVUEC/ fiC/R1vfhvDKUGhBH8kEFBaxXw3ppmV+0rsa64eFqVzOy31QMPehPG6mQ pHjOWRgu2PetJOgYwzLCJH39rCb1o8qbyW1DCJfnZfz6kcxwAhNgnzB7E +0z42znPuGKJOZ7CoI85oNem9mhwtfvfFi6LkX+6vZ+N8nhvP2HVkS4+a g==;
IronPort-SDR: ZSAktAU8ML1OLUmUYq6hRarO+mDgfXU1t27AwH3weyzefqkA0r43GsgrjDbn1viyDwiz/aqF5s T5NCVexoYZi6kOjatpa/fd6yJ0yVgcnVsOnC6SfHUV1jb1RYfTg6v1OgwZfahnVKSzheVi++ct 3Zqp6B05yJKYEG98x8q9kh0VZqFWiJKBaEukWnD1By7V1rK/KDhlVScY2XMMjQvjVMJaPXNQWW wLSBRerZLtUqsgsQHSReiszH9GjQFjAdwYlKCEOLoa1p8eqgmrWtg6eSvWH+Q1CLY5TvzevaIL i+o=
X-IronPort-AV: E=Sophos;i="5.77,287,1596499200"; d="scan'208";a="3081570"
IronPort-PHdr: =?us-ascii?q?9a23=3Axs5HTRJgllmPyPW8dtmcpTZWNBhigK39O0sv0r?= =?us-ascii?q?FitYgXK/TzrarrMEGX3/hxlliBBdydt6sbzbOM+Pm5BiRAuc/H7ClcNsQUFl?= =?us-ascii?q?cssoY/p0QYGsmLCEn2frbBThcRO4B8bmJj5GyxKkNPGczzNBX4q3y26iMOSF?= =?us-ascii?q?2kbVImbuv6FZTPgMupyuu854PcYxlShDq6fLh+MAi6oR/eu8ULg4ZuMLs9xg?= =?us-ascii?q?XGrndVZuhbx35jKVaPkxrh/Mu984Nv/iVKt/4968JMVLjxcrglQ7BfEDkoKX?= =?us-ascii?q?0+6tfxtRnEQwuP538cXXsTnxFVHQXL7wz0U4novCfiueVzxCeVPcvtTbApQj?= =?us-ascii?q?ui9LtkSAXpiCgcKTE09nzch9Fqg6JapBKhoAF/w5LRbYqIOvdyYr/RcNUHTm?= =?us-ascii?q?dHQ81fVTFOApmkYoUPEeQPIPpYoYf+qVsArxS+BBWjCuzgxTJTmn/5xq863/?= =?us-ascii?q?g9HQ3a3gEtGc8FvnTOrNXyMacfSe65wqvPzTXHa/NZxzH955PWfR89ovGARa?= =?us-ascii?q?97f9fNxkkoCwPFklucopHiMjOO1uQNtGyb7+5+WuKpkGEotR1+oju0y8cylI?= =?us-ascii?q?bJnIMVykvF9SV2xoY5P8G3SEl+YdO9FpZbqi6VOZdsTMw4X2FopDg1yqcAuZ?= =?us-ascii?q?OjcyYH1IgqywPDZvKIboWE/xzuWfqeLDp6mH9oZq6ziwuz/ES+yuPxWca63E?= =?us-ascii?q?hIoyZYjNTBq38A2RzS58WJVPZw/0Gs0iuM2QDL8uxIPFw4mbDGJ5MjzLM8jI?= =?us-ascii?q?cfvETNEyPsl0j7j7eaelg49uSy9ujqYKnqqoWBO4J7iQzyKLkil8+5DO8lKA?= =?us-ascii?q?YBRXKb9v651LD7+E35R6hFgeMun6nCtZDaOdwbpqmkAw9Jyooj6wiwDzOh0N?= =?us-ascii?q?kAgHQJMEpLdA+HgIbxNF/BIez0Aeqlj1SyjDhrwOrGPqX7DprXM3fPiqnhfa?= =?us-ascii?q?xm605a0gY80ddf55dMBrEAJvL8RFPxucTFAhMlKQC43uTqBdtn2o8DWW+CDL?= =?us-ascii?q?WVPazRvFOQ4+IgOeiMZIsbuDbnLPgl4ubjjWQ5mV8aeamp2YUYaHajEft4P0?= =?us-ascii?q?qZYmHhgskfHmcQvwo+V+3qiFKEUTJJe3myWKc86ikhCI26FYfDWpytgLuZ0S?= =?us-ascii?q?e5EZ1WYX1GClSRHnrweIiIR+kMZzyIIs9giTwEVLehS4k72R6ysw/6zqFqIf?= =?us-ascii?q?fR+iICr5LsyMJ55+zNmhEu+zx4FcOd03uCT2tshGMHWyc23LxjoUx60lqD0L?= =?us-ascii?q?Z3g+BWFdFI/fxJVBs6NZndz+x8EdzyXAbBdM+TSFm6WtWmHS0xTtUpzt8UfU?= =?us-ascii?q?l9FMutjx/f3yexAr8aiaCLBJIu/qLbxXjxKJU193GTnqsuiEQiTp4TbXOrnK?= =?us-ascii?q?9k9gfVQYXOlm2Vkq+wfuId0TLDsmCZwiDG6ENXVxN0XfCZBW4SfErNrNv/oE?= =?us-ascii?q?jFSpeiDL09OU1AxNKMbKxQZYutxR9HSevtEN3Yf2WwnSG2AVzAkrKBcITCcm?= =?us-ascii?q?MB2yTbTk4AxURbt2yLOgUuGg+grn7QSjt0GhinN1nh/uRutFu6Q1M6iQaQYB?= =?us-ascii?q?sy+aCy/0tfpfuYT/4V1L8Pu2NpkD5zAEr3l4bNC92EowdndqhXYvsj7U1Gzm?= =?us-ascii?q?PWsUp2OZn2fPMqvUIXbwki5xCm7B5wEIgVycU=3D?=
X-IPAS-Result: =?us-ascii?q?A2GrAABJ6Whf/zCZrQpfHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?T4EAQELAYRNCoQwkUKcHwsBAQEBAQEBAQEIAS8EAQGESwIXghYlNwYOAgMBA?= =?us-ascii?q?QsBAQEFAQEBAQEGAwEBAQKGUYI3IoNyAQEBAQMjEVEEAgEIEQQBAQMCJgICA?= =?us-ascii?q?jAVCAgCBAESCLoPdoEyilWBDioBhlmGbYFCPoERgxA+hCUvgwCCYASQCYMmh?= =?us-ascii?q?yOcXAMHgmePSIp7KqEBknuffAIEAgQFAhWBaoF8cIM5UBcCDY4rF44kdDcCB?= =?us-ascii?q?gEJAQEDCY1OgREBAQ?=
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, 21 Sep 2020 14:01:51 -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, 21 Sep 2020 14:01:51 -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: AQHWkCsF4LOfBN4h4EiM1722M8Wvd6lzYRhQ
Date: Mon, 21 Sep 2020 18:01:51 +0000
Message-ID: <d10f32c645454c358f50e043e5ab508b@verisign.com>
References: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl> <335D8D72-0A90-4E99-B21E-D5E991D61A96@verisign.com>
In-Reply-To: <335D8D72-0A90-4E99-B21E-D5E991D61A96@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/TkdI3Fb6Pc_fpNh5rLQU80a5wf8>
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, 21 Sep 2020 18:01:58 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Gould, James
> Sent: Monday, September 21, 2020 11:22 AM
> To: ietf@antoin.nl; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> Upon review of draft-ietf-regext-rfc7482bis, I have the following feedback:
>
> Use of entity lookup for registrar objects was added, but there is no guidance
> related to handling entity lookups for different independent object types,
> where the object identifier and subsequently the <handle> may overlap.  An
> example is the ROID format for contacts “((\w|_){1,80}-\w{1,8}” is unique
> from the use of the IANA Registrar ID “\d+” for registrars but not unique
> from the registrar name (“fn element” in RFC 7483 with “\w+”).  The registrar
> name is a superset of the ROID, so a <handle> following the ROID format can
> take precedence as a contact object lookup instead of a registrar object
> lookup.  A <handle> is a unique for all RDAP objects except for the entity
> object that can be mapped to multiple distinct object types (contact and
> registrar).  Should the RFC cover the case of possible overlapping <handle>
> values for different types of entity objects, such as contact and registrar
> objects, where the server must define a unique <handle> scheme or define
> a <handle> precedence order?

Jim, RDAP doesn't have any notion of registrar entities that are somehow different from any other type of entity, so I'm not sure what, if anything, makes sense to say in the document. If you have a specific suggestion for text, it would be worth sharing to see what others think.

Scott