Re: Update of RFC 2606 based on the recent ICANN changes ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





--On Sunday, June 29, 2008 7:46 PM -0700 Bill Manning <bmanning@xxxxxxx> wrote:


I'm suggesting it would be helpful if there were an RFC
directing IANA   to establish a registry that contains both
labels and rules (e.g, no   all-numeric strings, no strings
that start with 0x and contain   hexadecimal values, the
string 'xn--', the 2606 strings, etc.) that   specify what
cannot be placed into the root zone.  As part of future
IANA actions, any time a protocol defines a new TLD (e.g.,
.local) an   entry should be placed into that registry.

Would there be the downside to this?

	several come to mind...

	heres one.  wrt numeric strings, you have examples of the
ambiguity 	in implementations on -how- to process non-base 10
numbers.  but 	it is clear that hex encoding is -not- tossed
out.  how 'bout octal? 	or base 36?  are numeric string
representations now, after 30 years 	going to be outlawed? if
so, on what basis?

	creating a useful RFC that creates a registry and maintains
it in a timely 	fashion -in this century- seems a bedtime
fable.

The other two things that seem to be getting lost in this discussion is that one can write all of the RFCs one like, but rules like this are ultimately useless unless ICANN agrees to them, presumably via the gNSO, one at a time, and via a PDP process. The odds of the very-commercially-oriented gNSO agreeing to the IETF's being able to pull a name out of the potential namespace by simple IETF consensus (or less) are, IMO, around zilch. Worse, as we move toward IDN TLDs, the odds are high that there will be no practical difference between an IDN gTLD and an IDN ccTLD other than the ability of the operator to shield itself from any potential ICANN enforcement action --even of agreements that were signed to get the domain-- by claiming national sovereignty and the rule that, in general, private bodies can't sue governments without the permission of those governments.

The complementary problem is that, in the present DNS environment in which typing errors are monetized, an effect of a reservation of "example.com" is registration of, e.g., "examlpe.com" and "exmaple.com" as placeholders, perhaps in case they draw enough traffic that someone would like to buy them (the web page for the first of these contains an explicit offer to sell it).

To at least some extent, our reserving a name and (if the use in plain-text examples, rather than, e.g., MIB examples actually drives non-trivial traffic toward those names) publicizing it makes spelling variations of that name more valuable. I don't know if the gNSO would like that or not, but it seems to argue that we should be conservation about what names we reserve and thereby promote.

That has an interesting corollary: to the extent to which domains, especially web sites, consider unexpected access to be a potential profit source, rather than an annoyance, using someone else's domain name in an example may be "welcome free advertising", rather than a "rude intrusion". One can argue against use of those names on either basis, but let's stop pretending that we have complete knowledge of what is going on here and of the consequences of our actions.

Perhaps we should ask ICANN to reserve all single-letter TLDs (in any script) for IETF use. That would make the examples very clear, would avoid driving traffic to alternate sites (since we would "own" all of them) and would constitue a relatively closed list :-)

   john

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]