[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

[Mario Loffredo]

Hi Andy,

please find below my reply to this post along with my feedback on 
SimpleRedaction:


- I'm not OK with redacting only the JSON String values. IMO, it's 
better to have a comprehensive approach dealing with any JSON value, 
including objects and arrays. Just to give an example: for the sake of 
compatibility with the WHOIS response, .it RDAP server redacts the 
events of those contacts who did not give the consent for publishing.  
Think that it would be easier for servers to redact the events array 
instead of populating it with fake dates. Similarly, clients could 
signal that all the events have been redacted.


- Some placeholder values must comply with specific formats (e.g. email 
addresses, phone numbers, dates). Sometimes those values look really 
odd  (e.g. what could be a placeholder for a date-time value ? 
"-01-01T00:00:00Z" ?). But i'm more concerned about the result when 
SimpleRedaction is not implemented by the client. I'm afraid that the 
fake values displayed to the user would be interpreted as server errors 
instead of values used on purpose.  Conversely, if RFC9437 was not 
implemented by a client, no fake value would be presented to the user.


-  JSContact uid needs no ad-hoc placeholder value to be redacted. The 
"Security Considerations" section of rdap-jscontact describes how to 
redact it by using the Nil UUID  through the replacementValue method 
when the UUID format is used or, the empty string through the emptyValue 
method otherwise. Please note that the Nil UUID  is already defined by 
RFC9562 for this purpose:


   A Nil UUID value can be useful to communicate the absence of any
   other UUID value in situations that otherwise require or use a
   128-bit UUID.  A Nil UUID can express the concept "no such value
   here".  Thus, it is reserved for such use as needed for
   implementation-specific situations.

- Repeating once again my mantra, the problem here is not the redaction 
method but rather how data are structured. To represent contact data 
that might be redacted, objects should always be preferred to arrays and 
arrays should be redacted instead of their items when arrays have to be 
used. That would considerably help both servers and clients in handling 
redacted data. There would be no ambiguity in selecting a JSON value and 
we wouldn't have to distinguish the path before from the path after the 
redaction because the object members as well as the map entries are 
selected by name and their removal doesn't impact on their siblings.



Best,

Mario

Il 21/06/2024 14:41, Andrew Newton (andy) ha scritto:


On 6/20/24 16:39, rcar...@godaddy.com wrote:


I was not sure if I should reply to this thread or the "Simple" 
thread but as the "Simple" thread appears to be a product of this 
one, I thought I would post here.


Several years ago, there were many discussions (in the REGEXT WG, the 
RDAP WG and others) on how to handle redaction in the RDAP response 
and using placeholder text was an option that was discussed. Through 
those discussions it was determined that using placeholder text was 
not fit for purpose (typed data, different types of redactions, 
varied server implementations, etc) and was deemed as an engineering 
"hack" and called for an original solution. Not using placeholder 
text was exactly what drove us to the creation and eventual 
publication of RFC 9537.



Roger,

It is not simple placeholder text but patterned keys that retain 
syntactic validity. I did search the archives and did not find any 
discussion of this approach. However, if you can point us to the those 
technical discussions or, better, recite them here that would be very 
helpful. While some may pejoratively refer to it as a "hack", there is 
another saying often used by engineers, "the best is the enemy of the 
good."


This solution also has some clear benefits.

1. It can cleanly deal with JSContact UIDs, whereas we had many 
discussions on the list regarding the interaction between JSContact 
and 9537.


2. It can distinguish the parts of a string that are redacted from the 
parts that are not.


3. Even if the client doesn't support the extension and passes the 
data onto the user, there is some chance that the user will understand 
that the data has been redacted.


-andy

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

[Eric Skoglund]

Did a quick readthrough this evening, found some minor nits.

In the paragraph:

"Some domain registrars, acting as EPP clients, have rename host
  objects to subdomains of "as112.arpa," such as "empty.as112.arpa"
  [risky-bizness-irtf].  This practice has been observed in use."

"rename" should be "renamed" and for "as112.arpa," the comma should be outside 
the quotes.

In 5.2.2.1.5.2.:

"since there is no limit with the number of associations to delegated domains."

Change the "with" to either "to" or "on".

"since there is no limit to the number of associations to delegated domains."

IMHO the headings for

5.1.3.  Renaming Observed Practices
5.1.4.  Renaming Potential Practices
5.2.1.  Deletion Observed Practices
5.2.2.  Deletion Potential Practices

Reads a bit clunky to me, how about dropping the "Renaming/Deletion" or 
conversely something like "Observed Practices for Renaming" etc?

Regards,
Eric




From: Carroll, William 
Sent: 21 June 2024 19:09
To: kowa...@denic.de ; 
shollenbeck=40verisign@dmarc.ietf.org 
; regext@ietf.org 
Subject: [regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

Pawel,
I've uploaded a version 04 of the doc with the practices organized into 
observed and potential subsections. We didn't want multiple listings of best 
current practices in both sections 5 and 6. Hopefully this version is clear 
enough.
Thanks!
Bill

On 6/19/24, 6:37 AM, "kowa...@denic.de " 
mailto:kowa...@denic.de>> wrote:


Hi Bill,


TBH I didn't know of the structure in 00 and I must admit it's a way
more straightforward to follow, especially with "practices to avoid".
This determination was not that obvious to me when reading the current
version with each method having Benefits/Detriments section. And I think
this is the value I would expect from BCP.


Just thinking, that maybe the best of both, taking into account that
Section 5 only hast 2 Subsections, would be to have the split "practices
to avoid," "best current practices," and "potential practices" under
each of the subsections? This would keep similar practices together and
still be very straightforward as to what is to be avoided and what is
experimental.


Kind Regards,


Pawel




On 18.06.24 21:25, Carroll, William wrote:
> Pawel,
>
> Thanks for the feedback and for catching the mismatch between the abstract 
> and content.
>
> About the suggestion to split section 5, the 00 version of the document split 
> out practices into "practices to avoid," "best current practices," and 
> "potential practices" sections. We found that organization made it difficult 
> to keep track of and compare similar practices across the sections (it 
> required a lot of jumping back and forth), so we reorganized it to the major 
> categories ("renaming to sacrificial hosts" and "deletion of hosts"). I would 
> prefer to keep the current organization but am open to other ideas.
>
> Thanks,
>
> Bill
>
> On 6/18/24, 1:43 PM, "Hollenbeck, Scott" 
>    >> wrote:
>
>
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> Section 5 already identifies the practices as observed or not, but we can add 
> clarity by splitting it into two sections. We can also update the abstract. 
> Thanks for the feedback.
>
>
> Scott
>
>
>> -Original Message-
>> From: kowa...@denic.de  > > mailto:kowa...@denic.de> 
>> >>
>> Sent: Tuesday, June 18, 2024 12:03 PM
>> To: Hollenbeck, Scott >  > >>; regext@ietf.org 
>>  >
>> Subject: [EXTERNAL] Re: [regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-
>> 03
>>
>> Hi Scott,
>>
>> Splitting Section 5 into "Current Practices" and "Proposed experimental
>> Practices" would offer a lot of more clarity in this respect.
>>
>> Also abstract is not mentioning proposed practices:
>>
>> "This document describes best practices to delete domain and host objects
>> that reduce the risk of DNS resolution failure and maintain client-server 
>> data
>> consistency."
>>
>> I would change to:
>> "This document describes best current practices as well as proposes new
>> experimental practices to delete domain and host objects that reduce the risk
>> of DNS resolution failure and maintain client-server data consistency.
>>
>> Kind Regards,
>>
>> Pawel
>>
>> On 18.06.24 17:46, Hollenbeck, Scott wrote:
>>> Pawel, the document already describes known practices, their issues, and
>> those that are proposed, along with analysis of how they're thought to be
>> better. Wha