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

[Mario Loffredo <[e-mail]>]

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