On 2/16/13 6:21 PM, "Joe Abley" <joe.ab...@icann.org> wrote:
>Jason: you didn't ask directly, but if the working group was polled to >determine support for adopting this document, I would say yes and >volunteer to review it. Thanks, Joe, for prodding me to be more explicit! ;-) Yes, that is indeed one of my questions: is this an interesting doc to the WG. I also listed the following open issues in the draft: 1. Determine whether RFC 2119 language should be used or not when describing things like the duration of a NTA. 2. Determine whether this is an individual I-D or a DNSOP WG I-D. 3. Determine whether this is Informational or a BCP. 4. The DNSOP WG should discuss whether a 1 day limit is reasonable, whether a different time (more or less than 1 day, such as 1 hour or 1 week) should be specified, or whether no time should be specified (just a recommendation that it SHOULD generally be limited to X). 5. The DNSOP WG should discuss how to assess when critical DNSSEC deployment mass has been achieved so that this is no longer a common practice. 6. Olafur Gudmundsson has suggested that we may want to consider whether a non validatable RRSIG should be returned or not when a NTA is in place. This was raised in the context of NLnet Labs' DNSSEC-Trigger, which apparently acts like forwarding stub-validator. He said, "The reason for this is if NTA strips signatures the stub-validator thinks it is under attack and may a) go into recursive mode to try to resolve the domain, getting to the right answer the long way. b) Give the wrong error "Missing signatures" instead of the real error. If all the validator does is not to set the AD bit for RRsets at and below the NTA, stub-resolvers (and cascading resolvers) should be happy." - Jason _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
