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/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
