On 16 November 2017 at 00:23, 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 > > I support adoption, and I'm willing to review. This seems like an incredible valuable mechanism.
In fact, I already have some comments/questions: In the last paragraph of section 2, "This mechanism is to be applied only by resolvers that perform DNSSEC validation ..." I seem to recall there was some ambiguity in the signal from RFC 8145 validators caused by some implementations that might send a signal even if they weren't actively validating. I think it would be worthwhile to make this statement stronger and more explicit that an implementation should only enable this mechanism if it is actually configured to validate, and not simply capable of validation. The records being queried seem to be anchored at the root. Given that a server in state Vleg is expected to return A responses that implies that the root zone needs to include these records, but I don't see that stated anywhere.. perhaps I just missed it? At the bottom of section 3, the document gives two definitions for a Vleg response. One seems to be a typo and should be Vold. "A Vleg response pattern says that the nominated key is not yet trusted by the resolver in its own right."
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
