Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Amanda Baber <amanda.baber@iana.org> Wed, 23 August 2023 17:51 UTC
Return-Path: <amanda.baber@iana.org>
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 9F339C13AE4E; Wed, 23 Aug 2023 10:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 vDzVCcTukQ24; Wed, 23 Aug 2023 10:51:18 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 BA98CC13AE2D; Wed, 23 Aug 2023 10:51:18 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa2.lax.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 37NHpCSx028069 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Aug 2023 17:51:13 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Wed, 23 Aug 2023 10:51:11 -0700
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.1118.030; Wed, 23 Aug 2023 10:51:11 -0700
From: Amanda Baber <amanda.baber@iana.org>
To: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-regext-rdap-reverse-search@ietf.org" <draft-ietf-regext-rdap-reverse-search@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>, "tomh@apnic.net" <tomh@apnic.net>
Thread-Topic: [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Thread-Index: AQHZ1cK4OqU8NKDWcU+qy6sbJj9S7q/4KUcA
Date: Wed, 23 Aug 2023 17:51:11 +0000
Message-ID: <7712565C-F1E7-4726-9100-FB989ED79264@iana.org>
References: <169279601849.28214.1438749064615727794@ietfa.amsl.com>
In-Reply-To: <169279601849.28214.1438749064615727794@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.63.22070801
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3775632670_2081677450"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-08-23_12,2023-08-22_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/whmmf1-yGqI4XBZbqDoVDHmo4j0>
Subject: Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 23 Aug 2023 17:51:22 -0000
Regarding the use of a brief description in the registry itself as the "Specification" in "Specification Required": I missed it this time, but we ran into this same question with draft-ietf-calext-jscalendar-21, and FWIW, Barry Leiba recommended to the author that the registration procedure be changed to Expert Review. Thanks, Amanda On 8/23/23, 6:07 AM, "iesg on behalf of Robert Wilton via Datatracker" <iesg-bounces@ietf.org on behalf of noreply@ietf.org> wrote: Robert Wilton has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTv8R0bod8$ [ietf[.]org] for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTvYBEfpd4$ [datatracker[.]ietf[.]org] ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Flagging part of the IANA considerations as a DISCUSS, but I think that this should be easy to resolve: (1) p 11, sec 12.2.1. Creation of the RDAP Reverse Search Registries These registries follow the Specification Required process as defined in Section 4.5 of [RFC8126]. The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability. References are not limited only to RFCs and simple definitions could be described in the registries themselves. I'm not sure that "simple definitions could be described in the registries themselves" is consistent with the "Specification Required" policy chosen above. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [I support John's discuss on normative references.] I also have some other comments that you may wish to consider: (2) p 14, sec 12.2.4.2. Initial Content +==========+==================================================+ | Property | Property Path | +==========+==================================================+ | fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3] | +----------+--------------------------------------------------+ | handle | $.entities[*].handle | +----------+--------------------------------------------------+ | email | $.entities[*].vcardArray[1][?(@[0]=='email')][3] | +----------+--------------------------------------------------+ | role | $.entities[*].roles | +----------+--------------------------------------------------+ Would it be helpful for this table to include the "Description" and "Reference" properties? Minor level comments: (3) p 3, sec 1. Introduction The protocol described in this specification aims to extend the RDAP query capabilities and response to enable reverse search based on the relationships defined in RDAP between an object class for search and a related object class. The reverse search based on the domain- entity relationship is treated as a particular case of such a generic model. This introduction text seems to immediately jump into a defense as to why it is okay to standardize this functionality in an RDAP extension. This is okay, but I wonder whether it wouldn't be better if the introduction only included the last paragraph (i.e., that is stating what extension is defined in this document), and the rest of the text was moved into a "Background" subsection of the introduction. (4) p 7, sec 8. Reverse Searches Based on Entity Details Reverse search property: fn RDAP member path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3] Reference: Section 6.2.1 of [RFC6350] A minor issue, but it wasn't immediately obvious to me what 'fn' is - I initially presumed that it meant function, so I was wondering if some more text would be helpful here, and/or perhaps in the IANA registry that you are creating. Regards, Rob
- [regext] Robert Wilton's Discuss on draft-ietf-re… Robert Wilton via Datatracker
- Re: [regext] [Ext] Robert Wilton's Discuss on dra… Amanda Baber
- Re: [regext] Robert Wilton's Discuss on draft-iet… Mario Loffredo
- Re: [regext] [Ext] Robert Wilton's Discuss on dra… Mario Loffredo
- Re: [regext] [Ext] Robert Wilton's Discuss on dra… Amanda Baber
- Re: [regext] [Ext] Robert Wilton's Discuss on dra… Mario Loffredo
- Re: [regext] Robert Wilton's Discuss on draft-iet… Mario Loffredo
- Re: [regext] Robert Wilton's Discuss on draft-iet… Rob Wilton (rwilton)
- Re: [regext] Robert Wilton's Discuss on draft-iet… Mario Loffredo