Re: [auth48] AUTH48: RFC-to-be 9537 <draft-ietf-regext-rdap-redacted-16> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!--[rfced] To clarify the second half of the sentence below, may we update
it as follows?

Original:
   The JSONPath expressions in the examples are for illustration
   purposes with single-role entities and the exact expressions to use
   by the server is out-of-scope.

Perhaps:
   The JSONPath expressions in the examples are for illustration
   purposes with single-role entities, and the exact expressions to be used
   by the server are out of scope.
-->   


2) <!--[rfced] May we reorder the references in this sentence for easier
readability as shown below?

Original:
    An example is the vCard [RFC6350] "ADR" property / jCard [RFC7095] 
    "adr" property that defines a sequence of address components. 

Perhaps:
    An example is the vCard "ADR" property [RFC6350], or the jCard  
    "adr" property [RFC7095], which defines a sequence of 
    address components.  
-->


3) <!--[rfced] Since "RFC 7095" is referenced for "jCard" in Section 3,
is it necessary to reference "RFC 7095" each time "jCard" is used
thereafter as it affects readability when there are multiple
references within one sentence or in close proximity.

Please let us know if "[RFC7095]" (from instances of "jCard
[RFC7095]") may be removed after the first mention in 
Section 3. If that is not desired, may we update the 
sentences that contain multiple mentions to include only 
one mention as shown below? Please let us know your preference.

Some examples:

Original:
   The empty jCard [RFC7095] values ("" or null) are
   referenced in the "redacted" member in place of the jCard [RFC7095]
   property name in a array, such as referencing the "fn" jCard
   [RFC7095] property value at position 3 instead of referencing the
   "fn" jCard property name at position 0. 

Perhaps:
   The empty jCard [RFC7095] values ("" or null) are
   referenced in the "redacted" member in place of the jCard
   property name in an array, such as referencing the "fn" jCard
   property value at position 3 instead of referencing the
   "fn" jCard property name at position 0. 

...
Original:
   For example, removal of an individual data field in
   jCard [RFC7095] will result in a non-conformant 
   jCard [RFC7095] array definition.

Perhaps:
   For example, removal of an individual data field in jCard will
   result in a non-conformant jCard array definition [RFC7095].

...
Original: 
   Reference index 0 of the jCard [RFC7095] property array, which is 
   the jCard [RFC7095] "name" property, with a filter expression
   containing the name of the field, when redacting a jCard [RFC7095]
   field using the Redaction by Removal Method (Section 3.1).

Perhaps: 
   Reference index 0 of the jCard [RFC7095] property array,
   which is the jCard "name" property, with a filter expression
   containing the name of the field, when redacting a jCard field using
   the Redaction by Removal Method (Section 3.1).
-->


4) <!--[rfced] Per usage in RFC 7095 and throughout the document, may we make "Text" lowercase?

Original:
   The Redaction by Empty Value Method is when a redacted field is not
   removed, but its value is set to an empty value, such as "" for a
   jCard [RFC7095] Text ("text") property or null for a non-Text
   property.

Perhaps:
   The Redaction by Empty Value Method is when a redacted field is not
   removed but its value is set to an empty value, such as "" for a
   jCard [RFC7095] text ("text") property or null for a non-text
   property.
-->   


5) <!--[rfced] We note that Figures 2, 6, 7, 8, 9, and 10 include
introductory text that repeats the information stated in their
titles. To avoid redundancy, may we remove the introductory text
for the figures listed?
-->


6) <!--[rfced] As RFC 7095 does not have its figures numbered, may we update "Figure 15" to be "Section 3.3.1.3" instead?

Original:
   An example of the "label" jCard property in Figure 15 of [RFC7095]
   that redacts "123 Maple Ave\nSuite 901\n":
   ...
   An example of the "redacted" member for the redacted "label" jCard
   property value, based on Figure 15 of [RFC7095]:

Perhaps:
   An example of the "label" jCard property in Section 3.3.1.3 of [RFC7095]
   that redacts "123 Maple Ave\nSuite 901\n":
   ...
   An example of the "redacted" member for the redacted "label" jCard
   property value, based on Section 3.3.1.3 of [RFC7095]:   
-->   


7) <!-- [rfced] We have included some 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) Section 6.1. In the "RDAP Extensions" registry under the "redacted" 
value, the Contact is listed as "IESG" in this document; however, it 
is listed as "IETF" in the IANA registry at
"https://www.iana.org/assignments/rdap-extensions". For consistency,
should this document be updated to reflect "IETF", or should the IANA 
registry be updated to reflect "IESG"?

Current (Section 6.1):
   Contact:  IESG <[e-mail]>

b) Section 6.2. In the "RDAP JSON Values" registry under the Description 
for "jsonpath", this document references "draft-ietf-jsonpath-base" ("RFC 9535")
but IANA references this document (see "https://www.iana.org/assignments/
rdap-json-values/"). Please confirm which document should be listed,
and we will update this specification or the IANA registry accordingly.

Original (Section 6.2):
   Description:  JSON path expression language, as defined in 
      draft-ietf-jsonpath-base.
-->


8) <!-- [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 "whitespace" should be updated. 
-->


Thank you.

RFC Editor/ap/kc


On Mar 8, 2024, at 2:16 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/rfc9537.xml
  https://www.rfc-editor.org/authors/rfc9537.html
  https://www.rfc-editor.org/authors/rfc9537.pdf
  https://www.rfc-editor.org/authors/rfc9537.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9537-diff.html
  https://www.rfc-editor.org/authors/rfc9537-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9537-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9537

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9537 (draft-ietf-regext-rdap-redacted-16)

Title            : Redacted Fields in the Registration Data Access Protocol (RDAP) Response
Author(s)        : J. Gould, D. Smith, J. Kolker, R. Carney
WG Chair(s)      : James Galvin, Antoin Verschuren

Area Director(s) : Murray Kucherawy, Francesca Palombini