> On 10 Mar 2022, at 04:53, Murray Kucherawy via Datatracker <[email protected]> > wrote: > > Murray Kucherawy has entered the following ballot position for > draft-ietf-dprive-dnsoquic-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Now THAT is a well done shepherd writeup. > > Thanks for this work, which was an interesting read. It's great to see this > so > quickly on the heels of QUIC itself.
Many thanks for the comments - please see the updates in version -11 which was just published, which we hope address your comments. > > Just a couple of BCP 14 things to point out. In Section 5.4, we have this: > > Clients SHOULD monitor the idle time incurred on their connection to > the server, defined by the time spent since the last packet from the > server has been received. When a client prepares to send a new DNS > query to the server, it will check whether the idle time is > sufficiently lower than the idle timer. If it is, the client will > send the DNS query over the existing connection. If not, the client > will establish a new connection and send the query over that > connection. > > There's a blanket SHOULD, followed by two "will"s. I read those as normative > requirements, even though they don't use BCP 14 language. But that means they > conflict with the SHOULD. IMHO, this needs to be resolved. Agreed - we’ve updated the following ‘wills' to SHOULDs. > > In Section 5.5: > > Clients SHOULD consider potential privacy issues associated with > session resumption before deciding to use this mechanism. [...] > > I find "SHOULD consider" to be far too vague for this to be meaningful. If > I've thought about it, have I met my burden here? There are several things to evaluate here - we’ve updated this text to: “Clients SHOULD consider potential privacy issues associated with session resumption before deciding to use this mechanism and specifically evaluate the trade-offs presented in the various sections of this document. The privacy issues are detailed…" Does that address your concern or can you suggest text? All nits fixed - thanks! Sara. > > Thank you for including Section 7. > > And now, some nits. > > Abstract: > > * "... similar properties to that provided by ..." -- s/that/those/ > > Section 1: > > * "DNS over QUIC is referred here as ..." -- s/referred/referenced/ or > s/referred/referred to/ > > Section 5.2: > > * The second-last paragraph is missing a closing parenthesis. > > > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
