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.
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
