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

[Mario Loffredo <[e-mail]>]

Hi Tom,

thinking back to my last message, I need some clarifications before 
updating the document.

Please find my comments inline.

Il 18/04/2022 13:10, Tom Harrison ha scritto:
> 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.

[ML] Note a different feeling about it between you and Scott. I mostly 
agree with you on this point but I'm open to any solution that is shared 
by the WG, especially if it comes from those having long experience in 
writing IETF documents.

According to what is stated in 
https://www.ietf.org/id/draft-kucherawy-bcp97bis-01.html:

*...., a normative reference specifies a document that must be read to 
fully understand or implement the subject matter in the RFC, or whose 
contents are effectively part of the RFC, as its omission would leave 
the RFC incompletely specified. **
*

*An informative reference is not normative; rather, it provides only 
additional background information.*

That being said, don't think JSContact related documents must be read to 
fully understand the reverse search document. For this reason, I put 
them among the informative references.

However, I would like to know Scott's and other members'opinions.

>      - 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).

[ML] I have already proposed to extend the response with an inline 
metadata about the supported reverse search properties but I'm not sure 
when it should be returned.

The metadata described in both RFC8977 and RFC 8982 include information 
about server features that can be applied to every search response, 
including reverse search.

On the contrary, it wouldn't make sense to me to return the reverse 
search metadata in every search response.

>
>   - 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.

[ML] Most probably I didn't make myself clear. I meant that servers may 
implement additional reverse search properties, including those mapped 
to RDAP response extensions.

Just to give you an example, some ccTLDs, including .it, have extended 
the registrant information with the tax code.

Being such a code a unique identifier, it could be eligible as reverse 
search property.

Don't think servers should specify a specific RDAP conformance tag in 
that case.  It would be enough for them to provide the reverse search 
properties they implement in the /help response.

Are you OK with changing the sentence as in the following?

Servers MAY implement other properties in addition to those defined in this section.


Totally agree on the other points without comment.

Best,

Mario

>
> -Tom
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo