--On Wednesday, 02 July, 2008 10:45 -0700 Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> wrote:
At 9:30 AM -0700 7/2/08, Ole Jacobsen wrote:
But it is still the case that an application for say .local
would need to go through some review process (regardless of
price) which would include input from the IETF ICANN rep. I
see little reason why or how a TLD that would be damaging,
confusing, or otherwise "bad" for the IETF would/could just
"slip through" this process.
Fully agree.
Ole, even those of us who are most skeptical about relying on
ICANN are not concerned about something "slipping through". The
concern is about ICANN weighing the issues and deciding that
what someone "wants to do" and on which they are willing to
spend serious money (or, to put that differently, contribute
serious money to ICANN).
What am I missing here?
That there could/would be others arguing that the IETF is
over-stating the damage from a particular proposal. Anyone who
is willing to pay the exorbitant^W application fee obviously
is willing to defend their choice of name. On something like
.local (and, I predict, ".1"), the counter-argument to
anything the IETF says is "that's possibly true, but not
likely". We can't prove future harm, and they can belittle us
for being "too cautious". They have money behind them, and we
have our reputation. ICANN gets to weigh those two against
each other. This is somewhat parallel to the political process
in most capitalist democracies.
Exactly.
And, in that regard, I draw no comfort from Thomas's comment
about a likely $100K application fee. Assume we have
organizations who are willing to put that sort of money into an
application for a TLD they think would be profitable or
beneficial to themselves... and probably to spend that much
again on lawyers, consultants, etc., to prepare an application
that will get through the system. If they see IETF-imposed
restrictions as being in their way, they are likely to be
willing to put significant energy and resources into sweeping
those restrictions out of the way, using precisely the sort of
"those guys are too conservative" argument Paul posits (or its
relatives "those guys are trying to make policy and disguise it
as an inevitable technical choice" or "the risks are low and
here is our large chunk of money to prove that we think there
are overriding commercial considerations").
Now, for example, I happen to believe that "one-off typing error
is guaranteed to yield a false positive", is a more than
sufficient _technical_ basis to ban single-alphabetic-letter
domains at either the top or second levels and to advise
lower-level domains against their use. Those are technical
grounds based on human interface design and information
retrieval principles, not "the network will break if that is
done". But few of the recommendations or reservations we might
make fall into that network-breaking latter category. Even some
of those that fall closest to the line involve cases that we
could "fix" by modifying our applications protocols to lexically
distinguish between domain names and address literals
(http://[10.0.0.6]/ anyone?).
It is, of course, possible to argue the case for and against
single-letter domains in other ways and reach the conclusion
that the advantages of permitting one-character alphabetic TLDs
far outweigh the possible risks, especially since the end users
who can get hurt by this stuff don't have much practical voice
in ICANN. To someone worried about ICANN's budget, or trying to
make the staff-empire even larger, $2,600,000 or $3,600,000 (26
letters, or 26 letters plus ten digits, times $100K) might
themselves be a powerful argument.
But, should those of us who believe that single-letter domains
are bad news refrain from advocating for that rule because those
who oppose it could use it to discredit other IETF
recommendations that might be more important? I don't know
the answer to that question, but I do know that the IETF has a
lot of trouble making clear decisions when those sorts of
politics start to intrude.
--On Tuesday, 01 July, 2008 09:44 -0700 Dave Crocker
<dhc2(_at_)dcrocker(_dot_)net> wrote:
RFC 1123 section 2.1, especially the last sentence.
Interesting.
I hadn't noticed the implication of that, before, but it seems
to be a pretty clear technical specification that a top-level
domain is not allowed to be a decimal number. Ever.
That's a concrete constraint on what ICANN is permitted to
authorize.
The rather odd phrasing there has been the source of a lot of
discussion in the past in both selected IETF and ICANN circles.
Some of us read it as "TLDs will be alphabetic only -- no
digits", not just "cannot be all digits". The former was
certainly the IANA intent when we were discussing RFC 1591.
But does it apply today? Can ICANN override it? I can assure
you that there are groups within ICANN who believe that they can.
--On Monday, 30 June, 2008 12:29 -0700 David Conrad
<drc(_at_)virtualized(_dot_)org> wrote:
...
Sort of like the concerns about unexpected behavior that
resulted in rejecting UTF-8 labels and coming up with punycode.
...
But the behavior that would occur if that were done wasn't
unexpected or unpredictable at all. We have a good number of
popular applications protocols, starting with SMTP, that insist
that domain names contain labels all of which are in "hostname"
(LDH) form. Anything else is a syntax error, and lots of
implementations support that and check for the error case. We
know that a number of implementations of applications got into
trouble when ICANN allocated TLDs of more than four characters
(without consulting the IETF, by the way). It is really hard
to predict what would happen in some of these other cases,
other than "inconsistent behavior" (resulting from different
implementations interpreting the rules differently).
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf