Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-ietf-regext-rdap-reverse-search-25> for your review
"Murray S. Kucherawy" <superuser@gmail.com> Mon, 01 April 2024 16:18 UTC
Return-Path: <superuser@gmail.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C736C15106B; Mon, 1 Apr 2024 09:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJexc-BSFtrA; Mon, 1 Apr 2024 09:18:36 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7029C14CF1A; Mon, 1 Apr 2024 09:18:35 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-513e8bf8228so1431218e87.1; Mon, 01 Apr 2024 09:18:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711988314; x=1712593114; darn=rfc-editor.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r4Cr4mi8FUbnPKq4aOfvDdaY96MnxhSwvP7i0qlq1nA=; b=b5Sl0QHjzGhBqhTR7gHPSnaTeqZb9JNoA3RJ623oahvlwpCxz0nwl7SdAfuq9o7vOb rj1XoymDq53iRhukX8WQJmiyGaLDL+/OzwYyThLfQbZPVFhER+snZa1fg7heqWHjX8R/ cEBsDZSt8oSQJ3VDOFjmVvo96wISaNrs3uIwuqLanmUvdhMdzBFROz8rXQHahWKIZ3lo 1alQwV1wkg9ZgcqBtnsHZRDEM3HCYyodN24WcXiJeNyYMbtwRvnXnRenW7h5iuCwHv++ 9U+vNznoRy8C5Ws/p+GaOBhr2SxDZ6gDFmST9gVwBM0+YzRZZwkcKfDrtriR+M59sOaZ CR1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711988314; x=1712593114; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r4Cr4mi8FUbnPKq4aOfvDdaY96MnxhSwvP7i0qlq1nA=; b=YLEFt6DQH4OnbTiQsnR1CS+i0dIv71aP81n0znmooENaCOK6BUTG71KxY223GC3uH0 HtyakOApohZiZEv4G76xn2xul3LCfJoIJCo/dDwMdYQGy6jFzQzIkp1iYl7fnnfdtgeW 0oejfD1idYzBfglEotlQOgBCgc8Zsz/8CZU9KEOFBM1dU8npszPiaDV3cI8H5xCF8cFs /rjhJYae4eeJRUnQv1YKwvddJ/ScfLdSMMKqQXB5NuA/+m+gue8CcBJgUsnwiIRsc+VZ jutzB778K2NQP0CbZxhps46DUvOTM/mROG3pIYecJga8Pa3CgCST2rNNjjL+6/nwE4Kd 0f2g==
X-Forwarded-Encrypted: i=1; AJvYcCV998T8BtlyQw640EC7dGmx2XaL2hBxizhEHQjObNz11nnrHXQbX3/cGkUN5qQHNK8SN+O3YvCI7o7H3xbteOIyqgZnaOWMDVR1X9V4HEJ7U5ltJkcblTFV8QZWScNbt85kS7b/7FUt
X-Gm-Message-State: AOJu0YwrlwMXEtvLgMNcmMthhPuyQELUEM1Od2SaHKP1rUAJKgAGBSeN IhJjN19/DgOWjvCjc0TzSsAZdUAQ0pN6BemliVmUXo51zHFL1bnfVEbiX3gYMiD9v59YEAeLptU SSg2rQAGbA7IFWsLvuBrJA0KVp0e+b6qa0uw=
X-Google-Smtp-Source: AGHT+IEpps5rbdLwKYvwLcA7ch2iqsQJNTET4TdxzHU1lc0HLKkyK+6GE3ZfdVcUubhRDE/rgGP+5oXxFGw/D+Vak4Y=
X-Received: by 2002:a05:6512:3b8e:b0:513:cfb8:8cb3 with SMTP id g14-20020a0565123b8e00b00513cfb88cb3mr8720677lfv.1.1711988313500; Mon, 01 Apr 2024 09:18:33 -0700 (PDT)
MIME-Version: 1.0
References: <20240308220538.8F54555D4B@rfcpa.amsl.com> <f505d21a-0680-47bc-af63-c50a60854a81@iit.cnr.it> <6FF7774A-06FC-451C-993E-E36847871F3A@amsl.com>
In-Reply-To: <6FF7774A-06FC-451C-993E-E36847871F3A@amsl.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Mon, 01 Apr 2024 09:18:20 -0700
Message-ID: <CAL0qLwY92-54D=LxtWF980APqpLwaKn-L2m3+xV2UVJ=X19Kug@mail.gmail.com>
To: Alanna Paloma <apaloma@amsl.com>
Cc: Mario Loffredo <mario.loffredo=40iit.cnr.it@dmarc.ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, maurizio.martinelli@iit.cnr.it, regext-ads@ietf.org, regext-chairs@ietf.org, tomh@apnic.net, "auth48archive@rfc-ed" <auth48archive@rfc-editor.org>
Content-Type: multipart/alternative; boundary="00000000000049382206150b578b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/DhyIrNyD_AWDhuwHS3pEUZ7FJrQ>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-ietf-regext-rdap-reverse-search-25> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2024 16:18:40 -0000
Hi Alanna, The removal of "Description" in the IANA registry is approved, as it's redundant to the need for a reference document. -MSK, ART AD On Mon, Mar 11, 2024 at 11:32 AM Alanna Paloma <apaloma@amsl.com> 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= > 40iit.cnr.it@dmarc.ietf.org> wrote: > > > > Dear rfc-editor, > > please find my responses inline prefixed with [ML]. > > Il 08/03/2024 23:05, rfc-editor@rfc-editor.org 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, rfc-editor@rfc-editor.org 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 > >> > >> * rfc-editor@rfc-editor.org (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). > >> > >> * auth48archive@rfc-editor.org, 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, > >> auth48archive@rfc-editor.org 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: +39.0503153497 > > Web: http://www.iit.cnr.it/mario.loffredo > >
- [auth48] AUTH48: RFC-to-be 9536 <draft-ietf-regex… rfc-editor
- Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9536 <dra… Mario Loffredo
- Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-i… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9536 <draft-ietf-r… Mario Loffredo
- Re: [auth48] AUTH48: RFC-to-be 9536 <draft-ietf-r… Maurizio Martinelli
- [auth48] [AD] Re: AUTH48: RFC-to-be 9536 <draft-i… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9536 <draft-ietf-r… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9536 <draft-ietf-r… Mario Loffredo
- Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-i… Mario Loffredo
- Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-i… Alanna Paloma
- Re: [auth48] [AD] AUTH48: RFC-to-be 9536 <draft-i… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9536 <draft-ietf-r… Alanna Paloma