Re: [DNSOP] draft-liman-tld-names-04

[Doug Barton <[e-mail]>]

On 11/25/2010 06:56, Andrew Sullivan wrote:
> On Wed, Nov 24, 2010 at 10:48:19AM -0800, Doug Barton wrote:
>
>>> IETF is supposed to be about interoperability, and if stuff breaks
>>> because we have decided, "We don't care lalalalalala I can't hear
>>> you there isn't a problem," then we ought to be ashamed of ourselves.
>>
>> I am rather specifically NOT claiming that there is no problem, and your
>> attempt here to paint me (and others who agree with this view) as
>> childish/foolish is a borderline ad hominem attack.
>
> You have claimed that there is not a technical problem here, but
> "merely" a policy one.

No, I haven't. I have specifically said, on numerous occasions now, that 
I expect software which does what you yourself described (OBE tests 
about what a TLD is) to break. So sure, let's call that a "technical 
problem."

What I DID say, also on numerous occasions, is that:

1. 1123 does not describe a restriction on the protocol
2. We should not add one
3. The responsibility for dealing with the fallout from the technical 
problem lies within the ICANN policy development process.

> I am arguing that, given that some people
> apparently read 1123 differently than you do, we have a technical
> problem in the narrowest meaning of that term, and that we therefore
> ought to address it.

I have also said that I'm leaning towards the idea that a paragraph 
which addresses the issue is in scope here. Where we differ is that I 
think "address" means "supply a warning" where you think it means "Tell 
people they can't do that."

I think part of the disconnect here is related to something that I ran 
into rather often in my time running IANA. "Back in the day" (e.g., 
during the time period when 1123 was written) you had a handful of 
people who all wore a lot of hats. If you got the right 2 or 3 people 
together in a room you could easily make decisions about almost any 
topic, and those decisions would almost always be right. As the network 
grew and roles/responsibilities differentiated into different people 
and/or organizations that process both became more difficult, and more 
"human;" by which I mean that you started having people becoming more 
interested in making sure that their areas of decision making did not 
become smaller *cough*turfwars*cough*. Now enter ICANN, which was 
scientifically designed to step on everyone's toes, and hilarity ensues.

I've been ruminating on what you, and others have said on this topic and 
I think we've hit one of the relevant icebergs here. For example, from 
your 2010-11-24 post:

> The
> IETF is supposed to be about interoperability, and if stuff breaks
> because we have decided, "We don't care lalalalalala I can't hear
> you there isn't a problem," then we ought to be ashamed of ourselves.

To me that sounds like you think it's the IETF's job to make sure that 
people are not _allowed_ to do something that might cause them (and 
their registrants) problems. I think this view is rooted in good 
motives, and that you (and others) honestly believe that you're doing 
the right thing here by trying to remove bullets from the foot-shooting 
gun.

However my view is that you're wrong on both counts. The policy 
questions regarding TLDs are in ICANN's court now, and because there is 
no protocol reason that TLD labels cannot contain digits, this IS a 
policy question. That doesn't mean that we shouldn't put a big red 
warning label on 1123-clarify, it just means that it's not in our 
bailiwick to say "no."

> Also, if you're going to start throwing around complaints about
> fallacies, you'll want to describe them correctly.  If you really
> think I'm misdescribing your position, it's not an _ad hominem_
> anyway.  It's a straw person.  Moreover, while we're talking about
> fallacies . . .

Um, no. My intent was not to start a debate about labeling logical 
fallacies. My intent was to point out that I do not appreciate your 
attempt to characterize me as a foolish person, and that I do not 
believe that behavior of that nature is appropriate in the IETF. The 
fact that by extension your attempt to make me appear foolish is also an 
attempt to weaken the plausibility of my argument is the fallacy. Feel 
free to label that whatever you want.

>> I will once again point out that if your criteria is "We can never
>> deploy anything new in DNS because something in the installed base will
>> break" then the issue with this draft is moot. We simply will not do
>> IDNs at all, and therefore there is no need for the draft to clarify
>> anything. Oh and btw, are you going to notify Jari and Ralph that we're
>> closing down dnsext, or would you like me to do it?
>
> . . . this is just a slippery slope argument, and not a very good one.

Um, yeah, that's sort of my point. :)  Oh wait, you meant me ....

> Engineering decisions involve trade-offs.  It is quite correct that
> there may well be deployed software that will break when exposed to
> on-the-wire DNS top-level labels that don't strictly conform to the
> RFC 1123 "alphabetic" description.  That doesn't mean that we don't
> deploy such labels: it means we have to make a decision about whether
> the feature is worth the potential cost.

Yes, that is also my point. /me getting confused ....

> I think it is, and I also think that the right thing to do is to
> specify exactly what we are changing and how so that, if something
> breaks, people have something they can read in order to understand
> what is going on.

Ah, now I get it. You're arguing that the protocol restriction did exist 
in the past, and now we're relaxing it, but only slightly. I'm arguing 
that the protocol restriction never existed, and therefore you are 
attempting to create one. My understanding of the support for your 
argument is that "lots of people already believed that this was so." 
(And to be clear, that's not a snark, if I'm wrong feel free to correct 
me.) My point is that we've already blown way past the historical 
restrictions on TLD labels, not once but twice. Therefore attempting to 
assert that a protocol restriction ever existed is both wrong (arguable, 
but moot because ...) and OBE (not arguable).

> Moreover, the class of applications that might be using the heuristic
> about the top-level labels extends far beyond just those things
> actually talking to the DNS.  It's actually that class of software I
> am most concerned about.

Yep, I get it, I have the same concerns, and in fact already lived 
through this exact problem in the early-2000's. Please don't think that 
I do not understand your concern. We are simply reaching different 
conclusions about it.

I (and others) think that the benefits of allowing creativity at the top 
level outweigh the costs of people having to fix old stuff. I thought 
that back in 2000, have always believed it, and will continue to believe 
it because the other side of that coin is that we just don't innovate at 
all "because stuff will break."


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/