Subject: 2606bis (was: .local)

From: Frank Ellermann <[email-masked]>
Date: Wed, 19 Oct 2005 08:33:08 +0200

> How about adding it to 2606 ?  2606bis could add a note that
> ".local" might be used for local purposes specified elsewhere

There is now a 2606bis draft, but it doesn't mention .local :
<http://ietf.org/internet-drafts/draft-eastlake-2606bis-00>

This memo quotes an agreement between ICANN and VeriSign about
gTLD .net published in 

<http://www.icann.org/tlds/agreements/net/net-registry-agreement-01jul05.pdf>

While that's all fine for gTLD .net and all TLDs with similar
agreements it's somewhat strange for other TLDs:

What's wrong with any "labels at all levels" matching one of
aso, gnso, icann, internic, ccsno, afrinic, apnic, arin,
example, gtld-servers, iab, iana, iana-servers, iesg, ietf,
irtf, istf, lacnic, latnic, rfc-editor, ripe, root-servers ?

Where's the technical problem with one of these strings in an
SLD or elsewhere ?  What's the technical purpose of reserving
these strings everywhere ?  When did all ccTLDs agree to this
arrangement ?  

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.

E.g. it's not obliged to offer a whois server no matter what
ICANN's agreements with other TLDs like .net might say.

For chapter 3.3 the purpose is clear, but xn-- is not more
reserved, it's already used as specified elsewhere.

3.4 is also clear:  FQDN whois.sc is a Bad Thing, because it's
unrelated to a whois server of ccTLD .sc  OTOH one reserved SLD
nic could be good enough for all TLDs, an inflation of reserved
SLD labels doesn't help (?)

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.

What on earth has ISO 3166 to do with SLDs ?  They are ignorant
about ccTLDs as demonstrated by CS.  Numerous SLDs using two
characters, country codes, letters, or else, exist.  If ICANN
doesn't allow this in its agreements it's fine, but where is
the technical reason to prohibit something like http://a9.com
or http://ix.de ?  (Yes, the latter is a legacy case under
DENIC rules, but so far this is no BCP affecting all TLDs.)

                        Bye, Frank

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Oct 2005 06:07:50 -0400

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
<[email-masked]> wrote:

>...

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.

>...
>...

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 19 Oct 2005 16:10:44 +0200

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 19 Oct 2005 21:01:10 +0200

John C Klensin wrote:

> 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.

No problem with that, quite the contrary, but 2606bis would be
an IETF BCP.  "You" drilled me to see a big red blinking WAIT
for each normative reference to an informational RfC.

One potential problem with this draft, it mixes some technical
issues (like xn-- or SLD nic) with legal issues (like label
"iab" anywhere) with oddities (like the two-character SLDs).

> 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

The "public whois server" idea unfortunately escaped some of
them (okay, it's not directly in 1591 ;-).  I'd really welcome
it if ICANN gets a proper RfC number for its ICP-1, apparently
some kind of 1591bis, and similar ICP-? documents.

But that's then still an ICANN document, not an IETF BCP.  The
wild mixture in the -00 draft confuses me.  And reserving the
string "iab" as label everywhere worldwide strikes me as plain
wrong.  Like all the other labels in 3.1 including "example".

There is an iab.de, no idea what it is, but probably nothing
related to "the" IAB.  If I'd start a gnso.webhop.info today
that's my legal problem, it shouldn't affect any IETF BCP.

The pseudo country codes on the ISO 3166 web page with obscure
organizations like EM, EP, EV, etc. are bad enough, let's not
imitate this style for all DNS labels worldwide in an IETF BCP.

Chapter 3.1 in the draft could be moved to an RfC published
by ICANN - and I won't miss it for a second if that ICANN RfC
about reserved labels worldwide is never published.

 [short SLDs]
> 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.

Okay, that's a technical reason, I buy.   So let's say that all
labels (not only SLDs & TLDs) must be at least two characters,
that's a clear and simple rule.

But the stuff about two characters in chapter 3.2 is dubious:

Whatever the governments of AC and CO might think, they can't
dictate which TLDs are allowed to adopt "Commonwealth style"
(my terminology) with SLDs ac and co.  Nothing is wrong with
co.uk, it's no business of Columbia, and nothing is wrong with
ac.za, it's no business of (AC -> SH ->) the UK.  Above all
the ISO 3166 MA has nothing to "allow" about SLDs worldwide.

                       Bye, Frank

---

From: Bill Fenner <[email-masked]>
Date: Wed, 19 Oct 2005 14:40:03 -0700

On 10/19/05, Frank Ellermann <[email-masked]> wrote:
>... to see a big red blinking WAIT

Not if the RFC 3967 procedure is followed ("Clarifying when Standards
Track Documents may Refer Normatively to Documents at a Lower Level.")

  Bill

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Oct 2005 19:17:00 -0400

--On Wednesday, 19 October, 2005 14:40 -0700 Bill Fenner
<[email-masked]> wrote:

> Not if the RFC 3967 procedure is followed ("Clarifying when
> Standards Track Documents may Refer Normatively to Documents
> at a Lower Level.")

Or, of course, we could ask for a Last Call and retroactively
reclassify RFC 1591 as a BCP.  Because there was not even a
serious attempt to solicit or identify community consensus
around the variations that ICANN's ICP-1 introduced into the RFC
1591 norms and definitions, and a large fraction of top-level
domains and others have declined to accept the ICANN version,
1591 probably still does represent a best practice consensus in
most respects.
:-)

    john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 20 Oct 2005 02:17:27 +0200

>1591 probably still does represent a best practice consensus in

The ccTLD community has a BCP under "preparation" for a while and 
globally abides by the version we completed in Dec. 2000. It is 
mainly based on RFC 1591.

There is certainly a need for a liaison between the IETF and the 
ccTLD. However the response of Brian to my proposition to introduce 
the hows at the Luxembourg meeting, shown a confusion between 
Registry Manager's role and community trustee. This is the same 
confusion which mares the relations with ICANN. The comming Tunis 
resolution may help solving this situation. This is why most of the 
proposed additions to RFC 2606bis seem an unwelcome and inappropriate 
debate right now (unless IETF wants to get involved in the 
international network operations).

jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Oct 2005 11:58:00 +0200

We *could* open that can of worms, but a downref really sends
the same message with less work.

    Brian