Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

Tom Harrison <tomh@apnic.net> Sun, 27 November 2022 21:49 UTC

Return-Path: <tomh@apnic.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 81B04C14CF00 for <regext@ietfa.amsl.com>; Sun, 27 Nov 2022 13:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=apnic.net
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 PdhcYJ4wVQ26 for <regext@ietfa.amsl.com>; Sun, 27 Nov 2022 13:49:43 -0800 (PST)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01on20613.outbound.protection.outlook.com [IPv6:2a01:111:f403:7004::613]) (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 77AB8C14F5E1 for <regext@ietf.org>; Sun, 27 Nov 2022 13:49:43 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oRH8LqQ7SShiDYXohAB0O5NVQCIbDPnT1mY7ccAdRrd6D0jUnFz7venkTXx067BaiZsV3w/Ybvj0MEMOSeBByVG8VYMEADawmRum2D0OYxJq1unRbQQMqvdfuteKaRNs5dhe/eN3J+kqRObI3mUxpplBtINipW3ueRyOC7Bdw/TEbBi24/+rkKk9MSgKvcNpn7XsjTTyyw8+HABk/uGcQW/Y7n8HUUwb3qLhq8OtGjrlSqEr8jxV5eRd0yeR28b7O2vm2bAL7FB/FYBmCulQfS8kFJ4h4c0S5QZDT0okXpF73Xj6f3EYyJ3gWWSiwvm3qwxf11Z2LRsguhq4D/14iw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zOvaUthZkFm5PebWWXoX6+0ryi4YIj5DVrLek9XUqZQ=; b=Iklv29kWW6W4e1bRAz4dGcESwyloTv/ihmo9xet60kp1I10dRxs7kAfpWAHuIdZfUKzQ6ObOIU5666N3qpzKG2xsT3Osb3SrTdi0k+6GGJM6/Gqx+0G3DO1uyg6rWayfr0G/Bd8VmY4c8frI52SUGgn57ZvPpDisJnN0U5wX71YabezDw9YzxY6xLPBZ2B0CEHohoE5LbY7oP4kae3FPnWDAXmTT2LHDaZJbLMt0oUCP3SzJZ3I++S/TluYYdodaxmcepgfunty+3AZhyRjoBZBSOiP5B0owla5Xk5i4qX/Eu5ern7CZgSuAvy00OxI5iy0l+dxD4VjvH7pvnieiNQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zOvaUthZkFm5PebWWXoX6+0ryi4YIj5DVrLek9XUqZQ=; b=TXWwHiPPCQ5S/Da7Q3UNe91bikRfywsELfggWYSQys2ZEb9EGONoH1vJDC0/2z8xGjzAqcu5NaKyjzVgTTRzk4hqdTry4YHvnIIfor27+SZHLXF9GtgAh7fLwRhd5LGHG5NA2LWxsXqkpMFe4P4VAa/nLuDfM0r05Usqco6CgYE=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net;
Received: from SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:68::12) by MEYP282MB2845.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:154::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.23; Sun, 27 Nov 2022 21:49:38 +0000
Received: from SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM ([fe80::d7d8:f371:c5f2:9848]) by SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM ([fe80::d7d8:f371:c5f2:9848%6]) with mapi id 15.20.5857.022; Sun, 27 Nov 2022 21:49:38 +0000
Date: Mon, 28 Nov 2022 07:49:35 +1000
From: Tom Harrison <tomh@apnic.net>
To: Mario Loffredo <mario.loffredo@iit.cnr.it>
Cc: "regext@ietf.org" <regext@ietf.org>, "pawel.kowalik@ionos.com" <pawel.kowalik@ionos.com>
Message-ID: <Y4Pbb2exb8B34eXc@TomH-802418>
Mail-Followup-To: Mario Loffredo <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>, "pawel.kowalik@ionos.com" <pawel.kowalik@ionos.com>
References: <166904400845.63178.12808486915076028699@ietfa.amsl.com> <3cf24684-e89c-2565-e2ae-be797359ebc4@iit.cnr.it> <Y3zH8UtSf4QMwHU5@TomH-802418> <3d566ca4-999e-4e72-e8f1-2e9dd65d2440@iit.cnr.it> <Y39njQxonjw4vw21@TomH-802418> <85c931a7-7800-6f57-6eed-5115fc1d448c@iit.cnr.it>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <85c931a7-7800-6f57-6eed-5115fc1d448c@iit.cnr.it>
X-ClientProxiedBy: SYBPR01CA0179.ausprd01.prod.outlook.com (2603:10c6:10:52::23) To SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:68::12)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SYBP282MB0553:EE_|MEYP282MB2845:EE_
X-MS-Office365-Filtering-Correlation-Id: f0322a8f-0459-4df6-c47d-08dad0c147dc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 3zCVvnQTfgKrqciABZ6r4wdRcmwlIn3luzcWiHQSzMF9b55sigOAsw5v7C3U+i+6rpNS81VSlB6FU/68dYDJhibrF3CfTPOJ8ZUxMxNNE4cN8TNAxs/AfaLIiyICRSIgt+YTFlsx31vvizL5zcFLyBwiVB+DYaMyKrOmzlITyJpFwIlLue+yHSxj+vadUvL4FwKRI0znDV29/pvzVjl4KHl6q/zeSeliue2txLzH8QRz8dvj57xoCUtj+g6RPKJ60ibB1qjT8osEhG6ND3wDkZxqnndxBZcr2XCFk0RvK6t4x84Got6KCqspFzLSytpoBKjQjzZKfF1ZAEGRKBGCeZAcGXjxouPiMqC/NX2Yj3TfHz4df434GMI5p8yDSeNL0fyxgmO4YvyOUazZz70osbfx5qLKi82TGq36LCjdjZySDLDqGeEWlIpOzF0exJRQTzMbgkbsyHmpsPPWZSEppM56p2LDX6tqidYlqXDY/hckpNaUY/xEgXgD0zE7mmHNE64rhCRj5Xl8bMRZ6TLXIkr0IYj5ANwJmVVRBQovHssqfEhcO5IkJYw0rBYsHodMayFAGqFGH1LW2StDkpDN2cbaaSaZARkBj3JBBY2nFTj7vA51RpxZ6DKroAsKtk9M0aGfqo/U6npTA2fS1+ViXqhQd0AqIEUqEh4ffjKTM+Mqu8oq1QQuOwvAfwYfc0YJ
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(7916004)(4636009)(39830400003)(396003)(366004)(346002)(136003)(376002)(451199015)(86362001)(6486002)(54906003)(6916009)(6506007)(6666004)(9686003)(6512007)(26005)(478600001)(5660300002)(8936002)(41300700001)(4326008)(2906002)(316002)(66946007)(66556008)(66476007)(8676002)(38100700002)(186003)(33716001)(83380400001)(403724002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: zTBBqiB1xizyM0mPTBZlbKY8AdWs/k0DiBjVpsPrI4dnD8UWQSpKOTNrlDACQ50ux/XHaLeb7/wN2xz+qOAb4/u3u0fbW7qIal7+LxqoLtF5nHphK+zlkejTi7mue3PEqMWDyCjOyGdNUm7GRVipmeJX8cOclUDTeqc/D86Fm4AiOCp7WYQh5NaUSJD0JHRIB4GWo+OKO6ZifBNSz9hjotdwaW0z/7q4EMU32ddXpBUZtMopnUNDZzMpTynXm8eLPxDLseuiz9mvA+8uyfQrK/+dOWt3WUt64NEouutub64a7S24RgL9wdREtm5cNXViu2iokUiLWxCpVrH7pauwgKRluLn3d88htCQ9ddNTAlhSIjnw4BFHyZ2z0d0s7dVIINqvbeNZzx7FLAxDt3VY8g3rj1NwPFlfa9zEQVEo1e5+f/eV77VT2BdE7hYGZnSkkcQ7qo2CFWqwNj5ITR7hrzpD8MWzZBEt/muQi55cWBusS04UVp71WO0+TYtARj/MwQ6qEsXUrWoAJb+qB/TD+t/c6PLAcpIn0gFBa7rJV3E849kCvk1T68t0FNpHmGFZ9S+MHU9UdGwrPFARYjFbLYb4JnyjDGYp3I9KRs7YyolYbz/BhIR/1YUdk2cPrSEWiohYmr6MQpyjbMbd6UE0S4+MhPYZOrOjPZUQO1EBZsM5JT1IymUTx1raHM36YVS/5NMb+xtsqHbr1LSEwFAYbAithd58C0z2dgND81Eu4WmhFqNqO2gjXJiJhXuWT0G5aRkwQmRcY1/I8m4jdDwLRVOgyvwZZEHJ33RNTCsHOLmzMu6d0JpefuAxLGPMX6tPkMTRzpIS2HUIJUGrl4Mwtw5WOZtcptjabCY39UvqHAXdDoVoWmU8y+zOoJE9nNmTbGRBNWXLu6vF149QVNSW+/CW61+6nQtPELEhVg855zPMTu9jhXRZTarwgWABUAQIRK6WjQjkwZJzVTfuFWliqt3ILMB1mpr6pQc2OS+HA7Hl/Um1+l1PA3h0IAHPhouM/iw8Q0up5VgcZWsIE0Sk4iKGDjhLNIzqyVsoF03t77FSLbK5X01iRBEcxfxPk9f33Y3fmVW8IcQhExc5VGm7IFdjW1MrFRWsGIXI+b36yqK0h/cEf7OCcJxnYsWtJPXY3l7RIDoOZnpkpF44a4Dp5UAKW5yLsjpxf8NQleqZ8vK+NQZxRRr9sq3/xsl7/o1BvI+5dr5EXnNaH1myYcja6Ypnz0+lJZeyFwPAe0FhFO0qrBdbBG9vSFsajdtp/FE82+SEghMEJ84kN6b+8/uveSuw7ISayCcdsD+Q1SaIkA8v1ulNKEDgUi2HT0GzT75QUXbiMsXfw4uV3UnC2TSbNqjM3+kt6ouqR943LzFmnyBz7Z3glLD20KQ7XRgQ3+Qqv31HmDDnhV5mU1N7uARnh+o95BDeFz5S0ln+2oRCMcrZWusgO5YMjwn3FxybhION2Ykv2RfF+lzoHT++c+QtnjWVZor5KbWT/I2Va3HQFDAbD8cu0XxKe/6GwlWsl0IIkQoduQyJb6FQfrqnzX4a7crZF+y2WtmWBGfYX6a0DQm9C1aeC8YyGW93wFZT5P0O
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f0322a8f-0459-4df6-c47d-08dad0c147dc
X-MS-Exchange-CrossTenant-AuthSource: SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Nov 2022 21:49:38.0356 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: lZuvXATzo/eF5iN0VUHKsVbcxDSvzIgj3Q/gxjD4iYeQwznmtsSVRFFIj+/vK4xy
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYP282MB2845
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/OXkJ2O8CJiuPf1ySZjHoFi-6WN8>
Subject: Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt
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: Sun, 27 Nov 2022 21:49:48 -0000

Hi Mario,

On Fri, Nov 25, 2022 at 02:18:35PM +0100, Mario Loffredo wrote:
> Il 24/11/2022 13:46, Tom Harrison ha scritto:
>> This is the part I (still) don't follow, sorry.  The fact that the
>> label is a JSON value in the "reverse_search_properties" member of
>> the help response does not mean that the label needs to be
>> registered in the "RDAP JSON Values" registry, as best I can tell.
> 
> [ML2] Per my understanding of the introduction of RFC8126, any
> constant defined in a protocol should be registered.
> 
> Since the "reverse_search_properties" member includes some
> pre-defined JSON values, they can be added to the "RDAP JSON Values"
> registry.
> 
>    Many protocols make use of points of extensibility that use
>    constants to identify various protocol parameters.  To ensure
>    that the values in these fields do not have conflicting uses and
>    to promote interoperability, their allocations are often
>    coordinated by a central record keeper.

Thanks, this was the part I was missing.

>>> The content of  "reverse_search_properties" member disambiguates
>>> the meaning of that labels in the context of the reverse search
>>> queries a server supports, e.g. an RDAP server could provide
>>> 
>>> "domains/reverse_search/entity?handle" rather than
>>> "nameservers/reverse_search/entity?handle" or both of them.
>>> 
>>> That said, I admit that the description of the "handle" entry as
>>> presented in the document is tailored on the "entity" as related
>>> resource type so, if there is consensus on this way to go, I'll
>>> make it more generic.
>> 
>> I don't see how the entry could be made more generic with respect
>> to the related resource type.  Even the current descriptions are
>> arguably too broad, since they do not limit the searchable object
>> type to one of domains, nameservers, or entities (being the three
>> searchable object types mentioned in section 2) but could e.g. be
>> read as applying to IP networks and ASNs as well.  A separate
>> registry would fix this problem.
> 
> [ML2] I would simply remove the reference to the "entity" object
> class as in the following:
> 
> OLD
> 
> When the related resource type in a reverse search query is
> "entity", it signals that the RDAP server supports the reverse
> search based on the "fn"property of an entity associated with the
> selected searchable resource type
> 
> NEW
> 
> It signals that the RDAP server supports the reverse search based on
> the "fn"property of the given resource type associated with the
> given searchable resource type
> 
> As I wrote in my previous mail, the reverse search property maps a
> property of the related resource type in a reverse search query. The
> searchable resource type is just needed to specify which reverse
> query an RDAP operator is willing to support but this information is
> included in the "reverse_search_properties" help response extension.
> 
> This approach would minimize the number entries compared to those
> required for a registry including all the variables in the reverse
> search query model.
> 
> In fact, having defined four reverse search properties and based on
> the fact that the object class entity is associated to any RFC9083
> object class, the pre-defined entries of a possible "Reverse Search
> Properties" registry should be the following:
> 
> (domains|nameservers|entities) - entity - handle
> 
> (domains|nameservers|entities) - entity - fn
> 
> (domains|nameservers|entities) - entity - email
> 
> (domains|nameservers|entities) - entity - role
> 
> domains - nameserver - handle
> 
> Applying reverse search to ips and autnums searchable resource types
> without declaring  additional properties would add no entry to "RDAP
> JSON Values" registry instead of eight additional entries in the
> "Reverse Search Properties"  registry.

My main concern here is that the reverse search document defines
behaviour for searchable object types that contain an 'entities'
member which is a list of entity-type objects, with the further
requirement that the 'fn' and 'email' searches only work correctly for
entity-type objects containing vCards (i.e. they won't work for
entity-type objects containing JSContact records).  Defining the
registry property generically runs the risk of server implementors
adding reverse search properties for other object types (searchable or
related), without properly defining the behaviour for those searches.
Using the existing registry is fine (IMHO) if the text limits the
search to the cases considered by this document.  (That does mean that
it's not possible to register more than one reverse search for a given
name, but maybe that's not a serious problem in practice, given that
implementors can just choose another name if necessary.)

>> But there's no way to prevent collisions from happening, if custom
>> reverse search properties are supported.  If server S1 uses a
>> custom reverse search property named P, and server S2 then
>> registers with IANA a property with the same name, then there will
>> be a collision between the two names.  It won't necessarily be
>> possible for S2 to confirm that P hasn't previously been used.
> 
> [ML2] Even now there is no real way to prevent collisions since
> extension identifiers and JSON values are normally used for long
> before they are registered.
> 
> Currently, only when an extension is considered stable, the related
> identifier is registered.
> 
> Think that preventing RDAP operators to provide temporary reverse
> search properties is incompatible with registries'policy of
> releasing features on test platforms for a limited period before
> running them in the live environment.

I can see the argument here, but the document doesn't say e.g. "custom
properties may only be used temporarily, or for testing purposes", so
it doesn't prevent two servers from having two custom properties with
the same name and different behaviour, each of which is intended to be
used long-term (i.e. neither server intends to register the property,
for whatever reason).  If support for custom properties is omitted
from the document, then a server wanting to support a new reverse
search property temporarily or for testing can still do that, but the
lack of in-protocol support for that makes it clear that it's not
meant to be a long-term solution.

>>> With regard to the meaning of your last sentence, I need a
>>> clarification.  Are you meaning that inconsistencies come up
>>> because, for example, the "email" reverse search property maps the
>>> same JSON value but identified through two different JSONPaths in
>>> the RDAP response ?
>> 
>> I don't think it would be open to a server to do this under the
>> current document, because the JSONPath to "email" is defined in the
>> document itself.  An example scenario where inconsistency could occur:
>> 
>>   - S1, S2, and S3 implement support for JSContact.
>>   - S1 decides to add a custom reverse search property called "name",
>>     for matching a JSContact "name" (per 2.2.1 of that document), by
>>     looking at the "given" and "surname" name components for the
>>     JSContact "name".
>>   - S2 also adds a custom reverse search property called "name", but
>>     instead matches against the JSContact "fullName".
>>   - S3 also adds a custom reverse search property called "name", in the
>>     same manner as S2, but if a jCard is retrieved, it falls back to
>>     using the same logic as that for an "fn" reverse search per the
>>     current document.
> 
> I still think that custom properties are useful for the reasons above.
> 
> On the other hand, their possible misuse should be ruled somehow.
> 
> Here in the following a possible statement limiting the scope of custom
> properties:
> 
> "A custom reverse search property MUST NOT collide with a registered reverse
> search property and MUST NOT match an RDAP property, or any of its variants,
> matched by a registered reverse search property."
> 
> Being JSContact fullName a variant of jCard fn, both S2 and S3 can't define
> "name" as a custom property.

I still don't see how the document can require that a custom reverse
search property not collide with registered reverse search properties
as to its name or the members that it refers to, because the person
registering a new reverse seach property is not guaranteed to be aware
of all existing custom reverse search properties.  The fact that a
given field is a 'variant' of another may not be obvious to
implementors, either.  If any new reverse search that isn't covered by
the existing document has to be defined in an extension, then these
problems go away.

-Tom