Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

"Gould, James" <jgould@verisign.com> Tue, 26 April 2022 12:17 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 1A34DC070467 for <regext@ietfa.amsl.com>; Tue, 26 Apr 2022 05:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level:
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxF-8AF3zO4J for <regext@ietfa.amsl.com>; Tue, 26 Apr 2022 05:17:20 -0700 (PDT)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.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 AC124C070469 for <regext@ietf.org>; Tue, 26 Apr 2022 05:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=32664; q=dns/txt; s=VRSN; t=1650975435; h=from:to:subject:date:message-id:mime-version; bh=KZawjH5mYjF7XkhIQ945rHjjKj38CsnaMKZZEIoIEpo=; b=XbETIqVPXMWF3C3u2BUYZFiRMoU/cRhs8dHAoeLWOWCsX5EIYodXEG8V Mta/faOjJ6OaUpETd98fDLEiZ8kW5AfPaaJn/1KwYlvN95+tn/bP2a19g 0BE8LwepqSrpnl/7b+lDP2wuXjPm6U7/z0s18/4l1RgihWnLKfXTv/vQM 5V6xp8v66wfRx31jijaWP5np6eeZYI/8m6lZbQfzCZhJ9mfMMwTShnndc UFt4MxmJBdmYDBuoJd07nGB/KjS5bS8ZF6u7LuE5buKE+CkzLs27y6x9w NavT3zt+3ZJC0FmGFpB9CumzQi8ykMKs+MwluyeZcV0dSK+ZJlaXClPOi w==;
IronPort-Data: A9a23:D8ZkuK8udGzNiskI6M7yDrUDvn+TJUtcMsCJ2f8bNWPdYAuW7oE1v jtCCD7TOv+LfCKrLOnCW/2/ph8G6sXXz9BqS1Fp/3hnQyIQ9sbLCYyUdUmpb3PDf5CSEhNq5 pxANIefJ8pvRC+M+BqnObO99yAlhKqDFuesYAKo1kGdYCc9IMt2oU46wrJRbvdUvOWE7yOxV fLa8sCAZAb81m4kb25It/vY8hll5Pj86WNB4VZmb6ER4lOCzilEB58hfqzgdHGQrqu4vAKZb 72akOzmpDOxEzMFUI7NfmPTKxVSKlLq0IznZkN+A8BOuDAbzsAJ+vt9ZaJ0hXt/0W3TxYgtk osV7PRcdC9yVkHysLVFO/VnO3wmVUF20Oevza+X6JH7I+XuKhMA8t02ZK0EFdRwFtVfWAmiw cclxAUlNXhvscrtme7mFbM87igUBJKD0Is34hmMxBmHVap2Gcirr6/ivbe01x9o7ixC8Gq3i 2P0plODYTyZCyCjNGv7B7ocjbyaoELzVwRnoVuxm4c66DjT3DJ+he2F3Nr9IrRmRO1/pGDBm UTrzzygRA8RM8aHjzOJtGy2nemJliT+MG4QPOTgsKc12xvKmzdVVE1+uViT+JFVjma8VNVCL 0A85Cc0rLMz+0rtRd74N/G9iCfY5ENHAIQOewE8wCPVxPDY/CHGP3UJUAFiZvcFrtEUfyN/g zdlmPusX1SDqoa9SH+B+OLI9Tq0JS8UKykEYQcISAIf6J/irZ09yBXVQb5LCqO6g83pMTD93 z7MqzIx74j/luYBzaPi4lbKk2r144PXVEgw5x6SVGXj5Bl/Pci7fZeur1Pc6J6sMbqkc7VIh 1Bc8+D20QzEJcjlePClKAnVIIyU2g==
IronPort-HdrOrdr: A9a23:/y2tFa2xLtaTfOcmelw5oAqjBG8kLtp133Aq2lEZdPUzSL38qy nOpoV46faaslYssR0b9+xoW5PufZq0z/cc3WB7B8bAYOCJggqVBbAnw4fkzybpBiHyssVMvJ 0NT4FOTPn9F0Jzg8q/wgWpeuxL/PC3tISln/3XwXsodxxtcK0I1WpEIxyWCVJ7XzNLApcFFJ 6Rj/Atmwad
X-IronPort-AV: E=Sophos;i="5.90,290,1643691600"; d="png'150?scan'150,208,217,150";a="14253366"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Tue, 26 Apr 2022 08:17:13 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.024; Tue, 26 Apr 2022 08:17:13 -0400
From: "Gould, James" <jgould@verisign.com>
To: "ietf=40antoin.nl@dmarc.ietf.org" <ietf=40antoin.nl@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search
Thread-Index: AQHYWWePaV3rxMxA9Umg/C6r0TdNcg==
Date: Tue, 26 Apr 2022 12:17:12 +0000
Message-ID: <0DB20F08-45E9-4557-BD59-BAB4013F70CC@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.59.22031300
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_0DB20F0845E94557BD59BAB4013F70CCverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/3cY3ZEq0MJ4D_7MaLvYIEroS6os>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.34
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: Tue, 26 Apr 2022 12:17:25 -0000

