Substantial bits below; others were accepted withtout note. On Jul 17, 2023, at 5:06 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 ;-)
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
