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