Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09

[Brian Haberman <[e-mail]>]

The shepherd's write-up has been updated to align with the draft.

Brian

On 8/5/23 2:01 AM, Eric Vyncke (evyncke) wrote:
> Hello Paul,
> 
> Thanks for your reply, look below for EV2> but, in short, we are all set *except* for the shepherd's write-up .
> 
> Regards
> 
> -éric
> 
> On 05/08/2023, 02:53, "Paul Hoffman" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On Jul 31, 2023, at 8:29 AM, Eric Vyncke (evyncke) <evyncke=[e-mail] <mailto:[e-mail]>> wrote:
>> # Shepherd's write-ip
>>
>>
>> The shepherd's write-up states "the WG would like to ensure that this list remains in the document once it is published as an RFC" but the appendix A states "RFC Editor: please remove this section before publication". I.e., the shepherd's write-up and the I-D MUST be coherent ;-)
>>
>> EV> we do need the shepherd's write-up and I-D being consistent on this point. *Let me know when either the shepherd's write-up or the I-D is modified.*
> 
> 
> You and the shepherd are already discussing this on the mailing list.
> 
> EV2> I guess you meant "we" and not "you", but whatever we need a resolution for this.
> 
>> # Section 1.1
>>
>> I am always uneasy with the use of BCP14 normative language outside of a standard track or BCP document.
>>
>> EV> I have read Paul's reply, as long as authors are aware, let it be. Expect some non-blocking comments by some ADs during the IESG evaluation.
> 
> 
> This is a ripe topic for a statement from the various RFC stream managers so that we document authors will know what to expect. I do hope those comments are non-blocking.
> 
> 
> EV2> of course this is not blocking, sorry if I was not clear.
> 
>> # Section 3
>>
>> This was probably discussed over the mailing list, but must DoT & DoQ replies be also identical to Do53 replies ? The current text is a little underspecified.
>>
>> Paul> The last paragraph of Section 3 says "An authoritative server implementing DoT or DoQ MUST authoritatively serve the same zones over all supported transports." How should we say that differently to be more specfied?
>>
>> EV> I still find the text a little unclear about the returned DNS replies (e.g., the answer section must be identical in Do53 and DoT). I am leaving the choice to the authors about whether to add further clarification text.
> 
> 
> Got it: "serve the same zones" versus "have the same replies". We'll make that change in -10.
> 
> EV2> Thanks
> 
>> # Section 3.5
>>
>> Expect some comments during the IESG review if the SHOULDs do not have some wording about when the SHOULDs does not apply.
>>
>> EV> thanks, Paul, for explaining the somehow convoluted/complex clause "this might be limited by e.g. not receiving an EDNS(0) option in the query". You may consider rendering it easier to parse though.
> 
> 
> Sure, I'll make a run at that for -10 as well.
> 
> 
>> # Section 4.2
>>
>> Is there any chance to also use an IPv6 example ?
>>
>> EV> Obviously, there was no chance ;-)
> 
> 
> We chose to keep the examples consistent with each other.
> 
> EV2> fait enough, though the 2 examples could be IPv6 ;-) (kidding here)
> 
> I'll prep a -10, and we'll submit it next week.
> 
> 
> --Paul Hoffman
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy