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

["Murray S. Kucherawy" <[e-mail]>]

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