John, Frank,
this draft is dead-ended. But it can seriously hurt the Internet.
I questioned Donald about it, obtaining an incomplete response, about
the 01.txt version having to take obtained responses in consideration.
The management of the IANA name/number issues are out of the IETF
reponsibility (RFC 2860, not quoted by Donald's Draft). This issue is
extermely sensible a few weeks from the Tunis meeting. If it is a
temptative of an individual to interfere in the Internet Governance
debate through a confusion over the Government sovereignty, it would
be a serious mistake.
I suggest we either drop this issue, or we definitly rename ourself
UNTF and be embarked in another IETF DoS. I find there are too many
of them nowadays, all related to the IANA.
jfc
12:07 19/10/2005, John C Klensin wrote:
Frank, I'm going to comment on two of your remarks. My not
commenting on the others does not imply that I agree with you
about them either.
--On Wednesday, 19 October, 2005 08:33 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
>...
> This draft references the informational RfC 1591 as normative.
> So far I thought that 1591 in essence says that the internal
> business of a TLD is, well, its internal business.
First of all, there are a collection of RFCs that were issued by
the IANA that are, indeed, normative. They aren't IETF
Standards because they weren't produced or ratified by the IETF.
It wasn't considered appropriate to ask the IETF to ratify them.
And they aren't BCPs or the equivalent, first because they
weren't IETF documents and second because there was no such
thing at the time. RFC 1591 is one of those documents. If you
want to think about it that way, what makes it normative is that
the operator of every TLD allocated in the pre-ICANN period
agreed to its provisions, including both the "trustee rule" (see
below) and the obligation to insist that any subdomains it
registered accept the same rules.
The "internal business" of a TLD is subject to an obligation to
act as a trustee for the global Internet community and to act in
the best interests of that community. In that context,
agreements about naming conventions and protocols that are
reached through a plausible consensus process really are binding
on all TLDs and, indeed, on all domains. Whether the relevant
authority is willing or able to enforce those norms and
agreements is a separate issue: at worst, the norms and
agreements constitute a guideline about good practices.
>...
> 3.2 prohibits single characters as SLD. What's the technical
> purpose of this prohibition ? It also prohibits two characters
> as SLD unless the government of the corresponding ccTLD, or if
> that doesn't exist the ISO 3166 MA allow it.
>...
The technical purpose for this long-standing restriction is the
avoidance (or minimization) of false positives. If one has
several characters in a string, the odds are (or were) presumed
to be reasonable that a typing mistake (or something equivalent)
would yield a "no domain" answer. If only one character in a
domain name label is permitted, the assumption was that all such
labels would swiftly be taken and the likelihood would be very
high that a single-character typing error would yield a false
positive. That was considered a problem to be avoided a dozen
years ago. It seems to be that in today's more rapacious
Internet, where "traffic concentration" (i.e., registering
domain names with the express purpose of capturing false
positives for a profit) represents the most profitable activity
in the "names market", it is even more important.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf