On Thu, May 03, 2018 at 06:15:49PM +1000, Geoff Huston wrote: > We have submitted -12 of this draft which we believe incorperates the > substantive review comments made during the WG Last Call period that > were posted to the WG Mailing List. > > > Editors: Please take “concern about a description of current > > implementation status” as WGLC input, and consider what you might be > > able to add to the draft to address it. > > We have also taken the implementation comments posted to the WG > mailing list and collected them in a new section titled > "Implementation Experience” in the light of Suzanne’s request > > So we would like to pass this draft back to the WG Chairs at this > point for your review for potential submission as an RFC.
1/ While this is a step in the right direction, I'm not yet entirely impressed by the 'Implementation Experience' section. Is it somehow hard to write an implementation report that describes which implementations comply with the BCP 14 / RFC 8174 terms used in draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some blocker in this regard? 2/ Moving the Walkthrough Example to the end of the document as an appendix has greatly improved the readability of the document. 3/ Section 3 states: "The responses received from queries to resolve each of these names would allow us to infer a trust key state of the resolution environment.". >From what I understand, in today's DNS world we can only reasonably expect to do one query per packet. It is well understood that many operators use BGP-4 anycasting (ECMP), the likes of dnsdist, and/or simple UDP loadbalancers. I think it may be good to document that running 3 queries (in essence 3 independent experiments) may not generate sufficient data to properly infer the state (or any state) of the resolution environment. Each query (as part of a single sentinel data gathering session) may be handled by an entirely different resolver with different keys, contaminating any lookup in the proposed truth tables. Section 4 covers a number of cases where the results are indeterminate. It maybe should be added to Section 4 that the client has no awareness of how the resolver environment is constructed, and thus requiring multiple independent queries to infer state has its downsides. Kind regards, Job _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
