I think Jody captured my thoughts. Option 1 is my preference. -andy
On Fri, Dec 9, 2022 at 12:33 PM Mario Loffredo <[email protected]> wrote: > > Hi James and others, > > I prefer option 1 too. > > With regard to the transition period, think it can't really be implemented > since this specification doesn't describe features for a server to swtich > from one way to and back from the other on demand until the old way is > completely deprecated. As opposed to the replacement of jCard with JSContact, > in this case it's not worth it because basically it doesn't make much > difference for a client if an RDAP field is missing or contains a placeholder > value. > > What a server can do is to notify the clients about the imminent change of > redaction strategy and then make the switch when it's time. > > Best, > > Mario > > Il 09/12/2022 15:30, Gould, James ha scritto: > > Jasdip, > > > > Agreed. If providing clarity around transitioning to the old way to the new > way makes sense to keep the MUST NOT language, then that can certainly be > done. The transition considerations section could include an overlap period > that supports a soft cutover. A similar kind of section can be found for the > Secure Authorization Information for Transfer RFC 9154 > (https://datatracker.ietf.org/doc/html/rfc9154#section-6); although the > redaction transition section would be much simpler. With that I’ll add back > in inclusion of the MUST NOT language and the transition considerations > section to the list of options, as option 5. > > > > 1. Keep MUST NOT – The Section 3 sentence is “The use of placeholder > text for the values of the RDAP fields, such as the placeholder text "XXXX", > MUST NOT be used for redaction.”. > > 2. Change MUST NOT to SHOULD NOT – This enables the draft to recommend that > placeholder text not be used for redaction, but still enable the server to > support it in parallel with the redaction methods defined in the extension. > The Section 3 sentence would become “The use of placeholder text for the > values of the RDAP fields, such as the placeholder text "XXXX", SHOULD NOT be > used for redaction.”. > > 3. Remove the normative language – Change the Section 3 sentence to “The use > of placeholder text for the values of the RDAP fields, such as the > placeholder text "XXXX", has been used for redaction.”. > > 4. Remove reference to placeholder text use for redaction – Just lead > Section 3 with the sentence “This section covers the redaction methods that > can be used with the redaction signaling defined in Section 4.2.”. > > 5. Keep MUST NOT with Transition Considerations section – Same as option 1, > but with the addition of a Transition Considerations section that provides > guidance on transition of the use of placeholder text redaction to the use of > the redaction extension. > > > > My preference order would be Option 1, Option 5, and then Option 3 as a > fallback. > > > > Thanks, > > > > -- > > > > JG > > > > > James Gould > Fellow Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > > > From: Jasdip Singh <[email protected]> > Date: Friday, December 9, 2022 at 9:02 AM > To: "Gould, James" <[email protected]>, Jody Kolker > <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" > <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: [EXTERNAL] Re: [regext] Review of draft-ietf-regext-rdap-redacted-09 > Resent-From: <[email protected]> > Resent-To: David Smith <[email protected]>, Roger Carney > <[email protected]>, James Gould <[email protected]>, Jody Kolker > <[email protected]> > Resent-Date: Friday, December 9, 2022 at 9:02 AM > > > > Hello James, > > > > Since we are trying to get away for the placeholder text "XXXX" with this > standards-track proposal, agree option #1 makes sense to discourage such > practice. Further, agree with Jody that returning the "redacted" > rdapConformance should make it ample clear when an RDAP server switches to > the new way. That said, perhaps, we could add a section concerning the > transition from the old way to the new way if that helps clarify. > > > > Thanks, > > Jasdip > > > > From: regext <[email protected]> on behalf of "Gould, James" > <[email protected]> > Date: Friday, December 9, 2022 at 8:38 AM > To: "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [regext] Review of draft-ietf-regext-rdap-redacted-09 > > > > Jody, > > > > I thought adding the transition period to the MUST NOT would provide for some > flexibility for those that need to transition from placeholder redaction to > draft-ietf-regext-rdap-redacted, but I believe a server would implement a > hard cutover (e.g., supporting the draft with no other form of redaction). > With that in mind, I’ll modify option 1 to be simply MUST NOT without any > reference to a transition period. > > > > 1. Keep MUST NOT – The Section 3 sentence is “The use of placeholder > text for the values of the RDAP fields, such as the placeholder text "XXXX", > MUST NOT be used for redaction.”. > > 2. Change MUST NOT to SHOULD NOT – This enables the draft to recommend that > placeholder text not be used for redaction, but still enable the server to > support it in parallel with the redaction methods defined in the extension. > The Section 3 sentence would become “The use of placeholder text for the > values of the RDAP fields, such as the placeholder text "XXXX", SHOULD NOT be > used for redaction.”. > > 3. Remove the normative language – Change the Section 3 sentence to “The use > of placeholder text for the values of the RDAP fields, such as the > placeholder text "XXXX", has been used for redaction.”. > > 4. Remove reference to placeholder text use for redaction – Just lead > Section 3 with the sentence “This section covers the redaction methods that > can be used with the redaction signaling defined in Section 4.2.”. > > > > My preference is option 1 (“Keep MUST NOT”), and I agree that if the > normative language cannot remain that option 3 (“Remove the normative > language”) is the best alternative. > > > > Can others from the working group provide their preferred option to address > Pawel’s last open feedback item? All of Pawel’s feedback will be > incorporated in draft-ietf-regext-rdap-redacted-10. > > > > Thanks, > > > > -- > > > > JG > > > > > James Gould > Fellow Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > > > From: Jody Kolker <[email protected]> > Date: Friday, December 2, 2022 at 2:27 PM > To: Pawel Kowalik <[email protected]>, James Gould <[email protected]>, > "[email protected]" > <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: [EXTERNAL] RE: Review of draft-ietf-regext-rdap-redacted-09 > > > > My preference would be that if the server is supporting this draft that > placeholder text is not allowed to be returned for any redacted field. I'm > not sure what a transition period would look like. It seems to me that a > server is either supporting the draft with an "rdapConformance" value of > "redacted" or it's not supporting the draft and does not return the > "redacted" value in the “rdapConformance” value. If "redacted" is returned, > placeholder text should not be used. > > > > I would support option #1 without a transition period. Servers are free to > continue with the responses used today that do not include the “redacted” > “rdapConformance” value if the server is returning placeholder text. One the > draft is supported without placeholder text, the “redacted” “rdapConformance” > value can be returned in the responses. > > > > However, I can live with Option #3 where the RFC acknowledges that > placeholder text has been used in the past. > > > > Thanks, > > Jody Kolker. > > > > From: Pawel Kowalik <[email protected]> > Sent: Friday, November 25, 2022 1:50 AM > To: Gould, James <[email protected]>; > [email protected] > Cc: [email protected] > Subject: Re: Review of draft-ietf-regext-rdap-redacted-09 > > > > Caution: This email is from an external sender. Please do not click links or > open attachments unless you recognize the sender and know the content is > safe. Forward suspicious emails to isitbad@. > > > > Hi James, > > > > Thanks for that. > > My preference would be 3 or 4, to focus the draft on signaling, allowing the > clients to recognize redacted fields. > > > > Kind Regards, > > Pawel > > > > Am 23.11.22 um 16:57 schrieb Gould, James: > > Pawel, > > > > I add responses embedded below with “JG4 – “. > > > > For the WG, I’m including one discussion topic at the top for consideration: > > > > Section 3 currently states “The use of placeholder text for the values of the > RDAP fields, such as the placeholder text "XXXX", MUST NOT be used for > redaction.” Pawel raised an issue with the MUST NOT language and proposed to > use SHOULD NOT. I view the use of placeholder text redaction as an > anti-pattern that should be disallowed when implementing > draft-ietf-regext-rdap-redacted, but I do recognize the potential need for a > transition period. I summarize the options below: > > > > 1. Keep MJST NOT with Transition Period – Formally define the transition > period that is based on server policy in a new Transition Considerations > section. > > 2. Change MUST NOT to SHOULD NOT – This enables the draft to recommend that > placeholder text not be used for redaction, but still enable the server to > support it in parallel with the redaction methods defined in the extension. > > 3. Remove the normative language – Change “The use of placeholder text for > the values of the RDAP fields, such as the placeholder text "XXXX", MUST NOT > be used for redaction.” To “The use of placeholder text for the values of > the RDAP fields, such as the placeholder text "XXXX", has been used for > redaction. …”. > > 4. Remove reference to placeholder text use for redaction – Just lead > section 3 with the sentence “This section covers the redaction methods that > can be used with the redaction signaling defined in Section 4.2.”. > > > > Please respond to the mailing list with your thoughts on the options or if > you have any additional options. My preferred option is option 1 “Keep MJST > NOT with Transition Period”. > > > > Thanks, > > > > -- > > > > JG > > > > > James Gould > Fellow Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > > > From: Pawel Kowalik <[email protected]> > Date: Wednesday, November 23, 2022 at 9:23 AM > To: James Gould <[email protected]>, > "[email protected]" > <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: [EXTERNAL] Re: Review of draft-ietf-regext-rdap-redacted-09 > > > > Hi James, > > My comments below. > > Am 23.11.22 um 14:17 schrieb Gould, James: > > [...] > > JG3 – What triggered the creation of this extension was a proposal to use > placeholder text for redaction, which in my opinion is an anti-pattern that > needs to be directly addressed. I believe that you see the need to support a > transition period that would be up to server policy. See my comment below > related to creating a Transition Considerations section to make this > explicit. The draft can define the methods for redaction, disallow the use > of placeholder text for redaction outside of a transition period, and add > explicit support for a transition period with a set of considerations. Does > this meet your needs? > > [PK3] OK, please include also this part in the Abstract and Introduction, > that the draft also defines certain rules for redaction to mitigate the > anti-patterns, if there is a consensus in WG to mandate how redaction is done. > > > > JG4 – I’m raising the options for discussion in the WG to hopefully find a > consensus option. > > Populating the existing value with a static placeholder value as a signal for > redaction is different from what is defined for the "Redaction by Replacement > Value Method", which changes the value to a non-static value or moves the > location of the value. > > [PK2] I believe it should be perfectly valid to replace one email with > another email (for example privacy proxy email) without moving it, shouldn't > it? For me it would be "Redaction by Replacement Value Method" where both > paths are same. > > JG3 – Yes, use of a privacy proxy email is a form of "Redaction by > Replacement Value Method", since the real value is not being provided but a > replacement value is being used instead. In this case the “method” value is > “replacementValue” and the “replacementPath” is not used. Does this need to > be clarified in the draft, since the intent is to support replacing the value > in place or replacing the value using an alternate field, such as the > replacement with the “contact—uri” property? > > [PK3] Now I see it from examples that replacementPath might be omitted. It > would be good to have some normative text defining that. > > JG4 – Ok, I’ll look to add clarification text. > > > > [...] > > JG3 – Ok, that helps. I believe the biggest issue from a client perspective > is when they expect a non-empty value, and the server implements the > Redaction by Empty Value Method and then returns an empty value. The use of > the placeholder redaction text can be used in parallel with > draft-ietf-regext-rdap-redacted during a transition period. The duration of > the transition period would be up to server policy. What I don’t want to > introduce is parallel forms of redaction for beyond a transition period. How > about including the definition of a transition period in a Transition > Considerations section and updating the MUST NOT language to “The use of > placeholder text … MUST NOT be used for redaction outside of a transition > period defined in Section X . In the Transition Considerations section, it > can define that placeholder redaction text may exist and may overlap with > this extension during a transition period that is up to server policy. Then > there can be a set of considerations for the server and client in making the > transition. I believe this would address the transition more explicitly and > leave the timing of the transition up to server policy. Do you agree? > > [PK3] If the WG is in consensus to keep "MUST NOT" then Transition > Considerations is a good way to cover the smooth transition. > > JG4 – I’m raising the options for discussion in the WG to hopefully find a > consensus option. > > > > [...] > > Another approach would be to define a way of interpreting the JSONPath > > so that it is reversible or even defining a subset of JSONPath which is > > reversible in the narrower RDAP context. > > > > JG2 - I'm not sure what is meant by JSONPath that is reversable. I believe > that JSONPath needs to be used as defined. > > [PK2] Reversable means that you can unambiguously re-create the original > object structure based on the path. Normalized JSONPath have this property > (see 2.8 of JSONPath draft) but may not be the best in case of array members > identified by a property value of array member, like in jCard. The > expressions like $.entities[?(@.roles[0]=='registrant')] can be also > reversible, but this is not true for just any JSONPath expression. If we > would define a narrowed down definition of JSONPath expressions which are > allowed, we could achieve the property of reversibility and maybe even that > one kind of object or property would have exactly one and only possible > JSONPath describing it. Again - it's just an idea how to deal with removed > paths. It may be also not worth following if we assume "redacted name" would > be the leading property (see below). > > > > JG3 – Thanks for the reference, I’ll review it and see whether something can > be used. My initial thought is that it’s going to be too complex and won’t > cover the broad set of use cases in RDAP. Right now, we’ll assume that it > can’t be used in draft-ietf-regext-rdap-redacted, but it’s being reviewed. > > > > In the end, implementing a client, I would rather want to rely on the > > "redacted name" from the "JSON Values Registry" for paths which have > > been deleted, and treating the path member as only informative. > > > > If you agree for such processing by the client I suggest to put it down > > in the chapter 5 (maybe splitting it into server and client side). > > > > JG2 - From a client perspective, I believe I would first key off the > "redacted name" to route my display logic and then I would utilize a template > RDAP response overlaid with the actual response and the JSONPath to indicate > the redacted values. It would be nice to hear from some clients on this to > identify useful client JSONPath considerations. > > [PK2] If I would be implementing the client likely I will do exactly this. > > JG3 – Ok, the “JSONPath Considerations” section will have two subsections of > “JSONPath Client Considerations” and “JSONPath Server Considerations”, where > the above will be the starting JSONPath client consideration. How about the > JSONPath Client Consideration: > > > > When the server is using the Redaction By Removal Method (Section 3.1) or the > Redaction by Replacement Value Method (Section 3.3) with an alternate field > value, the JSONPath expression of the "path" member will not resolve > successfully with the redacted response. The client can first key off the > "name" member for display logic and utilize a template RDAP response overlaid > with the redacted response to successfully resolve the JSONPath expression. > > [PK3] OK > > > > > > [...] > > > > JG2 - Your reference to $.entities[0] is an example of an element in an > array, but its' not referring to a fixed field position of a fixed length > array, such as the case for redacting the "fn" jCard property. There is no > intent to block all cases of redacting objects via the use of an array > position. Is there better language than "using the fixed field position of a > fixed length array" to provide the proper scope? > > OK, now I get it. My proposal would be: "The Redaction by Removal Method MUST > NOT be used to remove an element of an array where position of the elements > in the array determines semantic meaning of the element." > > JG3 – Just a tweak, how about “The Redaction by Removal Method MUST NOT be > used to remove an element of an array where the position of the element in > the array determines semantic meaning.”? > > [PK3] Thanks. > > Kind Regards, > > Pawel > > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext > > -- > Dott. Mario Loffredo > 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 > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
