Dear WG, The WGLC period for draft-ietf-dnsop-server cookies has finished. There are editorial comments that the authors have already addressed. The chairs feel that the draft is ready to move forward.
Thanks for the reviews, — Benno > On 12 Oct 2020, at 11:47, Willem Toorop <wil...@nlnetlabs.nl> wrote: > > Thanks Brian, > > All but one nit resolved in these commits: > > * > https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/commit/db51181a > * > https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/commit/e1e763e8 > > For your convenience, a rendered possible future version of the document > with these changes can be viewed here: > > * > https://raw.githubusercontent.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/master/draft-ietf-dnsop-server-cookies-04.txt > > I've provided a bit more feedback inline below. > > Op 10-10-2020 om 23:13 schreef Brian Dickson: >> >> >> On Fri, Oct 9, 2020 at 8:38 AM Benno Overeinder <be...@nlnetlabs.nl >> <mailto:be...@nlnetlabs.nl>> wrote: >> >> This starts a Working Group Last Call for >> draft-ietf-dnsop-server-cookies. >> >> Current versions of the draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ >> >> The Current Intended Status of this document is: Standards Track >> >> FYI, I will not shepherd this document, as it was written with one >> of my coworkers. >> Tim Wicinski will be Document Shepherd. >> >> Please review the draft and offer relevant comments. >> If this does not seem appropriate please speak out. >> If someone feels the document is *not* ready for publication, please >> speak out with your reasons. >> >> >> I have read the document, and support publication (modulo very minor >> nits that should be fixed). >> >> In addition to these nits, I do have one further suggestion for Section 8. >> >> I'm not sure if it is too late to make such a suggestion, but on reading >> (and thinking about) the spec, >> it could be useful guidance (particularly for clients which may not be >> aware of changes to their Client-IP address): >> >> "o In order to determine that a Server has detected a change to the >> Client-IP, a Client may consider >> a BADCOOKIE error sooner than would be expected from a Server >> Cookie refresh as a signal >> that the Client-IP may have changed, and thus that a new Client >> Cookie should be created for each Server." > > This is too late. For privacy reasons, the server should not be able to > discover that the Client-IP changed so it cannot *track* Clients with > the help of a DNS Cookie. The Client needs to detect source address > changes before it uses it to send out queries. > >> >> Nits: >> Introduction - I believe "provides" should be "provide", to agree with >> the singular "is" of the verb. (Sorry, grammar nit.) >> >> Section 1.1 - I believe all the "Section Section" instances should >> really just be "Section". >> >> Section 4 - "too frequent" -> "too frequently". >> >> Section 4.3 - "in the anycast." -> "in the anycast set." >> >> Section 4.4 - hash calculation, end of first line "Client-IP," -> >> "Client-IP |" > > (from Wikipedia) > SipHash is not actually a cryptographic hash, bot only suitable as > message authentication code: a keyed hash function like HMAC. > > It has the form SipHash(message, key) > > Thanks, > -- Willem > >> >> Section 5 - "anycast group" -> "anycast set"; "us used" -> "is used" >> >> Section 8 - "like for example five minute." -> "for example five minutes." >> >> Brian >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
