Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
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" mailto:paul.hoff...@icann.org>> wrote: On Jul 31, 2023, at 8:29 AM, Eric Vyncke (evyncke) mailto: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. 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 dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy OpenPGP_signature Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
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" mailto:paul.hoff...@icann.org>> wrote: On Jul 31, 2023, at 8:29 AM, Eric Vyncke (evyncke) mailto: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. 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 dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
On Jul 31, 2023, at 8:29 AM, Eric Vyncke (evyncke) 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
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
On Aug 1, 2023, at 16:37, Brian Haberman wrote: > > > As document shepherd... > >> Paul Wouters pointed out on the list (2023-07-02) that Appendix A is not in >> the format from RFC 7942, and is not at all definitive, and thus can be >> removed. > > I got the sense that the WG wanted the list of implementations to remain to > facilitate testing. If that is not the case, I can update the shepherd's > writeup to remove the offending request to retain the list. I didn’t see a good reason to go against the advice of 7942 to remove it. If we had published a list of dns software supporting DoH in a document in 2018, how useful or misleading would that list be at this point? I again recommend to let the RFC editor remove the list before publication. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
Hey Paul, As document shepherd... On 7/21/23 2:56 PM, Paul Hoffman wrote: Substantial bits below; others were accepted withtout note. On Jul 17, 2023, at 5:06 AM, Eric Vyncke (evyncke) 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 ;-) Paul Wouters pointed out on the list (2023-07-02) that Appendix A is not in the format from RFC 7942, and is not at all definitive, and thus can be removed. I got the sense that the WG wanted the list of implementations to remain to facilitate testing. If that is not the case, I can update the shepherd's writeup to remove the offending request to retain the list. Regards, Brian OpenPGP_signature Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
Thank you, Paul, Joey, Daniel, for the -10. As you can guess, I won't have time to review the -10 and the email thread before next week __ Regards -éric On 27/07/2023, 08:18, "Paul Hoffman" mailto:paul.hoff...@icann.org>> wrote: Please see the -10 that was just submitted. Let us know if we need to make more changes before you want to move this on to IETF Last Call. --Paul Hoffman (for dkg and Joey as well) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
Please see the -10 that was just submitted. Let us know if we need to make more changes before you want to move this on to IETF Last Call. --Paul Hoffman (for dkg and Joey as well) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
On Sat, Jul 22, 2023 at 3:27 PM Christian Huitema wrote: > > IF we were serious about the "informational only" status, then we would > [...] > Disagree. Non-standards track RFCs can have these requirements. For example, they may be documents never intended for the standards track (in that they never intend to give the IETF change control), or rejected alternatives. This document does exactly what is called for by RFC 7322: https://datatracker.ietf.org/doc/html/rfc7322#section-4.8.2 thanks, Rob ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
On 7/21/2023 11:56 AM, Paul Hoffman wrote: Substantial bits below; others were accepted withtout note. On Jul 17, 2023, at 5:06 AM, Eric Vyncke (evyncke) 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 ;-) Paul Wouters pointed out on the list (2023-07-02) that Appendix A is not in the format from RFC 7942, and is not at all definitive, and thus can be removed. # Section 1.1 I am always uneasy with the use of BCP14 normative language outside of a standard track or BCP document. I agree with your unease, but it is a long-established tradition in the RFC Series. If the IESG and IAB and ISE want to create new guidance on that... # 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. 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? # Section 3.2 In ` The simplest deployment would simply provide a self-issued, regularly-updated X.509 certificate` is the intent to use short-lived certificates ? Or more to state "valid certificate" ? The text would benefit from clarity. There is no intent for short-lived or long-lived: that's totally up to the deployment. Also, self-issued certificates are not valid, they are only verifiable. # 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. To increase the anonymity set for each response, the authoritative server SHOULD use a sensible padding mechanism for all responses it sends when possible (this might be limited by e.g. not receiving an EDNS(0) option in the query). Specifically, a DoT server SHOULD use EDNS(0) padding [RFC7830] if possible, and a DoQ server SHOULD follow the guidance in Section 5.4 of [RFC9250]. How much to pad is out of scope of this document, but a reasonable suggestion can be found in [RFC8467]. The first SHOULD says it does not apply when not receiving an EDNS(0) option. The second points to the logic in Section 5.4 of RFC 9250. What more could we add? IF we were serious about the "informational only" status, then we would rewrite this to provide information instead of mandating behavior. Something like: An authoritative server that does not use sensible padding mechanisms will probably decrease the anonymity of each response. For DoT, sensible padding mechanism can be implemented using EDNS(0) padding [RFC7830]. For DoQ, padding mechanisms are described in Section 5.4 of [RFC9250]. How much to pad is out of scope of this document, but a reasonable suggestion can be found in [RFC8467]. -- Christian Huitema # Section 4.4 Unsure whether the last paragraph has any value... ` a recursive resolver implementing these strategies SHOULD also accept queries from its clients over some encrypted transport (current common transports are DoH or DoT).` That was requested by the WG. # Section 4.6.10 Only one prioritization scheme in this section while there were two in section 3.4 Section 3 is about authoritative servers, Section 4 is about resolvers. In general, no one gets too concerned about resource exhaustion in resolvers. After the deployment experiemt, maybe that will change. We will turn in the -10 during IETF117. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] AD review of draft-ietf-dprive-unilateral-probing-09
Substantial bits below; others were accepted withtout note. On Jul 17, 2023, at 5:06 AM, Eric Vyncke (evyncke) 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 ;-) Paul Wouters pointed out on the list (2023-07-02) that Appendix A is not in the format from RFC 7942, and is not at all definitive, and thus can be removed. > # Section 1.1 > > I am always uneasy with the use of BCP14 normative language outside of a > standard track or BCP document. I agree with your unease, but it is a long-established tradition in the RFC Series. If the IESG and IAB and ISE want to create new guidance on that... > # 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. 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? > # Section 3.2 > > In ` The simplest deployment would simply provide a self-issued, > regularly-updated X.509 certificate` is the intent to use short-lived > certificates ? Or more to state "valid certificate" ? The text would benefit > from clarity. There is no intent for short-lived or long-lived: that's totally up to the deployment. Also, self-issued certificates are not valid, they are only verifiable. > # 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. To increase the anonymity set for each response, the authoritative server SHOULD use a sensible padding mechanism for all responses it sends when possible (this might be limited by e.g. not receiving an EDNS(0) option in the query). Specifically, a DoT server SHOULD use EDNS(0) padding [RFC7830] if possible, and a DoQ server SHOULD follow the guidance in Section 5.4 of [RFC9250]. How much to pad is out of scope of this document, but a reasonable suggestion can be found in [RFC8467]. The first SHOULD says it does not apply when not receiving an EDNS(0) option. The second points to the logic in Section 5.4 of RFC 9250. What more could we add? > # Section 4.4 > > Unsure whether the last paragraph has any value... ` a recursive resolver > implementing these strategies SHOULD also accept queries from its clients > over some encrypted transport (current common transports are DoH or DoT).` That was requested by the WG. > # Section 4.6.10 > > Only one prioritization scheme in this section while there were two in > section 3.4 Section 3 is about authoritative servers, Section 4 is about resolvers. In general, no one gets too concerned about resource exhaustion in resolvers. After the deployment experiemt, maybe that will change. We will turn in the -10 during IETF117. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
