Obviously, I'm largely in agreement with Willem in this discussion. Let me make a few high level points though.
There are lots of other folks that are in favor of this draft that haven't spoken up yet. I will try to poke them to chime in. I am not in favor of downgrading this draft to Informational. I think we could add language to the draft that does it make it optional, while keeping the Standards Track normative SHOULD language based on the technical analysis of its benefits. Regarding DELEG, yes, I agree that this will make ns-revalidation and other choices moot in the long term, and I think the choice to have the new delegation record authoritative in the parent is a good idea. But I feel that some folks are being way too optimistic about DELEG - usable DELEG infrastructure I'd guess is at least 5 to 10 years (probably closer to the latter). This draft deals with the current structure of the DNS delegation mechanism and where authoritative data resides. One more mundane operational benefit I haven't seen mentioned in this discussion -- since ns-revalidation prefers the authoritative child NS RRset, that puts control of rapidity of NS RRset changes firmly into the hands of the child zone operator. We've had huge problems in the past with some of our DNS vendors routinely messing up (over the course of multiple years sometimes), where we would have to frequently eject one or the other vendor out of the NS RRset and have those changes visible quickly. This is not possible if some of the major TLDs only offer very long unchangeable TTLs and resolvers don't interrogate the child NS RRset. You might argue that this problem could be solved by getting some of those TLDs to offer configurable TTLs, but guess what - we've been talking about that for ages with no significant movement, so other protocol solutions are needed. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
