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

[Tom Harrison <[e-mail]>]

On Mon, Apr 04, 2022 at 03:18:33PM +0200, Antoin Verschuren wrote:
> 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/

I think this document is in good shape as it is.  Some minor
points/suggestions:

 - Section 2 has "All the predicates are joined by the AND logical
   operator".  For the multivalued predicate properties ('role', 'fn',
   and 'email'), the behaviour as required by the text here may be
   slightly unintuitive.  For example, if two 'fn' predicates are
   included, then an object will only be included in the results if
   one of its related entities matches against both of those
   predicates, which would be unusual given that most entities have a
   single 'fn' property.  Making this requirement clearer may help to
   avoid confusion:

    All the predicates are joined by the AND logical operator.  This
    includes predicates that are for the same property: it is
    necessary in such a case for the related object to match against
    each of those predicates.

 - Section 2 has "Based on their policy, servers MAY restrict the
   usage of predicates to make a valid search condition".  It may be
   useful to clarify how this will happen.  For example:

    Based on their policy, servers MAY restrict the usage of
    predicates to make a valid search condition, by returning a 400
    (Bad Request) response when a problematic request is received.

   (Possibly there's a more appropriate response code than 400 that
   can be used.)

 - Section 2 has:

    related-resource-type: it MUST be one of the resource types for
    lookup defined in Section 3.1 of [RFC9082], i.e. "domain",
    "nameserver", "entity", "ip" and "autnum";

   But the document defines semantics only for "entity" in this
   context.  Some additional text (after the bullet points) that makes
   it clear that this is intentional may be useful:

    While related-resource-type is defined as having one of a number
    of different values, the only searches defined in this document
    are for a related-resource-type of "entity".  Searches for the
    other mentioned types may be defined by future documents.

 - There is no text that specifies the response format for the
   searches.  Although this is arguably implicit based on RFC 9082, it
   may be useful to be explicit about it, by adding another section
   between 2 and 2.1:

    2.1 RDAP Response Specification

    Reverse search responses use the formats defined in section 8 of
    RFC 9082, which correspond to the searchable resource types
    defined in section 2.

 - I-D.ietf-calext-jscontact is listed as an informative reference,
   but it appears to be a normative reference, given that the
   JSONPaths for 'fn' and 'email' are taken from that document.
   Assuming that it is a normative reference, then it may be that the
   reverse search document will be approved notwithstanding the
   downref.  However, there are a couple of options for avoiding that
   in the first place:
    - Define the document in terms of jCard only, and note that
      documents defining successor formats to jCard will describe how
      to handle the conversion from 'fn'/'email' to the corresponding
      fields in the new format.
    - Define inline metadata, so that the relevant JSONPaths are
      available to the client, and can be changed to work for
      JSContact when a server switches to use JSContact (similarly to
      how things work with RFC 8977).

 - Section 2.1 has "Servers MAY implement other properties than those
   defined in this section".  A server that supports other properties
   for the purposes of reverse search has no way to indicate that
   support except by way of a standards-track specification that
   defines a new rdapConformance value, which would be the case
   regardless of this additional text in the document, so it seems
   like this text could be omitted.

-Tom