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
