Hi James, > On 30 Jun 2023, at 12:49, Gould, James <jgould=40verisign....@dmarc.ietf.org> > wrote: > > Ties, > > That paragraph in section 3.1 is meant to state that if an RDAP object is > redacted (e.g., administrative contact), it is redacted in whole, and there > is no need for the server to indicate the redaction of each child of the RDAP > object. The intent of the redaction extension is to make redaction explicit > and to differentiate from non-existence, so it does signal the existence of > an object or member that can't be returned due to redaction.
Ack, that is clear (and as I expected). I will try to rephrase my question: If a optional attribute is not present in the response - but would have been redacted in the response if it was present, would it be present in the “redacted” member? Kind regards, Ties > > Thanks, > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > > On 6/30/23, 4:31 AM, "Ties de Kock" <tdek...@ripe.net > <mailto:tdek...@ripe.net>> 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. > > > Hi all, > > > I have a question after reading draft-ietf-regext-rdap-redacted-13. I am > considering the case of redaction by removal, where an attribute may not be > present in the RDAP response. > > > Consider the case where an extension adds an optional member to a response. > This > optional member is considered for redaction. However, there are two cases, > depending on whether the member was present before redaction. > > > My read of section 3.1 is that the following paragraph, > > > When an RDAP object is redacted by removal, all of the RDAP object's > child fields are also removed. Only the redacted RDAP object needs > to be referenced in the list of redacted fields, as defined in > Section 4.2. > > > Implies that the redaction only needs to be present in the list of redacted > fields if the value is actually redacted. This would allow inferring the > existence of a value for that member – not a privacy leak, but it leaks _some_ > information. > > > Could you clarify the intended behaviour in this case? > > > Kind regards, > Ties de Kock > > > > >> On 29 Jun 2023, at 17:42, Gould, James <jgould=40verisign....@dmarc.ietf.org >> <mailto:40verisign....@dmarc.ietf.org>> wrote: >> >> Jim, >> >> Jasdip Singh's feedback has been incorporated into >> draft-ietf-regext-rdap-redacted-13. I believe that all feedback has been >> addressed. >> >> Thanks, >> >> -- >> >> JG >> >> >> >> James Gould >> Fellow Engineer >> jgo...@verisign.com <mailto:jgo...@verisign.com> >> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com >> <mailto:jgo...@verisign.com>> >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> Verisign.com >> <http://secure-web.cisco.com/1VyP5TFukQ36HdlUYLqzeSTK_XfWBRhQQjhpYQ2JAusV9RCPLdrCVidrPXaFf1VIWECoY1e93sJ0RyPqjH1qaN-XDEIyKO9mybRdOiPckM7EUh4MGVV4FK3lpXzwbDOwGBWDg-fOsobREU-GT6MPJjd38yTc9wFd51NLcKcf_0b5gs1z-9xhRq_kMB_ihKAV_Sdyw1wpuNimEAB6qfmD8Ic4zfgeYU1dEcxrY7kibsc1nW1x6lzA8tAT4yyzh9MXTTjouXSssKrsHjX6mGPdqev3zupsBMJdjgxkuh_f1Ez8/http%3A%2F%2Fverisigninc.com%2F> >> >> <http://secure-web.cisco.com/1VyP5TFukQ36HdlUYLqzeSTK_XfWBRhQQjhpYQ2JAusV9RCPLdrCVidrPXaFf1VIWECoY1e93sJ0RyPqjH1qaN-XDEIyKO9mybRdOiPckM7EUh4MGVV4FK3lpXzwbDOwGBWDg-fOsobREU-GT6MPJjd38yTc9wFd51NLcKcf_0b5gs1z-9xhRq_kMB_ihKAV_Sdyw1wpuNimEAB6qfmD8Ic4zfgeYU1dEcxrY7kibsc1nW1x6lzA8tAT4yyzh9MXTTjouXSssKrsHjX6mGPdqev3zupsBMJdjgxkuh_f1Ez8/http%3A%2F%2Fverisigninc.com%2F>> >> >> >> >> >> >> On 6/26/23, 10:49 AM, "regext on behalf of James Galvin" >> <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> >> <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>> on behalf >> of gal...@elistx.com <mailto:gal...@elistx.com> <mailto:gal...@elistx.com >> <mailto:gal...@elistx.com>>> 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. >> >> >> Thanks for this Andy. Very helpful. >> >> >> The Chairs would very much appreciate other comments regarding whether or >> not to actually delay the redacted draft based on the format discussion. >> >> >> Note that we’re “waiting” now on the shepherd process regardless, but if the >> WG can resolve this question of “delay” before the shepherd is done we’ll be >> able to move this document along as soon as it’s ready. >> >> >> Thanks! >> >> >> Antoin and Jim >> >> >> >> >> >> >> On 26 Jun 2023, at 10:38, Andrew Newton wrote: >> >> >>> On Mon, Jun 26, 2023 at 9:49 AM James Galvin <gal...@elistx.com >>> <mailto:gal...@elistx.com> <mailto:gal...@elistx.com >>> <mailto:gal...@elistx.com>>> wrote: >>>> >>>> 2. Andy Newton needs to confirm on the list that all of his concerns have >>>> been addressed. Tom Harrison has already indicated that his concerns have >>>> been addressed. >>> >>> My apologies. I confirm my concerns have been addressed. >>> >>>> >>>> The Chairs would also like to note that given the new discussion regarding >>>> jCard vs jsContact vs SimpleContact, that we will be delaying the actual >>>> submission of this document to the IESG until that discussion resolves. It >>>> seems prudent to make sure there is no impact to the “redacted” document >>>> as a result of the format discussion before we submit it to the IESG. >>>> >>> >>> I appreciate the prudence, and practically it may not matter if >>> submission to the IESG is delayed given the dependency on JSONPath and >>> IESG workload. That said, I do not believe this is necessary. Let me >>> explain. >>> >>> Much of the complexity in the RDAP redaction spec has to do with >>> getting around weird things in jCard, but as Marc has pointed out, >>> jCard will be with us for the foreseeable future. Though I strongly >>> suspect redaction will be easier with a theoretical SimpleContact, it >>> could be quite some time before we know that. And the RDAP redaction >>> spec covers more than contact data, so it is useful outside of the >>> contact data discussions. >>> >>> The complications with redaction with regard to JSContact center >>> around client processing of JSContact patch objects before, after or >>> during client processing of the redaction directives. This is >>> something the JSContact drafts could specify without need to modify >>> the RDAP redaction, IMHO. I believe the UID issue has been resolved. >>> Finally, JSContact may take some time to get to the publication point >>> considering its dependency. >>> >>> That's my opinion. Maybe others see it differently. >>> >>> -andy >> >> >> _______________________________________________ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org >> <mailto:regext@ietf.org>> >> https://secure-web.cisco.com/1tYf0mCBZUnEmTi2UWGO_5nbBOq4S5uK2pKN0rpsuTEU4dxpnhBvY4TNF_yUEAnIpZySu3fRKKTMixhF6hZzlb3loO4EKp7wThXhVdDCFsYk62VD8Or5C2p_7Jz7-0kpj64vJa9QMenWqDgwqRTUgkXQYEA4DlBH4RHGOAdDmpFHlftJ7ggffOqXGBnQs5E6H8uLq6qYtB9qUPE5UnwhMKP0zuJvdDRqmRuz9h2b-cpFY37UNYVZ5Vmomb4C1IZvQWQ7V0bjaTrM8ng7ic8W1VpXx2q1DuGZBq33KO6jq66c/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >> >> <https://secure-web.cisco.com/1tYf0mCBZUnEmTi2UWGO_5nbBOq4S5uK2pKN0rpsuTEU4dxpnhBvY4TNF_yUEAnIpZySu3fRKKTMixhF6hZzlb3loO4EKp7wThXhVdDCFsYk62VD8Or5C2p_7Jz7-0kpj64vJa9QMenWqDgwqRTUgkXQYEA4DlBH4RHGOAdDmpFHlftJ7ggffOqXGBnQs5E6H8uLq6qYtB9qUPE5UnwhMKP0zuJvdDRqmRuz9h2b-cpFY37UNYVZ5Vmomb4C1IZvQWQ7V0bjaTrM8ng7ic8W1VpXx2q1DuGZBq33KO6jq66c/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> >> >> <https://secure-web.cisco.com/1tYf0mCBZUnEmTi2UWGO_5nbBOq4S5uK2pKN0rpsuTEU4dxpnhBvY4TNF_yUEAnIpZySu3fRKKTMixhF6hZzlb3loO4EKp7wThXhVdDCFsYk62VD8Or5C2p_7Jz7-0kpj64vJa9QMenWqDgwqRTUgkXQYEA4DlBH4RHGOAdDmpFHlftJ7ggffOqXGBnQs5E6H8uLq6qYtB9qUPE5UnwhMKP0zuJvdDRqmRuz9h2b-cpFY37UNYVZ5Vmomb4C1IZvQWQ7V0bjaTrM8ng7ic8W1VpXx2q1DuGZBq33KO6jq66c/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> >> >> <https://secure-web.cisco.com/1tYf0mCBZUnEmTi2UWGO_5nbBOq4S5uK2pKN0rpsuTEU4dxpnhBvY4TNF_yUEAnIpZySu3fRKKTMixhF6hZzlb3loO4EKp7wThXhVdDCFsYk62VD8Or5C2p_7Jz7-0kpj64vJa9QMenWqDgwqRTUgkXQYEA4DlBH4RHGOAdDmpFHlftJ7ggffOqXGBnQs5E6H8uLq6qYtB9qUPE5UnwhMKP0zuJvdDRqmRuz9h2b-cpFY37UNYVZ5Vmomb4C1IZvQWQ7V0bjaTrM8ng7ic8W1VpXx2q1DuGZBq33KO6jq66c/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>> >> >> >> >> _______________________________________________ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> >> https://secure-web.cisco.com/1mG4yno7uRP7SnVJBLlwPgUNRVIcDJnlt0tXVE0VaqfYYu69Id_-cCqN65s4fIxCQ31rO_RfSOvntirc6x0h65QrkA0dxQu8cfXMKlBH7rvVBCbGwhzvcN6p7OZjEsjAtBfjZEzgGvjXpSOKg40yBfFpKiqSs4jz28dSS1KxxUFoblmPNBXuFzCQfKfHEJ-mGzVu7SmqAoElml2B2xx08CP-TqxTKUdWHBb8ylMFuhYeWaGr7TEgp9-xJ1XMdH1SB_mDQ--YK429aI4c7WnUK7shILTcpbGCuFqYn1wfbMiU/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >> >> <https://secure-web.cisco.com/1mG4yno7uRP7SnVJBLlwPgUNRVIcDJnlt0tXVE0VaqfYYu69Id_-cCqN65s4fIxCQ31rO_RfSOvntirc6x0h65QrkA0dxQu8cfXMKlBH7rvVBCbGwhzvcN6p7OZjEsjAtBfjZEzgGvjXpSOKg40yBfFpKiqSs4jz28dSS1KxxUFoblmPNBXuFzCQfKfHEJ-mGzVu7SmqAoElml2B2xx08CP-TqxTKUdWHBb8ylMFuhYeWaGr7TEgp9-xJ1XMdH1SB_mDQ--YK429aI4c7WnUK7shILTcpbGCuFqYn1wfbMiU/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> > > > > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
