On Mar 10, 2015, at 6:33 PM, Jim Reid <j...@rfc1035.com> wrote: > On 11 Mar 2015, at 00:08, David Conrad <d...@virtualized.org> wrote: > >> While true, these values will vary over time, location of collection, and >> myriad other reasons, probably including phase of moon. If we're going to >> reserve strings from ever being delegated, I believe we need to come up with >> some rationale beyond "because they showed up a lot at some root servers at >> this point in time." > > In the absence of other objective, measurable data (sigh), going with what's > seen at the root for some arbitrary shapshot(s) on arbitrary date(s) seems to > be the least-worst option. It might even be the only option.
"We have known-bad data; let's go with that." (louder sigh) >> If that is the only criteria, it would be relatively easy to game the stats >> by hiring a few botnet zombies to pump queries with names you'd like to >> reserve with spoofed source addresses. > > The same would no doubt hold for whatever other criteria were chosen. We don't need to be so fatalist. In fact, given that we are talking about a resource where some of the values are worth more than others, we should be much more diligent. There is no reason for us to allow "we starting finding requests for these unassigned TLDs" as a reason to allocate TLDs. For the name ".lan", we can see that it has been used for quite over a decade to have a specific network purpose. We don't have to measure this at the roots: we can see it in examples of documentation for how to (mis-) configure your corporate LAN. That is a good enough reason to reserve it. The three that are in draft-chapin-additional-reserved-tlds-02 (.home, .corp, .mail) have the same property. Adding in ".lan" might help some small part of the (non-)Internet not have problems in the future; allowing Lantam Airlines or the Lansing Airport to have it will possibly cause some damage when it is allocated. > IMO the draft is a reasonable attempt at harm reduction. For some definition > of harm. It seems ICANN's policy-making fora want the IETF to produce a list > of "dangerous" TLD strings (on technical grounds) so that they can point at > some RFC and say everything else can be classed as "safe to delegate". Which > is at best a very misguided approach IMO. And, fortunately, that's not what this draft says. Why impute that? > That ship has already sailed so the WG just has to make the best job it can > of the cards it has been dealt. If anyone here has better ideas on how to do > that, please speak up. Done so. Let's not be careless. > I think it would be prudent to assume any new TLD strings (if there ever are > any after the current round has been processed) are harmful unless the > applicant can prove otherwise to a reasonable standard. But nobody's ever > going to accept that. A rule that cannot be tested is not "prudent". Common, yes, but not prudent. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
