Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-ietf-regext-rdap-reverse-search-25> for your review

[Alanna Paloma <[e-mail]>]

Hi Murray,

This is another friendly reminder that we await your approval regarding the removal of the “Description” property from Section 11.2.4.1. See Mario’s mail sent on 3/12/2024 for the explanation of its removal.

Once we have received your approval, we will move this document forward in the publication process.

Thank you,
RFC Editor/ap


> On Mar 25, 2024, at 9:18 AM, Alanna Paloma <[e-mail]> wrote:
> 
> Hi Murray, 
> 
> This is another friendly reminder that we await your AD approval of the removal of the “Description” property in Section 11.2.4.1. Please see mail sent by Mario on 3/12/2024 for the explanation of its removal. 
> 
> Thank you,
> RFC Editor/ap
> 
>> On Mar 18, 2024, at 10:54 AM, Alanna Paloma <[e-mail]> wrote:
>> 
>> Hi Murray,
>> 
>> This is a friendly reminder that we await your approval regarding the removal of the “Description” property. See below for Mario’s explanation of its removal. 
>> 
>> Once we have received your approval, we will move this document forward in the publication process.
>> 
>> Thank you,
>> RFC Editor/ap
>> 
>>> On Mar 12, 2024, at 2:02 AM, Mario Loffredo <[e-mail]> wrote:
>>> 
>>> Hi Murray,
>>> let me shed light on this matter.
>>> In a reply of mine to Robert Wilton (see https://mailarchive.ietf.org/arch/msg/regext/GhZ9GfBckvGlct28PUZNL-DlOB0/) I explained that the "Description" property looked redundant to me in the Reverse Search Mapping Rgistry as the "PropertyPath" property formally and uniquely specifies the mapping between a reverse search property and a response field. As a consequence of it, Robert agreed and approved the removal of such a registry property.
>>> After then, I replied to Sabrina from IANA  (please search for "Re: [IANA #1282802] Protocol Action: 'Registration Data Access Protocol (RDAP) Reverse Search' to Proposed Standard (draft-ietf-regext-rdap-reverse-search-25.txt)" in your mailbox because I didn't find it out in the archive) that I had forgotten to remove the "Description" property but I was sure that the document would have been futher updated so I would have made this change later to make IANA registries consistent with the "IANA Considerations" section. 
>>> And that's what I did in version -26.
>>> 
>>> Best,
>>> Mario
>>> 
>>> Il 11/03/2024 19:44, Murray S. Kucherawy ha scritto:
>>>> I seem to be missing the relevant discussion.  I presume "Description" was removed because it's redundant to what's behind the "Reference"?
>>>> 
>>>> -MSK, ART AD
>>>> 
>>>> On Mon, Mar 11, 2024 at 11:32 AM Alanna Paloma <[e-mail]> wrote:
>>>> Hi Mario and Murray*,
>>>> 
>>>> *Murray - As the AD, please review this query.
>>>> 
>>>>> 6) <!--[rfced] *AD - The authors removed the definition of "Description"
>>>>> in Section 11.2.4.1 in version -26 that was submitted after the
>>>>> document was added to the RFC-ED queue. Please review and let us
>>>>> know if the removal of this definition is acceptable. Note that
>>>>> with this change, the template now matches the "RDAP Reverse
>>>>> Search Mapping" registry
>>>>> <https://www.iana.org/assignments/rdap-reverse-search-mapping/>.
>>>>> 
>>>>> Original:
>>>>> "Property Path":  The JSONPath of the RDAP property this reverse search
>>>>>    property maps to.
>>>>> 
>>>>> "Description":  A brief human-readable text describing this reverse
>>>>>    search property mapping.
>>>>> 
>>>>> "Registrant Name":  The name of the person registering this reverse
>>>>>    search property mapping.
>>>>> 
>>>>> Current:
>>>>> Property Path:  The JSONPath of the RDAP property this reverse search
>>>>>    property maps to.
>>>>> 
>>>>> Registrant:  The name of the person registering this reverse
>>>>>    search property mapping.
>>>>> -->
>>>> 
>>>> Mario - Thank you for your reply.  We have updated as requested.
>>>> 
>>>> The files have been posted here (please refresh):
>>>> https://www.rfc-editor.org/authors/rfc9536.xml
>>>> https://www.rfc-editor.org/authors/rfc9536.txt
>>>> https://www.rfc-editor.org/authors/rfc9536.html
>>>> https://www.rfc-editor.org/authors/rfc9536.pdf
>>>> 
>>>> The relevant diff files have been posted here:
>>>> https://www.rfc-editor.org/authors/rfc9536-diff.html (comprehensive diff)
>>>> https://www.rfc-editor.org/authors/rfc9536-auth48diff.html (AUTH48 changes)
>>>> 
>>>> Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.
>>>> 
>>>> We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>> https://www.rfc-editor.org/auth48/rfc9536
>>>> 
>>>> Thank you,
>>>> RFC Editor/ap
>>>> 
>>>>> On Mar 11, 2024, at 6:33 AM, Mario Loffredo <mario.loffredo=[e-mail]> wrote:
>>>>> 
>>>>> Dear rfc-editor,
>>>>> please find my responses inline prefixed with [ML].
>>>>> Il 08/03/2024 23:05, [e-mail] ha scritto:
>>>>>> Authors and *AD,
>>>>>> 
>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>>> 
>>>>>> *AD, please review question #6 and let us know if you approve.
>>>>>> 
>>>>>> 1) <!--[rfced] May we clarify "with another" to be "with another query"?
>>>>>> And should "in relationship with" be "that relates to" instead?
>>>>>> 
>>>>>> Original:
>>>>>> Through a further step of generalization, the meaning of reverse search
>>>>>> in the RDAP context can be extended to include any query for retrieving
>>>>>> all the objects in relationship with another matching a given search
>>>>>> pattern.
>>>>>> 
>>>>>> Perhaps:
>>>>>> Through a further step of generalization, the meaning of reverse search
>>>>>> in the RDAP context can be extended to include any query for retrieving
>>>>>> all the objects that relates to another query matching a given
>>>>>> search pattern.
>>>>>> --> 
>>>>>> 
>>>>> [ML] Sure.
>>>>>> 2) <!--[rfced] We note that both "data is" and "data are" are
>>>>>> used. Please review and confirm the intent in Section 5 is
>>>>>> singular and Appendix A is plural.
>>>>>> 
>>>>>> Current
>>>>>> 
>>>>>> Section 5:
>>>>>> This data is included in the search response, rather than in 
>>>>>> the help response, because it may differ depending on the 
>>>>>> query that is sent to the server.
>>>>>> 
>>>>>> Appendix A:
>>>>>> * Attribute-Based Access Control (ABAC): Rules to manage access
>>>>>> rights are evaluated and applied according to specific attributes
>>>>>> describing the context within which data are requested.
>>>>>> --> 
>>>>>> 
>>>>>> 
>>>>> [ML] Please change only Section 5 as in the following:
>>>>> OLD 
>>>>> This data is included in the search response, rather than in 
>>>>> the help response, because it may differ depending on the 
>>>>> query that is sent to the server.
>>>>> NEW
>>>>> This data structure is included in the search response, rather than in 
>>>>> the help response, because it may differ depending on the 
>>>>> query that is sent to the server.
>>>>>> 3) <!--[rfced] Please review and consider whether the "type" attribute of the sourcecode elements in the XML file should be set.
>>>>>> 
>>>>>> The current list of preferred values for "type" is available at
>>>>>> https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
>>>>>> list does not contain an applicable type, feel free to suggest additions
>>>>>> for consideration. Note that it is also acceptable to leave the "type"
>>>>>> attribute not set.
>>>>>> -->
>>>>>> 
>>>>> [ML] Authors have used no sourcecode element. However, figures 2 and 3 include JSON contents. Hence, in those cases, sourcecode elements might be used within <figure>  elements and the related "type" attributes should be set to "json". 
>>>>> Figure 1 includes a list of URL path segments. Don't think it's appropriate to use the sourcecode element in that case.
>>>>>> 4) <!--[rfced] Figure titles (Section 8)
>>>>>> 
>>>>>> a) For the title of Figure 2, may we update "reverse_search_properties_mapping" 
>>>>>> to "reverse_search_properties" to match the contents of the figure?
>>>>>> 
>>>>>> Original:
>>>>>> Figure 2: An example of help response including the
>>>>>> "reverse_search_properties_mapping" member
>>>>>> 
>>>>>> Perhaps:
>>>>>> Figure 2: An Example of Help Response including the
>>>>>> "reverse_search_properties" Member
>>>>>> 
>>>>> [ML] Right, but please leave member in lower case, i.e. "reverse_search_properties" member .
>>>>>> 
>>>>>> b) For the title of Figure 3, may we update "reverse_search_properties" 
>>>>>> to "reverse_search_properties_mapping" to match the contents of 
>>>>>> the figure?
>>>>>> 
>>>>>> Original:
>>>>>> Figure 3: An example of an RDAP response including the
>>>>>> "reverse_search_properties" member
>>>>>> 
>>>>>> Perhaps:
>>>>>> Figure 3: An Example of an RDAP Response including the
>>>>>> "reverse_search_properties_mapping" Member
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>> [ML] Right, but please leave member in lower case, i.e. "reverse_search_properties_mapping" member .
>>>>> I apologize but I realized that I inverted the captions of Figure 2 and Figure 3 :-(
>>>>>> 
>>>>>> 
>>>>>> 5) <!--[rfced] We have included specific questions about the IANA
>>>>>> text below. In addition to responding to those questions, please
>>>>>> review all of the IANA-related updates carefully and let us know
>>>>>> if any further updates are needed.
>>>>>> 
>>>>>> a) IANA does not list "Section 8" of this document as a reference for
>>>>>> all entries in the "RDAP Reverse Search" and "RDAP Reverse Search
>>>>>> Mapping" registries. Would you like both IANA registries to reflect
>>>>>> "Section 8", or should "Section 8" be removed from the Reference 
>>>>>> column in Table 1 of this document (Section 11.2.3.2)?
>>>>>> 
>>>>>> Current (Table 1):
>>>>>> | Reference | RFC 9536, Section 8 |
>>>>> [ML] No worries at all. It can be removed.
>>>>>> b) We updated the templates in Sections 11.2.3.1 and 11.2.4.1 to match
>>>>>> the corresponding header names in the "RDAP Reverse Search" and "RDAP
>>>>>> Reverse Search Mapping" registries. Would you like to order both
>>>>>> templates to match how they appear at
>>>>>> <https://www.iana.org/assignments/rdap-reverse-search/> and
>>>>>> <https://www.iana.org/assignments/rdap-reverse-search-mapping/>?
>>>>>> 
>>>>>> Example for the "RDAP Reverse Search" registry template (Section 11.2.3.1)
>>>>>> Original:
>>>>>> Searchable Resource Type
>>>>>> Related Resource Type
>>>>>> Property
>>>>>> Property Path
>>>>>> Description
>>>>>> Registrant Name
>>>>>> Registrant Contact Information
>>>>>> Reference
>>>>>> 
>>>>>> Perhaps:
>>>>>> Property
>>>>>> Description
>>>>>> Searchable Resource Type
>>>>>> Related Resource Type
>>>>>> Registrant
>>>>>> Contact Information
>>>>>> Reference
>>>>>> 
>>>>> [ML] Am OK with matching the order set by IANA.
>>>>>> c) FYI, we have updated the section numbers in the citations listed in
>>>>>> the sentences below so that they now point to the appropriate sections.
>>>>>> 
>>>>>> Original:
>>>>>> 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.
>>>>>> 
>>>>>> Current:
>>>>>> These registries follow the Specification Required registration policy, 
>>>>>> as defined in Section 4.6 of [RFC8126].
>>>>>> 
>>>>>> The designated expert should prevent collisions and confirm that
>>>>>> suitable documentation, as described in Section 4.5 of [RFC8126], is
>>>>>> available to ensure interoperability.
>>>>>> --> 
>>>>>> 
>>>>> [ML] OK.
>>>>>> 6) <!--[rfced] *AD - The authors removed the definition of "Description"
>>>>>> in Section 11.2.4.1 in version -26 that was submitted after the
>>>>>> document was added to the RFC-ED queue. Please review and let us
>>>>>> know if the removal of this definition is acceptable. Note that
>>>>>> with this change, the template now matches the "RDAP Reverse
>>>>>> Search Mapping" registry
>>>>>> <https://www.iana.org/assignments/rdap-reverse-search-mapping/>.
>>>>>> 
>>>>>> Original:
>>>>>> "Property Path": The JSONPath of the RDAP property this reverse search
>>>>>> property maps to.
>>>>>> 
>>>>>> "Description": A brief human-readable text describing this reverse
>>>>>> search property mapping.
>>>>>> 
>>>>>> "Registrant Name": The name of the person registering this reverse
>>>>>> search property mapping.
>>>>>> 
>>>>>> Current:
>>>>>> Property Path: The JSONPath of the RDAP property this reverse search
>>>>>> property maps to.
>>>>>> 
>>>>>> Registrant: The name of the person registering this reverse
>>>>>> search property mapping.
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 7) <!--[rfced] We note that RFC 6973 does not include "misuse of information", but 
>>>>>> it does include "misuse of data". May we update the item listed?
>>>>>> 
>>>>>> Original:
>>>>>> Providing reverse search in RDAP carries the following threats as
>>>>>> described in [RFC6973]:
>>>>>> 
>>>>>> * Correlation
>>>>>> * Disclosure
>>>>>> * Misuse of information
>>>>>> --> 
>>>>>> 
>>>>>> 
>>>>> [ML]  Am OK with using "misuse of data".
>>>>>> 8) <!--[rfced] Regarding the reference entry for [ICANN-RA], would
>>>>>> you prefer to link to the landing page for the Base Registry
>>>>>> Agreement as shown below, where the reader may access a DOCX,
>>>>>> PDF, or HTML version of the most current registry agreement
>>>>>> (2024)? Note that the July 2017 version is archived and also
>>>>>> available from this landing page. Please let us know your
>>>>>> preference.
>>>>>> 
>>>>>> Original:
>>>>>> [ICANN-RA] Internet Corporation For Assigned Names and Numbers,
>>>>>> "Registry Agreement", July 2017,
>>>>>> <https://newgtlds.icann.org/sites/default/files/
>>>>>> agreements/agreement-approved-31jul17-en.pdf>.
>>>>>> 
>>>>>> Perhaps:
>>>>>> [ICANN-RA] ICANN, "Base Registry Agreement", January 2024,
>>>>>> <https://www.icann.org/en/registry-agreements/
>>>>>> base-agreement>.
>>>>>> -->
>>>>>> 
>>>>> [ML] Agreed. Use the more recent reference.
>>>>>> 9) <!--[rfced] The URL in the reference entry below redirects to
>>>>>> <https://lookup.icann.org/en>. Please review and let us know how
>>>>>> the URL may be updated.
>>>>>> 
>>>>>> Original:
>>>>>> [ICANN-RDS2]
>>>>>> Internet Corporation For Assigned Names and Numbers,
>>>>>> "Final Issue Report on a Next-Generation gTLD RDS to
>>>>>> Replace WHOIS", October 2015,
>>>>>> <http://whois.icann.org/sites/default/files/files/final-
>>>>>> issue-report-next-generation-rds-07oct15-en.pdf>.
>>>>>> --> 
>>>>>> 
>>>>> [ML]  This document seems to be removed from ICANN web site. It is also linked from another page (i.e.https://gnso.icann.org/en/group-activities/inactive/2018/rds) but the link doesn't work either .
>>>>> Think it's better to remove this reference and rename the tag "ICANN-RDS1 into "ICANN-RDS".
>>>>>> 10) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
>>>>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 
>>>>>> and let us know if any changes are needed.
>>>>>> 
>>>>>> For example, please consider whether "whitelisting" should be updated.
>>>>> [ML] Sorry. Please replace "whitelisting" with "allow-listing".
>>>>>> 
>>>>>> Additionally, please review the usage of pronouns indicating gender (i.e., "his"
>>>>>> and "he") in Appendix A and let us know if you would like to use gender-neutral
>>>>>> text (e.g., "its" or "their") instead.
>>>>> [ML] Sorry. Please replace every occurrence of "his" with "their" and any occurrence of "he" with "they". 
>>>>> 
>>>>> Hope I addressed all the points.
>>>>> Please let me know if you need further clarifications.  
>>>>> Thanks a lot.
>>>>> Mario
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> RFC Editor/ap/kc
>>>>>> 
>>>>>> 
>>>>>> On Mar 8, 2024, at 2:01 PM, [e-mail] wrote:
>>>>>> 
>>>>>> *****IMPORTANT*****
>>>>>> 
>>>>>> Updated 2024/03/08
>>>>>> 
>>>>>> RFC Author(s):
>>>>>> --------------
>>>>>> 
>>>>>> Instructions for Completing AUTH48
>>>>>> 
>>>>>> Your document has now entered AUTH48. Once it has been reviewed and 
>>>>>> approved by you and all coauthors, it will be published as an RFC. 
>>>>>> If an author is no longer available, there are several remedies 
>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>>> 
>>>>>> You and you coauthors are responsible for engaging other parties 
>>>>>> (e.g., Contributors or Working Group) as necessary before providing 
>>>>>> your approval.
>>>>>> 
>>>>>> Planning your review 
>>>>>> ---------------------
>>>>>> 
>>>>>> Please review the following aspects of your document:
>>>>>> 
>>>>>> * RFC Editor questions
>>>>>> 
>>>>>> Please review and resolve any questions raised by the RFC Editor 
>>>>>> that have been included in the XML file as comments marked as 
>>>>>> follows:
>>>>>> 
>>>>>> <!-- [rfced] ... -->
>>>>>> 
>>>>>> These questions will also be sent in a subsequent email.
>>>>>> 
>>>>>> * Changes submitted by coauthors 
>>>>>> 
>>>>>> Please ensure that you review any changes submitted by your 
>>>>>> coauthors. We assume that if you do not speak up that you 
>>>>>> agree to changes submitted by your coauthors.
>>>>>> 
>>>>>> * Content 
>>>>>> 
>>>>>> Please review the full content of the document, as this cannot 
>>>>>> change once the RFC is published. Please pay particular attention to:
>>>>>> - IANA considerations updates (if applicable)
>>>>>> - contact information
>>>>>> - references
>>>>>> 
>>>>>> * Copyright notices and legends
>>>>>> 
>>>>>> Please review the copyright notice and legends as defined in
>>>>>> RFC 5378 and the Trust Legal Provisions 
>>>>>> (TLP – https://trustee.ietf.org/license-info/).
>>>>>> 
>>>>>> * Semantic markup
>>>>>> 
>>>>>> Please review the markup in the XML file to ensure that elements of 
>>>>>> content are correctly tagged. For example, ensure that <sourcecode> 
>>>>>> and <artwork> are set correctly. See details at 
>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>> 
>>>>>> * Formatted output
>>>>>> 
>>>>>> Please review the PDF, HTML, and TXT files to ensure that the 
>>>>>> formatted output, as generated from the markup in the XML file, is 
>>>>>> reasonable. Please note that the TXT will have formatting 
>>>>>> limitations compared to the PDF and HTML.
>>>>>> 
>>>>>> 
>>>>>> Submitting changes
>>>>>> ------------------
>>>>>> 
>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>>>>> the parties CCed on this message need to see your changes. The parties 
>>>>>> include:
>>>>>> 
>>>>>> * your coauthors
>>>>>> 
>>>>>> * [e-mail] (the RPC team)
>>>>>> 
>>>>>> * other document participants, depending on the stream (e.g., 
>>>>>> IETF Stream participants are your working group chairs, the 
>>>>>> responsible ADs, and the document shepherd).
>>>>>> 
>>>>>> * [e-mail], which is a new archival mailing list 
>>>>>> to preserve AUTH48 conversations; it is not an active discussion 
>>>>>> list:
>>>>>> 
>>>>>> * More info:
>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>> 
>>>>>> * The archive itself:
>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>> 
>>>>>> * Note: If only absolutely necessary, you may temporarily opt out 
>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>> If needed, please add a note at the top of the message that you 
>>>>>> have dropped the address. When the discussion is concluded, 
>>>>>> [e-mail] will be re-added to the CC list and 
>>>>>> its addition will be noted at the top of the message. 
>>>>>> 
>>>>>> You may submit your changes in one of two ways:
>>>>>> 
>>>>>> An update to the provided XML file
>>>>>> — OR —
>>>>>> An explicit list of changes in this format
>>>>>> 
>>>>>> Section # (or indicate Global)
>>>>>> 
>>>>>> OLD:
>>>>>> old text
>>>>>> 
>>>>>> NEW:
>>>>>> new text
>>>>>> 
>>>>>> You do not need to reply with both an updated XML file and an explicit 
>>>>>> list of changes, as either form is sufficient.
>>>>>> 
>>>>>> We will ask a stream manager to review and approve any changes that seem
>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>>>>> and technical changes. Information about stream managers can be found in 
>>>>>> the FAQ. Editorial changes do not require approval from a stream manager.
>>>>>> 
>>>>>> 
>>>>>> Approving for publication
>>>>>> --------------------------
>>>>>> 
>>>>>> To approve your RFC for publication, please reply to this email stating
>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’,
>>>>>> as all the parties CCed on this message need to see your approval.
>>>>>> 
>>>>>> 
>>>>>> Files 
>>>>>> -----
>>>>>> 
>>>>>> The files are available here:
>>>>>> https://www.rfc-editor.org/authors/rfc9536.xml
>>>>>> https://www.rfc-editor.org/authors/rfc9536.html
>>>>>> https://www.rfc-editor.org/authors/rfc9536.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9536.txt
>>>>>> 
>>>>>> Diff file of the text:
>>>>>> https://www.rfc-editor.org/authors/rfc9536-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9536-rfcdiff.html (side by side)
>>>>>> 
>>>>>> Diff of the XML: 
>>>>>> https://www.rfc-editor.org/authors/rfc9536-xmldiff1.html
>>>>>> 
>>>>>> The following files are provided to facilitate creation of your own 
>>>>>> diff files of the XML. 
>>>>>> 
>>>>>> Initial XMLv3 created using XMLv2 as input:
>>>>>> https://www.rfc-editor.org/authors/rfc9536.original.v2v3.xml 
>>>>>> 
>>>>>> XMLv3 file that is a best effort to capture v3-related format updates 
>>>>>> only: 
>>>>>> https://www.rfc-editor.org/authors/rfc9536.form.xml
>>>>>> 
>>>>>> 
>>>>>> Tracking progress
>>>>>> -----------------
>>>>>> 
>>>>>> The details of the AUTH48 status of your document are here:
>>>>>> https://www.rfc-editor.org/auth48/rfc9536
>>>>>> 
>>>>>> Please let us know if you have any questions. 
>>>>>> 
>>>>>> Thank you for your cooperation,
>>>>>> 
>>>>>> RFC Editor
>>>>>> 
>>>>>> --------------------------------------
>>>>>> RFC9536 (draft-ietf-regext-rdap-reverse-search-25)
>>>>>> 
>>>>>> Title : Registration Data Access Protocol (RDAP) Reverse Search
>>>>>> Author(s) : M. Loffredo, M. Martinelli
>>>>>> WG Chair(s) : James Galvin, Antoin Verschuren
>>>>>> 
>>>>>> Area Director(s) : Murray Kucherawy, Francesca Palombini
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> -- 
>>>>> Dott. Mario Loffredo
>>>>> Senior Technologist
>>>>> 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
>>>> 
>>> -- 
>>> Dott. Mario Loffredo
>>> Senior Technologist
>>> 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
>> 
>