On Jul 31, 2023, at 8:29 AM, Eric Vyncke (evyncke) <evyncke=40cisco....@dmarc.ietf.org> 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. > # 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. > # 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. > # 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. I'll prep a -10, and we'll submit it next week. --Paul Hoffman _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
