I support adoption of this work. Its a sensible, simple proposal which has immediate benefit, and can be used by anyone to test the ability of their nominated resolver to recognise specific keys, and their trust state.
I believe as a community, at large, we need code deployed into the resolvers in the wild, and we need a document specifying the behaviour we need deployed into those resolvers. We can use this to inform ourselves of operational risk under keychange. We can know as individuals, as organizations what we will see, if keys change. I think this is quite powerful. compared to measurement of what resolvers see, or what authoritatives or roots see, going back to these service-providers themselves. This method informs the client side of the transaction. Thats big. I'm not saying we shouldn't do other things, or measure. I'm saying that this proposal has a qualitative aspect which I think is different, and good. -George On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf <tjw.i...@gmail.com> wrote: > All > > The author has rolled out a new version addressing comments from the meeting > on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > _______________________________________________ > 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
