Re: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search

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

Return-Path: <jasdips@arin.net>
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 D314D3A1232 for <regext@ietfa.amsl.com>; Fri, 31 Jul 2020 07:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 bnjSDPvSOfmX for <regext@ietfa.amsl.com>; Fri, 31 Jul 2020 07:35:32 -0700 (PDT)
Received: from smtp2.arin.net (smtp2.arin.net [192.136.136.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4B03A12D5 for <regext@ietf.org>; Fri, 31 Jul 2020 07:35:16 -0700 (PDT)
Received: from CAS01CHA.corp.arin.net (cas01cha.corp.arin.net [10.1.30.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTPS id 8BF431075744; Fri, 31 Jul 2020 10:35:15 -0400 (EDT)
Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS01CHA.corp.arin.net (10.1.30.62) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 31 Jul 2020 10:35:23 -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 10:35:22 -0400
From: Jasdip Singh <jasdips@arin.net>
To: Mario Loffredo <mario.loffredo@iit.cnr.it>, "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search
Thread-Index: AdZnNOUF5N2RSl5aSj6EkwI8/xgDnAAJ4D4AAAfk/YD//82xgIAAPc7A///MW4D//7/MAA==
Date: Fri, 31 Jul 2020 14:35:22 +0000
Message-ID: <AB4BAD13-56B7-4EEE-9E72-36792CD4DD93@arin.net>
References: <1cb2fde4261748afa8163333d090b84a@verisign.com> <df404a43-8284-5466-7d83-88e27d5691ef@iit.cnr.it> <4541e6d1530943e5bfd5c211a426ff82@verisign.com> <5d2ab8ae-563e-b244-10c6-ae8b90fc2d4b@iit.cnr.it> <a73a0c6356f94caa9efa3c25991453ba@verisign.com> <961d717d-80db-f395-9f1e-c0f55f3cffb1@iit.cnr.it>
In-Reply-To: <961d717d-80db-f395-9f1e-c0f55f3cffb1@iit.cnr.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.136.136.37]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5DB8E11EE0483745AE923F88FF6BD726@corp.arin.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/ILr2IqT1dGE8CjFRcqw8Ok1Wm2g>
Subject: Re: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search
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 14:35:36 -0000

IMHO, the current wording in 7843bis seems clear enough, especially the phrase "specifications used in the construction of the response." It is about what specifications were used for the returned response. No?

Jasdip

On 7/31/20, 10:28 AM, "regext on behalf of Mario Loffredo" <regext-bounces@ietf.org on behalf of mario.loffredo@iit.cnr.it> wrote:

    
    Il 31/07/2020 16:10, Hollenbeck, Scott ha scritto:
    >> -----Original Message-----
    >> From: Mario Loffredo <mario.loffredo@iit.cnr.it>
    >> Sent: Friday, July 31, 2020 9:49 AM
    >> To: Hollenbeck, Scott <shollenbeck@verisign.com>; regext@ietf.org
    >> Subject: [EXTERNAL] Re: [regext] IANA Considerations in draft-ietf-regext-
    >> rdap-reverse-search
    >>
    >> Hi Scott,
    >>
    >> Il 31/07/2020 15:21, Hollenbeck, Scott ha scritto:
    >>>> -----Original Message-----
    >>>> From: Mario Loffredo <mario.loffredo@iit.cnr.it>
    >>>> Sent: Friday, July 31, 2020 9:03 AM
    >>>> To: Hollenbeck, Scott <shollenbeck@verisign.com>; regext@ietf.org
    >>>> Subject: [EXTERNAL] Re: [regext] IANA Considerations in
    >>>> draft-ietf-regext- rdap-reverse-search
    >>>>
    >>>> Hi Scott,
    >>>>
    >>>> thanks a lot for your feddback.
    >>>>
    >>>> Please find my comments to your feedback below.
    >>>>
    >>>> Il 31/07/2020 14:29, Hollenbeck, Scott ha scritto:
    >>>>> draft-ietf-regext-rdap-reverse-search currently states that "This
    >>>>> document
    >>>> has no actions for IANA".  I believe that's primarily because there's
    >>>> nothing new or different being returned in the search results, which
    >>>> is where RDAP servers describe the features they support.
    >>>> Exactly.
    >>>>> There is, however, a case to be made for registering a value in the
    >>>>> RDAP
    >>>> extensions registry: a response to a help query (or any other query)
    >>>> can be used to indicate that the server supports reverse search. I'd
    >>>> like to suggest this change for Section 7:
    >>>>> OLD:
    >>>>> This document has no actions for IANA.
    >>>>>
    >>>>> NEW:
    >>>>> IANA is requested to register the following value in the RDAP
    >>>>> Extensions
    >>>> Registry:
    >>>>> Extension identifier: reverse_search_1_0 (or whatever makes sense)
    >>>>> Registry operator: Any Published specification: This document.
    >>>>> Contact: IESG <iesg@ietf.org>
    >>>>> Intended usage: This extension describes reverse search query
    >>>>> patterns
    >>>> for RDAP.
    >>>>> Scott
    >>>> I agree.
    >>>>
    >>>> Furthermore, my opinion is that Section 4.1 of RFC7483bis should be
    >>>> updated to treat this use case. I mean, a server should signal in
    >>>> rdapConformance not only the extensions used in building the response
    >>>> but all the supported features.
    >>> So maybe this?
    >>>
    >>> OLD:
    >>> The data structure named "rdapConformance" is an array of strings, each
    >> providing a hint as to the specifications used in the construction of the
    >> response.
    >>> NEW:
    >>> The data structure named "rdapConformance" is an array of strings, each
    >> providing a hint as to the specifications that describe the query and response
    >> formats supported by the server.
    >>> Scott
    >> How about "query and response extensions" ?
    > That would exclude the core protocol specifications. Is this better?
    >
    > "The data structure named "rdapConformance" is an array of strings, each of which describes a query or response specification supported by the server."
    
    OK. I wrote "extensions" in my previous message to mean "in addition to 
    rdap_level_0".
    
    Mario
    
    >
    > Scott
    >
    > _______________________________________________
    > regext mailing list
    > regext@ietf.org
    > https://www.ietf.org/mailman/listinfo/regext
    
    -- 
    Dr. Mario Loffredo
    Systems and Technological Development Unit
    Institute of Informatics and Telematics (IIT)
    National Research Council (CNR)
    via G. Moruzzi 1, I-56124 PISA, Italy
    Phone: +39.0503153497
    Mobile: +39.3462122240
    Web: http://www.iit.cnr.it/mario.loffredo
    
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext