[Collisions] "controlled interruption" - 127/8 versus RFC1918 space
paul at donuts.co
Mon Jan 13 21:05:55 UTC 2014
On Jan 13, 2014, at 10:30 AM, Warren Kumari <warren at kumari.net> wrote:
> On Mon, Jan 13, 2014 at 10:46 AM, Paul Stahura <paul at donuts.co> wrote:
>> On Jan 13, 2014, at 7:09 AM, Rubens Kuhl <rubensk at nic.br> wrote:
>>>>> Or their helpdesk went into meltdown as zillions of customers complain about getting some weird message about name collisions instead of their usual kitten pictures. From their perspective, somebody else changed something that caused them breakage. I understand that in the US this tends to result in lawsuits. YMMV.
>>>> Yup, exactly -- *someone changed something*. I believe that it is the
>>>> responsibility of the organization who made the change (ICANN) to foot
>>>> the bill. They can recover this from the folk they are making the
>>>> changes for if they like…
>> You say if you write code that has a bug, and it works for years, then some other guy comes along, say the OS manufacturer, or a user, or anyone, and makes a change "out there" that activates the bug, *that other person* is liable and you will be able to somehow force them to foot the bill for your bug? lol!
>>> Considering who made the change is a tripartite division between ICANN, US Government and root zone operator, there are 3 organizations one can sue.
>> IANAL, but wouldn't that be like suing the government when, after new local building codes come out, your house has damage after an earthquake because you built it using the old building code?
> If we are going to play the bad analogy game:
> This is more like your local electricity company deciding to change
> the voltage from 110V to 220V (or the other way round) and then say
> "Oh well..." when non-autoswitching things go Boom or stop working.
Your analogy only works if the system never changed.
The DNS system was made to change. new domain names come and go every day.
And not just millions of SLDs every day, but TLDs too - many (10s? 100?) TLDs have been added over the years.
Since the DNS changes all the time, your analogy does not work.
And by the way, not only does my electricity supplier sometime "surge" electricity way over 110v to my house -they are not liable for when that happens. I buy surge suppressors to reduce my risk.
and also my computer, for example, works with 110v or 220v. But if it only worked on 110, and I stupidly plugged it into a 220v outlet, that is my problem, not the electricity supplier's.
>> You know earthquakes can happen at any time - before or after building code changes.
> Yes, exactly. But this isn't the same thing at all -- if changing the
> building code *caused* an earthquake, presumably you'd be annoyed,
> yes? Delegating a name doesn't just change some rules on how things
> should be done in the future, it perturbs an existing, deployed
Delegating a TLD changes no rules. The real "deployed system" as you call it - is the DNS. Its *designed* to add new TLDs from day-one.
If you deploy software or configurations or names or whatever that does not account for new SLDs or TLDs being added to the DNS from time to time - as they always have - then your stupidity for not accounting for those changes are your problem & your liability. The internet community, like a responsible parent, should strive make as few problems for you as possible (for example, by somehow warning you that your lame naming scheme will/may cause leaks, for example), which we are doing, but in the end, even if we didn't warn you, its your liability, not ICANN's, not the USG, not the root operator's, not your ISPs, not the new registry's. Yours.
>> Name collisions happen every day - for example when .com names expire. They can, and do, happen even in undelegated TLDs. Verizon, for example, returns non-NxD answers for *all* names - .com or .xyzzy - *today*.
> Yes, and folk who travel occasionally plug in things that don't
> autoswitch to $other_country voltage. This doesn't mean that changing
> voltages globally is a fine thing to do...
>> Good luck with that suit.
>>> Collisions mailing list
>>> Collisions at lists.dns-oarc.net
More information about the Collisions