[regext] RDAP reverse search draft feedback

Jasdip Singh <jasdips@arin.net> Fri, 31 July 2020 19:01 UTC

Return-Path: <jasdips@arin.net>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4D0A13A0BCC for <regext@ietfa.amsl.com>; Fri, 31 Jul 2020 12:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rVW2k2vHL2Bl for <regext@ietfa.amsl.com>; Fri, 31 Jul 2020 12:01:36 -0700 (PDT)
Received: from smtp2.arin.net (smtp2.arin.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5EF3A0BC8 for <regext@ietf.org>; Fri, 31 Jul 2020 12:01:07 -0700 (PDT)
Received: from CAS02CHA.corp.arin.net (cas02cha.corp.arin.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTPS id E44781075744 for <regext@ietf.org>; Fri, 31 Jul 2020 15:01:06 -0400 (EDT)
Received: from CAS01CHA.corp.arin.net ( by CAS02CHA.corp.arin.net ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 31 Jul 2020 15:01:14 -0400
Received: from CAS01CHA.corp.arin.net ([fe80::51fb:9cc2:1f9a:288b]) by CAS01CHA.corp.arin.net ([fe80::988:2227:cf44:809%17]) with mapi id 15.00.1104.000; Fri, 31 Jul 2020 15:01:14 -0400
From: Jasdip Singh <jasdips@arin.net>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: RDAP reverse search draft feedback
Thread-Index: AQHWZ2z2IsAPkisUaUCLaDf8XI2kXg==
Date: Fri, 31 Jul 2020 19:01:13 +0000
Message-ID: <FAA3B04A-8EAB-4947-BC8C-1AF6B315D94B@arin.net>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_FAA3B04A8EAB4947BC8C1AF6B315D94Barinnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/YtuzLzgHw9nrQ4TH6OIb-joKoLg>
Subject: [regext] RDAP reverse search draft feedback
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: Fri, 31 Jul 2020 19:01:46 -0000

Hello Mario, Scott,

Please find my feedback on https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/  below:

  1.  Agree with the overall usefulness of this draft to cover the missing/needed search scenarios.
  2.  Not sure if we need to specifically mention in the draft but just noting that Regional Internet Registries (RIRs) also implement the domains search for their reverse DNS zones. :) Something to consider for the Introduction section?
  3.  Why introduce the keyword “reverse” in the search path? Is it to distinguish from the related reverse search scenarios (e.g. domains by nsIp) defined in 7843bis? In light of introducing a new extension for this draft, the “reverse” keyword may be redundant.
  4.  Instead of defining the generic reverse search path {resource-type}/reverse/{role}?{property}=<search pattern>, would it be better to take a specific search path, say domains versus nameservers versus entities, and define the new query parameters (that fill the current search gaps) for each of them section-by-section? Please ignore this comment if the intent here is to pivot around the roles defined in the IANA RDAP JSON Values registry.
  5.  Knowing that it gets more complex but is it possible that folks may need to pass multiple query parameters for conjunctive criteria? If so, {resource-type}/reverse/{role}?{property}=<search pattern> may need to evolve to account for multiple query parameters.
  6.  Though not directly related with this draft, just an observation from 7483bis that there the IP Network and Autonomous System Number objects can be listed in an entity (an org) lookup response but not the Domain objects. Not sure if this was by design?
  7.  May be just me but found the abstract a bit verbose. Move some of it to the Introduction section?