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

"Gould, James" <jgould@verisign.com> Mon, 21 September 2020 18:27 UTC

Return-Path: <jgould@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 50BF43A0B76 for <regext@ietfa.amsl.com>; Mon, 21 Sep 2020 11:27:35 -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 fliiyS97c0sx for <regext@ietfa.amsl.com>; Mon, 21 Sep 2020 11:27:33 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 779953A0B8B for <regext@ietf.org>; Mon, 21 Sep 2020 11:27:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4764; q=dns/txt; s=VRSN; t=1600712847; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=a99+vcX/XJS3SD73n1tquvILhJroCzXZpx9NfNY6b/c=; b=F8iz45/GPNY4I0HoYDFPs3Hl9kXyxQWsYWC/P9uIFoD3Yw1cDgKXsblf KsoJ4UOijDNSim73PJE2X56xEM3jQNcof2SDtxqsCEjtgEvc3yXmNmr5G Z/mNSMbeapkR5j8cxMVOdP1dBUnMKW/SXaPIsalpPoMgfeCg0rvFhO6j/ 63TOB2HX8Ck9S2hPaN2RKkviXSyGyCedzDMnLS4SaXEHUuSDFN6gHjQVG LnQR4KEnPtl5KnchCteJUGan9WePzbq91P5SqIZunCN+FxhO4xpdRxtW+ eGmUDFnPojsTnuLVE0BXf0X2Ov8yEHZ4dvBiKse2f3Y3v2zWMF7ZT8fvV A==;
IronPort-SDR: MCIrX3zwS2HzQbqstBXlLu+mYe00x95OJ3BwBjZqp3tET99qcJ8LnMErCSsuumIHBj/0tBP8qC arvHc/ky4Z59hTH9syEgFmkgecxowfI9S0GoJw1PeoMUswMAX2fswGCa2IZTOSCVP5KP2zUkDg WB2gucpnN1tOYrsouDz5XD0dfbiUCm/Z5v0r0PiBnaKupls/mLVWQnOkWAORWLEvSWljK2BW3b j+B33360hccZsuanxOaIuEqXw7rEaqbPJbQv2D8VEFJab9EH5vQK5qPGIUsZINBaVYgbCVgfa7 m8c=
X-IronPort-AV: E=Sophos;i="5.77,287,1596499200"; d="scan'208";a="3221397"
IronPort-PHdr: =?us-ascii?q?9a23=3AMH6vGBODSo24o1lAyPkl6mtUPXoX/o7sNwtQ0K?= =?us-ascii?q?IMzox0K/76r8bcNUDSrc9gkEXOFd2Cra4d1KyP6eu5ADNIoc7Y9ixbLtoUD1?= =?us-ascii?q?5NoP5VtjRoONSCB0z/IayiRA0BN+MGamVY+WqmO1NeAsf0ag6aiHSz6TkPBk?= =?us-ascii?q?e3blItdaz6FYHIksu4yf259YHNbAVUnjq9Zq55IAmroQnLucQanIlvJrwsxh?= =?us-ascii?q?fXrXdEZvlayGF1Ll6Xgxrw+9288ZF+/ylRof4t69JMXaDndKkkULJUCygrPX?= =?us-ascii?q?oo78PxrxnDSgWP5noYUmoIlxdDHhbI4hLnUJrvqyX2ruVy1jWUMs3wVrA0RC?= =?us-ascii?q?+t77x3Rx/yiScILCA2/WfKgcFtlq1boRahpxtiw47IZYyeKfRzcr/Bcd4cWG?= =?us-ascii?q?FMWNtaWS5cDYOmd4YBD/QPM/tEr4fzpFUOoxmxCgetBOzzxTFHiWT73bEh3O?= =?us-ascii?q?QkDQ3KwBYtEtAIvX/JrNv1LqASUeWtwaXGzDvDaO5W2TPg54TQbxsvpeuDXb?= =?us-ascii?q?dufsrKx0UkCgTIjlefqYziIjOV0vkCvnOF7+V+T+KvinUnqwB+ojip3Msjlo?= =?us-ascii?q?7JhocMx13C6C52z5o7K8eiR05nfd6rDoFQtyeCOoZyTM4vQX9ktSk6xLEbup?= =?us-ascii?q?O1cykHxpo7yxPCafGKd4uF7g/jWeuQLzp1i3xrdK+hihuz7UWtxOzxWtep3V?= =?us-ascii?q?pUriRIlMTHuH4K1xzW8MeHS/1981+/2TmRzQDT6/pEIUE7lardKp4hxKI/mo?= =?us-ascii?q?APvkTEGy/7nlj9gqyOdkg85+Sk9/7rbqjkq5KSLYN4lwHzP6o0lsGwBek0Kh?= =?us-ascii?q?UCU3SB9eih1rDv4Vf1TKhFg/A1iKXVrZPXKMIGraCjGQBVyJws6xOnAjej19?= =?us-ascii?q?QXgGcIIUpeeBKCk4jpI1bOIO3kDfung1SjjjNrx/feM7D8HpvDNmXPn7f5c7?= =?us-ascii?q?hy6kFQ1BQ/wcpB551IDbEBOurzVlXru9PFFBM5LRa0w/3hCNlnyoweXmePDr?= =?us-ascii?q?eYMKPUr1CI+voiL/SQaIMPpTrwKfYo6+TzgXI5l1IRZ6ak0J8PZHC9BPtmIk?= =?us-ascii?q?GZYXT2gtcGFGcHpgg+TOPtiF2fVT5cem2/X7wi6TEhCYKmFobDRo+rgLCbwC?= =?us-ascii?q?i7GZhWanhcCl+QCXfoa5mEW/AUZSKJIs9hlTgEVby/RI8nzh6hqhP1y7l/I+?= =?us-ascii?q?fb5iEYq4zs1MJ05+3IlBEy+jp0A96B3GGKSmF5hX4HRzos06BlvUNx0FaD3r?= =?us-ascii?q?Zkg/xWD9BT4OlJUggiP57G0+N6E8zyWh7GftqRSVapXMmmAT8qQ90rxd8Of0?= =?us-ascii?q?F9G9SkjhzZ2SqqB6cfl6aXC5ws7qLcw3/xKt5ny3nY26kukVYnQtdUOG2nmK?= =?us-ascii?q?F/6wbTC5TOk0WDmKb5PZgbiWTW9GCHyWeItkxTU1ssCbvIR3EEZ0TQ69/+42?= =?us-ascii?q?vOSra0AvImPxdPj8mYJeECPsbpilFCSfHpNd/dNj7phWqqBA2JybXKZ43vU2?= =?us-ascii?q?kY1T/WTkkJjw5V+myJY0x2TCasv2z2BTpyElPpJUXou6EqqX6nQGc9yR2Nbk?= =?us-ascii?q?sn0b7jvlZfn/GTRuMP9rMJpClnrC97Vh7pxd/ZBsqcjwtsYKsaZskytgRpz2?= =?us-ascii?q?Xc4kZSOYGkI+QqpFcbfh899xfs2BJqDoloj8UwrWgrwww0IqWdhgASPwiE1I?= =?us-ascii?q?z9b+WEYlL5+wqiPvbb?=
X-IPAS-Result: =?us-ascii?q?A2H8BABf72hf/zGZrQpcA4EJhGmBNAqEMJEaJoN6l2g9C?= =?us-ascii?q?wEBAQEBAQEBAQgBHxAEAQEChEkCF4IWJTgTAgMBAQsBAQEFAQEBAQEGAwEBA?= =?us-ascii?q?QKGRQyCNyJ7PQk9AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBBQIIB00HRwEeAQEBAQMjEVEEAgEIEQQBAQMCJgICAjAVCAgCBAESgyYBt?= =?us-ascii?q?xR2gTKKWIEOKoZahm2BQj6BEScMEIJNPoJcBIFFGAwLCiaCUDOCLQSQCYMmh?= =?us-ascii?q?yObVIEIAweCZ4h2hlKLBx6EM5xOknuIchKBXZUbAgQCBAUCFYFrgXtwFWUBg?= =?us-ascii?q?j4JRxcCDY4rF4NOilZ0AgwmAwIGAQkBAQMJjU6BEQEB?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) 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:27:23 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.1979.003; Mon, 21 Sep 2020 14:27:23 -0400
From: "Gould, James" <jgould@verisign.com>
To: "shollenbeck=40verisign.com@dmarc.ietf.org" <shollenbeck=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: AQHWkEFMbUvN4qNRfE2GtsOHsSqvUqlzaS+A
Date: Mon, 21 Sep 2020 18:27:23 +0000
Message-ID: <C368041A-5CF3-4EE6-9848-9E15F55D6945@verisign.com>
References: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl> <335D8D72-0A90-4E99-B21E-D5E991D61A96@verisign.com> <d10f32c645454c358f50e043e5ab508b@verisign.com>
In-Reply-To: <d10f32c645454c358f50e043e5ab508b@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.16.200509
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7C999A540661744BA8C120D8D0693C6A@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/d-zEXBI05ew68xf-LJokeipWzs4>
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:27:35 -0000

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.

-- 
 
JG



James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 9/21/20, 2:01 PM, "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org> wrote:

    > -----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