> -----Original Message----- > From: Paul Hoffman <paul.hoff...@icann.org> > Sent: Tuesday, June 6, 2023 11:05 AM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: dns-privacy@ietf.org > Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WGLC : > draft-ietf-dprive-unilateral- > probing > > 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. > > On Jun 6, 2023, at 7:49 AM, Hollenbeck, Scott <shollenb...@verisign.com> > wrote: > > [SAH] The criteria to conduct the experiment and measure the outcome > > could be documented in the current draft. > > Please propose such criteria. I ask because I feel that the likely criteria > (at least > one resolver implementation, one server implementation, and interop testing > between the two of them) has already been met.
[SAH] I'm thinking about experimentation more in the context of measuring operational impact and not so much as a pass/fail thing. For example: Measurement of CPU and memory use between Do53 and DoT or DoQ. Measurement of query response rates between Do53 and DoT or DoQ. Measurement of server authentication successes and failures. Measurement and descriptions of observed attack traffic, if any. Even if these measurements are operator dependent, this is the kind of experimentation that every name server operator will find invaluable in terms of understanding if/how they can implement and deploy the protocol,. > Or are you saying that, if we include the criteria in the current draft, and > show > that they are met, that we can proceed on standards track without changing > the charter? [SAH] No, because the current intended status is inconsistent with the current charter. That needs to be resolved. > > From there: > > > > Publish experimental RFC. > > Conduct experiment. > > Publish RFCbis I-D to document the results of the experiment with > > informational status for failure or standards track for success. > > See above. [SAH] Noted. If we take a measurement approach, and not a pass/fail approach, we can eliminate the "fail" possibility. > > Assuming success, recharter to publish RFCbis I-D on the standards track. > > Adopt RFCbis I-D as a working group document. > > Working group works to publish RFCbis on the standards track. > > > > Paul is correct in noting that there's more IETF effort associated > > with the above. It's worth making that effort to ensure that the risks > > to critical internet infrastructure are minimized. > > How would you put that (legitimate!) concern into a criterion for the > experiment? [SAH] I'd like to see the experiment described more in terms of measurement as I've described above. It doesn't have to be categorized as pass/fail. Scott _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
