--On Wednesday, 02 July, 2008 10:45 -0700 Paul Hoffman <paul.hoffman@xxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf