Thanks, this all looks good. I'll send it to Last Call when a new version appears.
-MSK On Fri, Aug 18, 2023 at 7:48 AM Gould, James <jgo...@verisign.com> wrote: > Murray, > > > > Thanks for the review. My feedback is included embedded below. We can > post draft-ietf-regext-rdap-redacted-14 once you agree with the needed > updates. > > > > Thanks, > > > > -- > > > > JG > > > [image: cid87442*image001.png@01D960C5.C631DA40] > > > *James Gould *Fellow Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *regext <regext-boun...@ietf.org> on behalf of "Murray S. > Kucherawy" <superu...@gmail.com> > *Date: *Saturday, August 12, 2023 at 7:38 PM > *To: *"regext@ietf.org" <regext@ietf.org> > *Cc: *"a...@hxr.us" <a...@hxr.us>, Gustavo Lozano < > gustavo.loz...@icann.org>, "regext-cha...@ietf.org" < > regext-cha...@ietf.org> > *Subject: *[EXTERNAL] Re: [regext] Publication has been requested for > draft-ietf-regext-rdap-redacted-13 > > > > AD evaluation: > > Thanks, Andy, for a good shepherd writeup. It would be helpful, even if > it seems redundant or obvious, to include an answer to the question about > why Proposed Standard is the right status for this document. > > > > The first paragraph of Section 3 is a bit confusing; it says you MUST NOT > use any placeholder text as a replacement for a redacted value, and then I > read the next sentence to suggest that there might actually be valid > replacement placeholder text although it might not conform to the expected > syntax. But on a second read, I think you're telling me that the reason > it's MUST NOT is because there could be a syntax mismatch which could upset > parsers. If that's correct, I suggest combining the sentences with > "because" or "since". > > > > JG – You are correct, the format mismatch is one reason for the MUST NOT. > The sentences can be combined to read: > > > > “The use of placeholder text for the values of the RDAP fields, such as > the placeholder text "XXXX", MUST NOT be used for redaction, since the > placeholder text value may not match the format requirements of each of the > RDAP fields and provides an inconsistent and unreliable redaction signal.” > > > > In Section 3.2, why are these two SHOULDs not MUSTs? What's the choice > being offered here, and what guidance should we provide? Same question for > the one in Section 3.3. > > > > JG – I don’t see an issue with changing the SHOULDs in Section 3.2 to > MUSTs, since I don’t see a good alternative approach to what is defined in > the draft. > > > > Doesn't the method of Section 3.4 directly conflict with the MUST NOT in > Section 3 (referenced above)? > > > > JG – No, since the replace value is not pre-defined placeholder text that > meant to signal redaction, such as the use of the placeholder value > “REDACTED”. The replacement value provides a proxy to the real value for > privacy reasons. Technically, it’s not redacted but the redaction > extension is used to signal that the real value has been replaced for use > in visualization or processing by the client. > > > > Also in Section 3.4, s/alternate/alternative/ > > > > JG – Thanks, that will be addressed. > > > > In Section 4.2, for "prePath" and "postPath", this is a JSON path > expression, not a JSON expression, correct? > > > > JG – Yes, you are correct, it is referred to as a JSON path expression > with the “pathLang”. We can replace the references of “JSON expression” > with “JSON path expression”. > > > > In Section 6.2, I suggest being precise: You're talking about the "RDAP > JSON Values" registry. > > > > JG – Yes, it is represented as the “RDAP JSON Values” registry in IANA ( > https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml), > but Section 10.2 of RFC 9083 is titled “JSON Values Registry”. We can > change the reference to “RDAP JSON Values Registry” instead of “JSON Values > Registry” if that is better. > > > > Thanks for including Section 7. > > > > -MSK, ART AD > > > > > > > > On Mon, Aug 7, 2023 at 7:24 AM James Galvin via Datatracker < > nore...@ietf.org> wrote: > > James Galvin has requested publication of > draft-ietf-regext-rdap-redacted-13 as Proposed Standard on behalf of the > REGEXT working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/ > <https://secure-web.cisco.com/18pLSwXz0cjG48M2Qn_T8yCXm83ZXpEU2_mVsTBKnmTjKdryD3L2WvB2edI-62enmTMM6IBkojtaBFnrDGNDF3Iffplhz2vZiJTYyIx8IwNi022-qM4p11O0Y_6xyEORphbIhnyOLkaLVbSj8mVl8H7P34at4L9tAYf_39EtUQECH25XTISFctIuMClGcPqmWXd6ZGbI2dooHOg_lN8vLUh0yKa1wSJhaSpQ97gKLHnZJ9rDQl6HtxG-JHpjvaCip5B4C6-MUqNpVzCuhmbj1HHQ-3BtuynGpUyywWzf6KW1n31kaeDd_onKxTDC4RvpN/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F> > >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