I did a review of the latest version of the draft (draft-ietf-regext-rdap-reverse-search-10), and below is my feedback:


  1.  Abstract
     *   It states, “This document describes RDAP query extensions”.   Shouldn’t it be “this document describes an RDAP query extension” in the singular form?
  2.  Introduction
     *   It is not clear what adopted ad hoc strategies effectively mitigate the impact of reverse searches.  Additionally, a standard search is much less powerful than implementing a reverse search, so I don’t view them as equivalent from a server processing perspective.  Some clarity of how a standard search is equivalent to a reverse search would be helpful or I would remove the statement.
     *   How is the domain-entity relationship treated with a special focus on its privacy implications?  Clarification would be helpful.
  3.  RDAP Path Segment Specification
     *   Is it defining OPTIONAL extensions or an OPTIONAL extension?  I believe the specification is defining a single RDAP extension, so the singular form would be better.
     *   The searchable-resource-type is limited to only resource types defined in RFC 9082.  Shouldn’t it also support new resource types defined by future RDAP extensions?  My recommendation is to have it read “it MUST be one of the resource types for searched defined in Section 3.2 of [RFC9082] or a resource type extension, …”.
     *   The related-resource-type is limited to only resource types defined in RFC 9082.  Shouldn’t it also support new resource types defined by future RDAP extensions?  My recommendation is to have it read “it MUST be one of the resource types for lookup defined in Section 3.1 of [RFC9082] or a resource type extension…”.
  4.  RDAP Conformance
     *   Based on the definition of a single value, the specification is defining a single RDAP extension and not multiple RDAP extensions as indicated in the Abstract and Introduction.

--

JG

[cid:image001.png@01D85946.08164690]

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

From: regext <regext-bounces@ietf.org> on behalf of Antoin Verschuren <ietf=40antoin.nl@dmarc.ietf.org>
Date: Monday, April 25, 2022 at 9:44 AM
To: regext <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

WGLC for this document should have ended last week.
But since there is still a good discussion going on between the Document Shepherd and the authors, the chairs have decided to extend this WGLC for another week till Monday May 2nd.

Since we only had 2 valid support messages (not being the authors or shepherd) we would like to ask for more support from the WG as well. 2 is very little to declare consensus. Could others please review as soon as Mario has published a new version with the comments from Scott and Tom included?



Op 11 apr. 2022, om 15:50 heeft Antoin Verschuren <ietf=40antoin.nl@dmarc.ietf.org<mailto:ietf=40antoin.nl@dmarc.ietf.org>> het volgende geschreven:

Reminder,

1 more week remaining for this WGLC.
In addition to the authors, we received 3 responses so far.

Regards,


Jim and Antoin



Op 4 apr. 2022, om 15:18 heeft Antoin Verschuren <ietf=40antoin.nl@dmarc.ietf.org<mailto:ietf=40antoin.nl@dmarc.ietf.org>> het volgende geschreven:

Dear Working Group,

The authors of the following working group document have indicated that it is believed to be ready for submission to the IESG for publication as a standards track document:

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/<https://secure-web.cisco.com/1ua3m1ygiPX3451lX_xaT9Z-dfjlDPcKJyp8avIFHXnHWndX3bvBPwhtbQU3yIZXz19hRC-18gI3rg7jzG1i7rI75UL5jo68iKqKYLCg2_-lG3zN36bOo2h-UDJuSccsr1TqPJzr-sh4pSgnm5JHfFINaH9HK5TbDl00Ye37nMZ6ecLZQrfipasSmiQTDKvrTDbd1MMXTyIRk2Q3nbS8JPcsGYYX3xs62rg93ONBCUdy48YH1INSVQUwIV2i3d8PO/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-reverse-search%2F>

This WG last call will end at close of business, Monday, 18 April 2022.

Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list.

The document shepherd for this document is Tom Harrison.

Regards,

Jim and Antoin





_______________________________________________
regext mailing list
regext@ietf.org<mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext

_______________________________________________
regext mailing list
regext@ietf.org<mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext