RE: Services and top-level DNS names (was: Re: Update of RFC 2606

[Cellario Luca]

UNSUBSCRIBE

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> John C Klensin
> Sent: Tuesday 8 July 2008 15:30
> To: Bill Manning
> Cc: Mark Andrews; ietf@ietf.org
> Subject: Re: Services and top-level DNS names (was: Re: Update of RFC
> 2606
>
>
>
> --On Tuesday, 08 July, 2008 04:28 -0700 Bill Manning
> <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jul 08, 2008 at 01:49:24AM -0400, John C Klensin wrote:
> >>
> >>
> >> --On Monday, 07 July, 2008 12:08 -0700 Bill Manning
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >> >John, do you beleive that DNS host semantics/encoding that
> >> > form the bulk  of the IDN work (stringprep, puny-code,
> >> > et.al.) are applicable -only- in   the context of zone file
> >> > generation or are they also applicable in  configuration
> >> > and acess control for DNS?
> >>
> >> I think I don't understand the question.   RFC 3490 tries to
> >> make a distinction between IDNA-aware and IDNA-unaware
> >> applications and domain name "slots".  The intent is, more or
> >> less, to permit a punycode-encoded string with the prefix
> >> (which the IDNA2008 drafts call an "A-label") to appear
> >> nearly anywhere in the DNS but to expect conversion to and/or
> >> from native characters only in contexts where IDNA is
> >> explicitly applied. Even in zone files, IDNA is generally
> >> applicable only to labels and not to data fields.
> >>
> >> >path/alias expansion/evaluation will be interesting if "."
> >> >is not what 7bit ASCII thinks of as "."
> >>
> >> RFC 3490 lists a series of other characters that are to be
> >> treated as label-separating dots if encountered in an IDNA
> >> context.  That model causes a number of interesting problems
> >> in contexts where one has to recognize a string as a domain
> >> name, and possibly process it, without knowing anything about
> >> IDNA. The problems show up in situations as simple as
> >> conversions between label-dot-label-dot-label format and
> >> length-label list format, making it very important whether
> >> one identifies an FQDN as containing IDNA labels or converts
> >> it to length-label form first.  IDNA2008 (see the IDNABIS WG
> >> and its documents and mailing list) does away with all of
> >> this as part of a general plan to do a lot less mapping of
> >> characters into other characters.  So, for the proposed newer
> >> version the only label-separating dot permitted in the
> >> protocol is the character you know as 7bit ASCII "." (U+002E
> >> in Unicode-speak).
> >>
> >> Does that answer whatever the question was intended to be?
> >>
> >>john
> >>
> >
> > perhaps - let me try again w/ example.
> >
> > in my resolv.conf file, I have the following three lines:
> >
> > search . karoshi.com. ip4.int. ep.net.
> > nameserver 198.32.2.10
> > nameserver 2001:478:6:0:230:48ff:fe22:6a29
> >
> > the line of interest is the first line, starting w/ search.
> > the expectation is that the items on this list are domain
> > names. in my case, they are all "fully qualified".   since
> > this is a  configuration file - not a zone file, is IDNA2008
> > expected to  apply?  this data is not, per se, in the DNS.
>
> Nothing in IDNA2008 makes it apply.  Nothing in IDNA2008 even
> makes it apply to zone files (!).   My personal view --others in
> the WG might have other opinions-- is that one would be better
> off using A-labels (the punycode-encoded forms) in this sort of
> context.
>
> The reasoning involves two points:
>
> * While I don't imagine you would put domain names in
> your search rules that you couldn't render (or easily
> type) on your machine, I believe that will happen with
> some servers who are supporting multilingual
> communities.  The A-labels can be typed and rendered
> accurately on any system that can handle construction of
> the config file (with its ASCII keywords) itself.  The
> U-labels put you at some risk of seeing little boxes or
> question marks (or, in some cases, worse) as well as
> potentially being hard to type.
>
> * An explicit design goal for IDNA (both versions) is to
> avoid changing the DNS or low-level DNS implementations.
> The sear

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John C Klensin]

--On Tuesday, 08 July, 2008 04:28 -0700 Bill Manning
<[EMAIL PROTECTED]> wrote:

> On Tue, Jul 08, 2008 at 01:49:24AM -0400, John C Klensin wrote:
>> 
>> 
>> --On Monday, 07 July, 2008 12:08 -0700 Bill Manning
>> <[EMAIL PROTECTED]> wrote:
>> 
>> >John, do you beleive that DNS host semantics/encoding that
>> > form the bulk  of the IDN work (stringprep, puny-code,
>> > et.al.) are applicable -only- in   the context of zone file
>> > generation or are they also applicable in  configuration
>> > and acess control for DNS?
>> 
>> I think I don't understand the question.   RFC 3490 tries to
>> make a distinction between IDNA-aware and IDNA-unaware
>> applications and domain name "slots".  The intent is, more or
>> less, to permit a punycode-encoded string with the prefix
>> (which the IDNA2008 drafts call an "A-label") to appear
>> nearly anywhere in the DNS but to expect conversion to and/or
>> from native characters only in contexts where IDNA is
>> explicitly applied. Even in zone files, IDNA is generally
>> applicable only to labels and not to data fields.
>> 
>> >path/alias expansion/evaluation will be interesting if "."
>> >is not what 7bit ASCII thinks of as "."
>> 
>> RFC 3490 lists a series of other characters that are to be
>> treated as label-separating dots if encountered in an IDNA
>> context.  That model causes a number of interesting problems
>> in contexts where one has to recognize a string as a domain
>> name, and possibly process it, without knowing anything about
>> IDNA. The problems show up in situations as simple as
>> conversions between label-dot-label-dot-label format and
>> length-label list format, making it very important whether
>> one identifies an FQDN as containing IDNA labels or converts
>> it to length-label form first.  IDNA2008 (see the IDNABIS WG
>> and its documents and mailing list) does away with all of
>> this as part of a general plan to do a lot less mapping of
>> characters into other characters.  So, for the proposed newer
>> version the only label-separating dot permitted in the
>> protocol is the character you know as 7bit ASCII "." (U+002E
>> in Unicode-speak).
>> 
>> Does that answer whatever the question was intended to be?
>> 
>>john
>> 
> 
> perhaps - let me try again w/ example.
> 
> in my resolv.conf file, I have the following three lines:
> 
> search . karoshi.com. ip4.int. ep.net.
> nameserver 198.32.2.10
> nameserver 2001:478:6:0:230:48ff:fe22:6a29
> 
> the line of interest is the first line, starting w/ search.
> the expectation is that the items on this list are domain
> names. in my case, they are all "fully qualified".   since
> this is a  configuration file - not a zone file, is IDNA2008
> expected to  apply?  this data is not, per se, in the DNS.

Nothing in IDNA2008 makes it apply.  Nothing in IDNA2008 even
makes it apply to zone files (!).   My personal view --others in
the WG might have other opinions-- is that one would be better
off using A-labels (the punycode-encoded forms) in this sort of
context.

The reasoning involves two points:

* While I don't imagine you would put domain names in
your search rules that you couldn't render (or easily
type) on your machine, I believe that will happen with
some servers who are supporting multilingual
communities.  The A-labels can be typed and rendered
accurately on any system that can handle construction of
the config file (with its ASCII keywords) itself.  The
U-labels put you at some risk of seeing little boxes or
question marks (or, in some cases, worse) as well as
potentially being hard to type.

* An explicit design goal for IDNA (both versions) is to
avoid changing the DNS or low-level DNS implementations.
The search rule interpreter in your resolver is going to
have to substitute names in that can be used in the DNS
and those are the A-labels.  Putting U-labels in the
config file would requires that the resolver be
IDNA-aware, understand those labels, and map them to the
A-label form before doing lookups.  It would also
presumably require doing that every time the config file
is read, a small decrement in efficiency.

Now, to give you a slightly different answer, I sort of expect
that communities who use IDNs a lot, especially those for whom
typing ASCII is uncomfortable, will find that IDNs drive them
toward "compilers" or special user interfaces to aid them in
producing all sorts of config files.  I'd expect them to develop
tools to permit constructing zone file and resolver config file
templates with IDN U-labels in them and then translating them
into DNS-internal forms (i.e., with the A-labels).  I'd even
expect such tools to provide screen interfaces that permit
working with the keywords of the config files without having to
type them out (a process that gets error-prone if words like
"searc

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Bill Manning]

On Tue, Jul 08, 2008 at 01:49:24AM -0400, John C Klensin wrote:
> 
> 
> --On Monday, 07 July, 2008 12:08 -0700 Bill Manning
> <[EMAIL PROTECTED]> wrote:
> 
> > John, do you beleive that DNS host semantics/encoding that
> > form the bulk   of the IDN work (stringprep, puny-code, et.al.)
> > are applicable -only- inthe context of zone file generation
> > or are they also applicable in  configuration and acess
> > control for DNS?
> 
> I think I don't understand the question.   RFC 3490 tries to
> make a distinction between IDNA-aware and IDNA-unaware
> applications and domain name "slots".  The intent is, more or
> less, to permit a punycode-encoded string with the prefix (which
> the IDNA2008 drafts call an "A-label") to appear nearly anywhere
> in the DNS but to expect conversion to and/or from native
> characters only in contexts where IDNA is explicitly applied.
> Even in zone files, IDNA is generally applicable only to labels
> and not to data fields.
> 
> > path/alias expansion/evaluation will be interesting if "." is
> > not what7bit ASCII thinks of as "."
> 
> RFC 3490 lists a series of other characters that are to be
> treated as label-separating dots if encountered in an IDNA
> context.  That model causes a number of interesting problems in
> contexts where one has to recognize a string as a domain name,
> and possibly process it, without knowing anything about IDNA.
> The problems show up in situations as simple as conversions
> between label-dot-label-dot-label format and length-label list
> format, making it very important whether one identifies an FQDN
> as containing IDNA labels or converts it to length-label form
> first.  IDNA2008 (see the IDNABIS WG and its documents and
> mailing list) does away with all of this as part of a general
> plan to do a lot less mapping of characters into other
> characters.  So, for the proposed newer version the only
> label-separating dot permitted in the protocol is the character
> you know as 7bit ASCII "." (U+002E in Unicode-speak).
> 
> Does that answer whatever the question was intended to be?
> 
>john
> 

perhaps - let me try again w/ example.

in my resolv.conf file, I have the following three lines:

search . karoshi.com. ip4.int. ep.net.
nameserver 198.32.2.10
nameserver 2001:478:6:0:230:48ff:fe22:6a29

the line of interest is the first line, starting w/ search.
the expectation is that the items on this list are domain names.
in my case, they are all "fully qualified".   since this is a 
configuration file - not a zone file, is IDNA2008 expected to 
apply?  this data is not, per se, in the DNS.



-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John C Klensin]

--On Monday, 07 July, 2008 12:08 -0700 Bill Manning
<[EMAIL PROTECTED]> wrote:

>   John, do you beleive that DNS host semantics/encoding that
> form the bulk of the IDN work (stringprep, puny-code, et.al.)
> are applicable -only- in  the context of zone file generation
> or are they also applicable inconfiguration and acess
> control for DNS?

I think I don't understand the question.   RFC 3490 tries to
make a distinction between IDNA-aware and IDNA-unaware
applications and domain name "slots".  The intent is, more or
less, to permit a punycode-encoded string with the prefix (which
the IDNA2008 drafts call an "A-label") to appear nearly anywhere
in the DNS but to expect conversion to and/or from native
characters only in contexts where IDNA is explicitly applied.
Even in zone files, IDNA is generally applicable only to labels
and not to data fields.

>   path/alias expansion/evaluation will be interesting if "." is
> not what  7bit ASCII thinks of as "."

RFC 3490 lists a series of other characters that are to be
treated as label-separating dots if encountered in an IDNA
context.  That model causes a number of interesting problems in
contexts where one has to recognize a string as a domain name,
and possibly process it, without knowing anything about IDNA.
The problems show up in situations as simple as conversions
between label-dot-label-dot-label format and length-label list
format, making it very important whether one identifies an FQDN
as containing IDNA labels or converts it to length-label form
first.  IDNA2008 (see the IDNABIS WG and its documents and
mailing list) does away with all of this as part of a general
plan to do a lot less mapping of characters into other
characters.  So, for the proposed newer version the only
label-separating dot permitted in the protocol is the character
you know as 7bit ASCII "." (U+002E in Unicode-speak).

Does that answer whatever the question was intended to be?

   john


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Bill Manning]

On Mon, Jul 07, 2008 at 12:25:09PM -0400, John C Klensin wrote:
> 
> 
> --On Monday, 07 July, 2008 10:30 +1000 Mark Andrews
> <[EMAIL PROTECTED]> wrote:
> 
> >...
> > If / when MIT stop using ai.mit.edu, "[EMAIL PROTECTED]" will not longer
> > mean [EMAIL PROTECTED]  This will mean that any configuration
> > filethat has "[EMAIL PROTECTED]" will now, suddenly, get a different
> > meaning.This is a latent security issue.
> 
> Mark,
> 
> While I'm basically sympathetic to the position you are taking
> on this, we have recommended for years and years (since the CS.
> incident, if not earlier), that things like configuration files
> use FQDNs and only FQDNs.  SMTP imposes the same requirement on
> addresses in MAIL and RCPT commands.  
> 
> If [EMAIL PROTECTED] is in a config file with the intent of identifying
> [EMAIL PROTECTED] then the config file is broken.Conversely,
> if the config file format is intended to permit references to
> TLDs, I would hope that it would be possible to write "ai." if
> the TLD were intended.
> 
> Personally, I'm very concerned about what users type and what
> happens after that.  For configuration files and the like, I
> believe that we have a case of bad design if the interpretation
> of the configuration is dependent on things outside the scope of
> that file and, in particular, if there is a dependency on DNS
> search procedures rather than one explicit FQDNs.
> 
> Quoting from your comment about Firefox, "Two wrongs don't make
> a right.  They just make two things that need to be fixed."
> 
> john
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

John, do you beleive that DNS host semantics/encoding that form the bulk
of the IDN work (stringprep, puny-code, et.al.) are applicable -only- in
the context of zone file generation or are they also applicable in 
configuration and acess control for DNS?

path/alias expansion/evaluation will be interesting if "." is not what
7bit ASCII thinks of as "."

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606)

[Olivier MJ Crepin-Leblond]

In an earlier message,  John C Klensin <[EMAIL PROTECTED]> wrote:


Part of the problem in that case was that, because JANET used
little-endian names internally, the big-endian foo.ucl.ac.uk (in
DNS order) had to be be mapped into uk.ac.uck.foo (in JANET
order) and vice versa.  That mapping was trivial as long as one
could run a simplistic "whichever end the TLD was on had to be
the big side" test.  When "CS" was introduced, blew up that
simple test.  In the JANET case, it failed since there were
strings that could be TLDs at both ends of the string, i.e., in
principle, cs.ucl.ac.uk could have been a string that was
already in JANET order and that would appear in the DNS order as
uk.ac.ucl.cs.


I tried getting Peter Kirstein to comment on this, but he's unfortunately 
currently away, so I'll voice my own opinions here and please bear with me 
because Peter's knowledge far exceeds mine. After all, I was only a terrible 
teenager at the time.


IMHO you cannot compare today's challenges with the way things were handled 
in 1989 or so...


JANET was using NRS, not DNS. NRS was a static mapping of UK computer 
addresses in NRS format, ie. UK.AC.SOMEPLACE.SOMECOMPUTER to X.3 PAD numbers 
accessed over X.25. NRS pre-dated the DNS. Getting e-mail in and out of the 
UK made use of several gateways that on the UK side we need to know, and on 
the other end of the line people either needed to know, or you'd send to a 
gateway that would know.


There were several gateways in the UK:

EARN RELAY - located at Rutherford Appleton Labs as a path to BITNET (UKACRL 
node)

EAN RELAY - to X.400 & other European Networks
UK.AC.UCL.CS.NSS - the precursor to nsfnet-relay.ac.uk  - satellite link to 
the Internet

UK.AC.UKC - University of Kent at Canterbury's UUCP service

Back in those days, you could route your email specifically - something 
which very few mailers allow today.

For example, I could send email to an Internet address [EMAIL PROTECTED] as:
To: [EMAIL PROTECTED]

or

to: [EMAIL PROTECTED]  (this one crossing the pond via 
BITNET & bridging to the Internet via cuny)


Note that the NSS Relay used to reverse the addressing automatically. In the 
early days, it used to try and check which way the addressing was. Then came 
CS and you are correct in saying that it caused problems. But the problems 
were not nearly as serious as you say. Rules were changed that you simply 
needed to write the address in the correct order for your email to be 
delivered.


For those that have a historical interest (and would perhaps like to get 
inspired technically to resolve possible future problems with gTLDs), I 
suggest you read the excellent document written by Tim Clark of Warwick 
University back in those days. It used to be my email bible for quite a 
while and a few copies still float around the net.
You can find a dusty copy here: 
http://iubio.bio.indiana.edu/soft/help/old/email-gateways.txt


Last but not least, IMHO the issue of [EMAIL PROTECTED] is a non issue. I think we need 
to come to terms that the age of a resolver trying out every known local 
domain/sub-domain is dying out. From now on, you'll need to provide an exact 
host/domain name. It is not the first and not the last habit to die on the 
Internet. Take bang! paths, for example: dead. hostname.uucp - dead. And I 
also think that what web browsers try to do by suggesting a page when you 
just type "somefooplace" -> opens somefooplace.com is also a "feature" that 
will need to die to ensure stability. There are simply too many 
"somefooplace" on the internet, and now "somefooplace" might even be 
.somefooplace
Or ISPs might even resolve locally "somefooplace" to "somefoobarplace" - 
clearly there is no limit to foo.


Warm regards,

Olivier

--
Olivier MJ Crepin-Leblond, Ph.D.
E-mail:<[EMAIL PROTECTED]> | http://www.gih.com/ocl.html
http://www.nsrc.org/codes/country-codes.html

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John C Klensin]

--On Monday, 07 July, 2008 10:30 +1000 Mark Andrews
<[EMAIL PROTECTED]> wrote:

>...
>   If / when MIT stop using ai.mit.edu, "[EMAIL PROTECTED]" will not longer
>   mean [EMAIL PROTECTED]  This will mean that any configuration
> file  that has "[EMAIL PROTECTED]" will now, suddenly, get a different
> meaning.  This is a latent security issue.

Mark,

While I'm basically sympathetic to the position you are taking
on this, we have recommended for years and years (since the CS.
incident, if not earlier), that things like configuration files
use FQDNs and only FQDNs.  SMTP imposes the same requirement on
addresses in MAIL and RCPT commands.  

If [EMAIL PROTECTED] is in a config file with the intent of identifying
[EMAIL PROTECTED] then the config file is broken.Conversely,
if the config file format is intended to permit references to
TLDs, I would hope that it would be possible to write "ai." if
the TLD were intended.

Personally, I'm very concerned about what users type and what
happens after that.  For configuration files and the like, I
believe that we have a case of bad design if the interpretation
of the configuration is dependent on things outside the scope of
that file and, in particular, if there is a dependency on DNS
search procedures rather than one explicit FQDNs.

Quoting from your comment about Firefox, "Two wrongs don't make
a right.  They just make two things that need to be fixed."

john


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Jaap Akkerhuis]

Historical note...

To confirm this:

The introduction of "cs" caused more general problems, unrelated
to name ordering, because there were systems all over the
network in computer science departments with FQDNs like
host.cs.someuniversity.edu.  It was common in many of those
institutions to set up university-wide search rules so that a
reference to host.cs would do the right thing, just like
host.physics, host.philosophy, and so on.  When "CS" was
introduced as a TLD, "host.cs" suddenly became ambiguous (or at
least dependent on exactly how the search rules were set up) as
to whether it represented "host.cs." or
"host.cs.someuniversity.edu.".

Being at one of the major connections to JANET (mcvax was connected to
Canterbury, which was the first gateway trying compensate for the JANET
order (uk.ac.foo) I vividly remember the day that loads of traffic was
forwarded to cs.vu.nl .

And, that, if my memory is correct, was the beginning of our
understanding that search rules needed to be used with great
care, if at all, and that incomplete domain names should not be
sent on the wire as part of protocols.

Since that day I stopped using a search path for dns I could avoid it.

jaap
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Mark Andrews]

> > Again you are asserting that no one has ever been effected.
> 
> No, I'm saying that you can only cry wolf so many times.
> 
> The disaster you are predicting has in fact been in progress for over
> a decade, and the mountains of casualties are nowhere to be found.
 
Just because there are no newspaper articles being published
doesn't mean that there are not problems.  There will have
been lots of little incidents over the years.  Each one
will have been cleaned up quietly.

e.g.
A .forward pointing to "[EMAIL PROTECTED]" where host has gone
away but it also matches a tld with a A record.  In most
cases the administator will just remove the .forward and
not bother complaining that the mail was being mis-directed
for a while.

> Someone claiming to be you said:
> 
> >I suspect that other sites that used the names just put up
> >with the pain of renamimg hosts along with the resultant
> >risk of email being misdirected.
> 
> There's at least one well known mail host whose name has matched a TLD 
> with an MX for ten years now.  Did they rename?  Are they losing floods of 
> mail to the Caribbean?  Uh, well, if they are, they're not telling anyone. 
> How do we explain this conspiracy of silence?

Well if they wanted to email [EMAIL PROTECTED] then yes.  It's a case
of something has got to give.
 
> Finally, as I presume you're aware, some browsers including Firefox retry 
> with an appended .com if the address you type doesn't resolve, so if you 
> type something like www.pets into your browser, it will find www.pets.com. 
> This means that if ICANN creates new TLDs that match any of the 70 million 
> existing .com domains, users of popular current software will suddenly 
> find that they're not seeing the sites they used to see.  (We're not 
> talking about records at the apex of a TLD here, it's www.blah.com vs. 
> www.blah.)  Should all of the existing .com domain names be reserved as 
> TLDs?  If not, why not?  It's the same problem, only it affects a lot more 
> people.

Firefox's defaults are just plain wrong.  This has been
pointed out multiple times by multiple people.  It's also
easily addressable by the end user.

Set browser.fixup.alternate.enabled to false in about:config.

Two wrongs don't make a right.  They just make two things
that need to be fixed.

Mark

> R's,
> John
> 
> PS to everyone else: I'll stop beating this dead horse now.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John Levine]

Again you are asserting that no one has ever been effected.


No, I'm saying that you can only cry wolf so many times.

The disaster you are predicting has in fact been in progress for over
a decade, and the mountains of casualties are nowhere to be found.

Someone claiming to be you said:


   I suspect that other sites that used the names just put up
   with the pain of renamimg hosts along with the resultant
   risk of email being misdirected.


There's at least one well known mail host whose name has matched a TLD 
with an MX for ten years now.  Did they rename?  Are they losing floods of 
mail to the Caribbean?  Uh, well, if they are, they're not telling anyone. 
How do we explain this conspiracy of silence?


Finally, as I presume you're aware, some browsers including Firefox retry 
with an appended .com if the address you type doesn't resolve, so if you 
type something like www.pets into your browser, it will find www.pets.com. 
This means that if ICANN creates new TLDs that match any of the 70 million 
existing .com domains, users of popular current software will suddenly 
find that they're not seeing the sites they used to see.  (We're not 
talking about records at the apex of a TLD here, it's www.blah.com vs. 
www.blah.)  Should all of the existing .com domain names be reserved as 
TLDs?  If not, why not?  It's the same problem, only it affects a lot more 
people.


R's,
John

PS to everyone else: I'll stop beating this dead horse now.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Mark Andrews]

> > The problem is that [EMAIL PROTECTED] is not globally unique.
> >
> > MIT users will have problems talk to [EMAIL PROTECTED] when "ai" means
> > Anguilla.  The is a current security issue.
> >
> > If / when MIT stop using ai.mit.edu, "[EMAIL PROTECTED]" will not longer
> > mean [EMAIL PROTECTED]  This will mean that any configuration file
> > that has "[EMAIL PROTECTED]" will now, suddenly, get a different 
> > meaning.
> > This is a latent security issue.
> 
> If by "latent" you mean "so obscure that in the ten years that there's 
> been A and MX records at TLDs nobody's been affected" I guess I agree.

Again you are asserting that no one has ever been effected.

By latent, I mean it will cause problems in the future when the
conditions described are met.

Not every action has a immediate consequence.  Some consequences
can happen years after the initial action was taken.

The consequences here are foreseeable but not necessarially
obvious to everyone affected.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John Levine]

The problem is that [EMAIL PROTECTED] is not globally unique.

MIT users will have problems talk to [EMAIL PROTECTED] when "ai" means
Anguilla.  The is a current security issue.

If / when MIT stop using ai.mit.edu, "[EMAIL PROTECTED]" will not longer
mean [EMAIL PROTECTED]  This will mean that any configuration file
that has "[EMAIL PROTECTED]" will now, suddenly, get a different 
meaning.
This is a latent security issue.


If by "latent" you mean "so obscure that in the ten years that there's 
been A and MX records at TLDs nobody's been affected" I guess I agree.


R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Mark Andrews]

> >> As someone else pointed out, there are currently about two dozen TLDs with
> >> A or MX records at the apex.  Some of them have been like that for many
> >> years, and as best I can tell, the Internet has not thereby collapsed.
> >
> > How many label our hosts with two letter domain names?
> 
> Beats me, but since there are several hundred TLDs, it seems to me that 
> the chances are pretty low that everyone in the world has managed to avoid 
> using them as host names.
> 
> > Do you have any evidence that they have not caused problems?
> 
> Hey, you're the one claiming that there's a global disaster in progress of 
> which nobody seems to be aware.  If there's evidence, tell us about it.
> 
> >I suspect that other sites that used the names just put up
> >with the pain of renamimg hosts along with the resultant
> >risk of email being misdirected.
> 
> Perhaps you could start by asking people at ai.mit.edu how long their mail 
> has been unusable.

The problem is that [EMAIL PROTECTED] is not globally unique. 

MIT users will have problems talk to [EMAIL PROTECTED] when "ai" means
Anguilla.  The is a current security issue.

If / when MIT stop using ai.mit.edu, "[EMAIL PROTECTED]" will not longer
mean [EMAIL PROTECTED]  This will mean that any configuration file
that has "[EMAIL PROTECTED]" will now, suddenly, get a different 
meaning.
This is a latent security issue.

> Look, we all know there's an unlimited number of ways one can screw up 
mail and web configuration.  If you put an underscore in the name of a web 
> server, as often as not it sort of works even though it's flatly forbidden 
> by RFCs.  Or if you put an @ or % character in the local part of your 
> e-mail address, it'll fail all over the place even though the RFCs say 
> that's fine.

I don't condone those actions.

If I see someone using underscore in a hostname I tell them
that they have made a error.

As for the % hack.  That should only be processed by the
machines handling the domain to the right of the @ sign.
If I saw a machine mishandling it I would complain to the
owner of the broken machine.

Similarly if "[EMAIL PROTECTED]"@domain failed I'd complain to owner
of the machine that is broken.
 
> Why is this particular configuration issue so uniquely awful that the IETF 
> and ICANN need to tie themselves up in knots about it?  ICANN has plenty 
> of real problems on its plate, like registrars who steal people's names 
> and won't give them back.  This isn't one of them.

This is worse.

The owner of a domain name that has been stolen can go to
the courts to get it back.  The have a remedy path outside
of ICANN.

This is a fundemental attack on the communication infrastruction
of the Internet which is predicated on there being globally
unique names.  It needs to be nipped in the bud before it
gets too bad.

Mark

> Regards,
> John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
> Dummies
> ",
> Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
> "More Wiener schnitzel, please", said Tom, revealingly.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John C Klensin]

Historical note...

--On Sunday, 06 July, 2008 09:34 +1200 Brian E Carpenter
<[EMAIL PROTECTED]> wrote:

>> Beats me, but since there are several hundred TLDs, it seems
>> to me that the chances are pretty low that everyone in the
>> world has managed to avoid using them as host names.
> 
> Back in the early days, when Czechoslovakia existed, and cs.
> was active, I recall cs.ucl.ac.uk causing great difficulty. Of
> course, the difficulty was due to email systems doing
> pragmatic things about JANET formats, before MX records were
> in use. We also had great difficulty, I remember, with
> uk.oracle.com.

Part of the problem in that case was that, because JANET used
little-endian names internally, the big-endian foo.ucl.ac.uk (in
DNS order) had to be be mapped into uk.ac.uck.foo (in JANET
order) and vice versa.  That mapping was trivial as long as one
could run a simplistic "whichever end the TLD was on had to be
the big side" test.  When "CS" was introduced, blew up that
simple test.  In the JANET case, it failed since there were
strings that could be TLDs at both ends of the string, i.e., in
principle, cs.ucl.ac.uk could have been a string that was
already in JANET order and that would appear in the DNS order as
uk.ac.ucl.cs.  While other heuristics could disambiguate that
one (as long as the Czech TLD didn't do deliberately
pathological things), uk.oracle.com illustrates a case in which
none of the heuristics worked -- the string was simply ambiguous
and one had to know, via out-of-band info, whether it was a
JANET or DNS name.

The introduction of "cs" caused more general problems, unrelated
to name ordering, because there were systems all over the
network in computer science departments with FQDNs like
host.cs.someuniversity.edu.  It was common in many of those
institutions to set up university-wide search rules so that a
reference to host.cs would do the right thing, just like
host.physics, host.philosophy, and so on.  When "CS" was
introduced as a TLD, "host.cs" suddenly became ambiguous (or at
least dependent on exactly how the search rules were set up) as
to whether it represented "host.cs." or
"host.cs.someuniversity.edu.".

And, that, if my memory is correct, was the beginning of our
understanding that search rules needed to be used with great
care, if at all, and that incomplete domain names should not be
sent on the wire as part of protocols.

Note that MX had little or nothing to do with any of this unless
MX records were probed as part of trying to disambiguate the
names.

As an aside, we are at some risk of reinventing the "can't quite
figure out which order the label of this domain name are in" as
we introduce IDNs that contain labels in right to left scripts.
Those who are interested in that issue should pay very careful
attention to the IRI spec and to draft-ietf-idnabis-bidi.

 john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Brian E Carpenter]

On 2008-07-06 01:00, John Levine wrote:
...

>> How many label our hosts with two letter domain names?
> 
> Beats me, but since there are several hundred TLDs, it seems to me that
> the chances are pretty low that everyone in the world has managed to
> avoid using them as host names.

Back in the early days, when Czechoslovakia existed, and cs. was
active, I recall cs.ucl.ac.uk causing great difficulty. Of course, the
difficulty was due to email systems doing pragmatic things about
JANET formats, before MX records were in use. We also had great
difficulty, I remember, with uk.oracle.com.

...
> Look, we all know there's an unlimited number of ways one can screw up
> mail and web configuration.  

Right, so let's make that even *more* likely...

   Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John Levine]

As someone else pointed out, there are currently about two dozen TLDs with
A or MX records at the apex.  Some of them have been like that for many
years, and as best I can tell, the Internet has not thereby collapsed.


How many label our hosts with two letter domain names?


Beats me, but since there are several hundred TLDs, it seems to me that 
the chances are pretty low that everyone in the world has managed to avoid 
using them as host names.



Do you have any evidence that they have not caused problems?


Hey, you're the one claiming that there's a global disaster in progress of 
which nobody seems to be aware.  If there's evidence, tell us about it.



   I suspect that other sites that used the names just put up
   with the pain of renamimg hosts along with the resultant
   risk of email being misdirected.


Perhaps you could start by asking people at ai.mit.edu how long their mail 
has been unusable.


Look, we all know there's an unlimited number of ways one can screw up 
mail and web configuration.  If you put an underscore in the name of a web 
server, as often as not it sort of works even though it's flatly forbidden 
by RFCs.  Or if you put an @ or % character in the local part of your 
e-mail address, it'll fail all over the place even though the RFCs say 
that's fine.


Why is this particular configuration issue so uniquely awful that the IETF 
and ICANN need to tie themselves up in knots about it?  ICANN has plenty 
of real problems on its plate, like registrars who steal people's names 
and won't give them back.  This isn't one of them.


Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Mark Andrews]

> >> No. 4 says "Strings must not cause any technical instability." which 
> >> sounds exactly within IETF scope covers the gist of the technical 
> >> aspects of the ietf list discussion.
> 
> > We need "cannot be used in a manner that causes technical
> > instablitity.  Known causes include, but are not limited
> > to, adding A,  and MX records at the zone apex."
> 
> As someone else pointed out, there are currently about two dozen TLDs with 
> A or MX records at the apex.  Some of them have been like that for many 
> years, and as best I can tell, the Internet has not thereby collapsed.

How many label our hosts with two letter domain names?

Do you have any evidence that they have not caused problems?
I suspect that other sites that used the names just put up
with the pain of renamimg hosts along with the resultant
risk of email being misdirected.

> I think we all understand that the use of addresses like http://tld/ and 
> [EMAIL PROTECTED] may be flaky due to bugs in client software, but if someone 
> wants 
> to spend $100 grand on a TLD and install a flaky A or MX, why is that an 
> urgent problem the IETF needs to solve rather than a private issue between 
> the TLD and its registrants?

This sentence indicates that you fail to understand all of the
issues involved.
 
> Also keep in mind that most of those apex records are in ccTLDs over which 
> ICANN and the IETF have no authority, so no matter what the we were to 
> say, they're not going away.

> Regards,
> John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
> Dummies
> ",
> Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
> "More Wiener schnitzel, please", said Tom, revealingly.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John Levine]

No. 4 says "Strings must not cause any technical instability." which 
sounds exactly within IETF scope covers the gist of the technical 
aspects of the ietf list discussion.



We need "cannot be used in a manner that causes technical
instablitity.  Known causes include, but are not limited
to, adding A,  and MX records at the zone apex."


As someone else pointed out, there are currently about two dozen TLDs with 
A or MX records at the apex.  Some of them have been like that for many 
years, and as best I can tell, the Internet has not thereby collapsed.


I think we all understand that the use of addresses like http://tld/ and 
[EMAIL PROTECTED] may be flaky due to bugs in client software, but if someone wants 
to spend $100 grand on a TLD and install a flaky A or MX, why is that an 
urgent problem the IETF needs to solve rather than a private issue between 
the TLD and its registrants?


Also keep in mind that most of those apex records are in ccTLDs over which 
ICANN and the IETF have no authority, so no matter what the we were to 
say, they're not going away.


Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

[John C Klensin]

Bernard,

I'm going to try to respond to both your note and Mark's, using
yours as a base because it better reflects my perspective.

Before I go on, I think the three of us are in agreement about
the situation.  The question is what can (or should) be done
about it.

--On Friday, 04 July, 2008 13:52 -0700 Bernard Aboba
<[EMAIL PROTECTED]> wrote:

>> Not really.  ICANN isn't "selling" single-label domains.  They
>> are selling (and I believe "selling" is probably now the
>> correct term) plain, ordinary, TLD delegations.  If I get one
>> of those and populate the TLD zone only with delegation
>> records, there are no problems with what ICANN has done at
>> all, whether you describe it as a property right or in some
>> other way.  
> 
> Agreed. 
> 
>> On the other hand, if they delegate one and the enterprise
>> that buys it chooses to populate the zone with service
>> records, then ICANN's position will certainly be that any
>> inability to use those service records isn't ICANN's problem
>> -- any more than difficulties using .museum or .aero were
>> ICANN's problem when those to whom those domains were
>> delegated discovered that a lot of applications software
>> thought that the one TLD label of more than three characters
>> was "ARPA".
> 
> Is generic "buyer beware" disclaimer really sufficient here? 
> The problem isn't just "inability to use" -- it's that other
> parties exist  who may claim the usage right, and provide
> citations to RFCs to back up their claim.
> 
> For example, typing http://brooklynbridgepark/ into a browser
> utilizing a resolver compliant with RFC 1536 will bring you to
> the web site of  Brooklyn Bridge Park Conservancy, assuming
> that .org is in your searchlist.

We agree so far, but let me note that 1536 is an informational
document.  We generally don't claim that systems are expected to
be compliant with those.
 
> If ICANN sells the brooklynbridgepark TLD delegation to
> another party who populates the zone with service records,
> should that party expect that http://brooklynbridgepark/  
> will now resolve to their site?  RFC 1536 says "no".  
> 
> Similar problems will occur when the party purchasing the
> brooklynbridgepark TLD  attempts to use the single-label name
> "brooklynbridgepark" for other uses, such as network access.

Yes.  And what I fear is that some applications and
implementations will support services on "brooklynbridgepark" as
a TLD and others will start searching.   Yes, that goes well
beyond "buyer beware".

>> And _that_ situation has a lot more to do about "buyer beware"
>> and understanding of conflicting expectations about use than
>> it does about ownership. 
> 
> Today there is a distinction between types of property rights
> - surface, subsurface, or rights to the air above a property.
> As noted at http://geology.com/articles/mineral-rights.shtml 
> this was not always the case: 
> 
>   If we go back in time to the days before drilling and
> mining, real estate transactions were fee simple
> transfers.  However, once  subsurface mineral production
became 
> possible, the ways in which people own property became
> much more complex.

Sure.  But I know who to call --title insurance companies,
lawyers, judges, etc.-- when your mineral rights intrude on my
surface building rights or vice versa.

> If the analogy holds (and I'm not a lawyer, so I have no idea
> if it does), then we could be talking about a "fee simple"
> transfer in a situation where sub-rights may  be claimed to
> belong to someone else.  

But this gets back exactly to both the rude comments I've been
making about ICANN and the example I tried to construct (not
carefully enough) about a Microsoft TLD.

Let's take the second one first.  Suppose that Microsoft, at a
high corporate level, decided that they wanted to have a TLD
called "microsoft" and that they wanted to attach services to
it.  You would advise against that.  I would advise against
that.  So would others.  We would cite 1535, a number of other
RFCs, and general bad taste.  My assumption is that Microsoft
would give it up -- even if they wanted the domain, they
wouldn't expect to locate services at the top level.  But
suppose some marketing force took over and overwhelmed those
arguments.  The thing that makes Microsoft relevant to this
example is that the company distributes a very popular browser
and a couple of very popular email clients.  Were a corporate
decision to be made to support services on a TLD, at least
services on that one special-case TLD, than that decision could
extend to modifications to those application programs that would
permit access to those services.  

Again, I don't expect that to happen, but it carries over
directly into the main point I'm trying to make, which is that
"property rights" are a relevant metaphor for this situation
only if there is some basis or authority for enforcing those
rights.  As I've pointed out in other contexts recently, the
last few times I've tried to call the

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Mark Andrews]

> 
> 
> John Levine wrote:
> >> The problem isn't just "inability to use" -- it's that other parties
> >> exist who may claim the usage right, and provide citations to RFCs to
> >> back up their claim.
> > 
> > There are several ICANN documents describing the new process that
> > include a set of recommendations to guide the process.  You must have
> > read them, since you are concerned about this proposal.  Do you think
> > that recommendations 3, 4, and 20 are adequate to address this
> > problem?  If not, why not?
> 
> 
> John, et al,
> 
> While I think it entirely appropriate to check whether any of us has a clue 
> about what ICANN is actually doing, I do suggest that reference to a document
>  
> warrants providing a specific citation, particularly when there are so many 
> possible choices at the ICANN cite.
> 
> I'm guessing you mean:
> 
>  798015>
> 
> and specifically the Recommendations table.
> 
> If so...
> 
> No. 3 is about legal infringement.  That seems wholly irrelevant to the scope
>  of 
> IETF work, although I agree that the ietf list thread has started using langu
> age 
> that sounds related.
> 
> No. 4 says "Strings must not cause any technical instability." which sounds 
> exactly within IETF scope covers the gist of the technical aspects of the iet
> f 
> list discussion.

We need "cannot be used in a manner that causes technical
instablitity.  Known causes include, but are not limited
to, adding A,  and MX records at the zone apex."
 
> No. 20 seems to have to do with failing a popularity contest.  Probably a goo
> d 
> escape clause to include, but not all that relevant to our I discussion... I 
> hope.
> 
> Let me stress that I do think language like "claim the usage right" makes No.
>  3 
> sound appropriate, but that the scope of IETF RFCs is technical specification
> s, 
> rather than "rights".  While yes, one can say that reserving a name or 
> proscribing against the use of a name -- such as a single, top-level label as
>  a 
> standalone name -- can be interpreting as declaring a "right", I suggest that
>  an 
> IETF discussion will fare much better by focusing on the technical issues tha
> t 
> lead to the constraints, rather than attempting a quasi-pseudo-meta-legal 
> discussion.
> 
> Simply put:  If an IETF specification has gone through the IETF consensus 
> process and been approved, the requirements and constraints imposed are almos
> t 
> by definition technical requirements.
> 
> Violating one of them invites instability, if only because it invites variabl
> e 
> implementations.  At the least, treating such constraints as subject to creat
> ive 
> interpretation by another body renders all output of the IETF fluid.
> 
> And just to press this to a logical conclusion, albeit not one that seems to 
> be 
> at issue... yet:  If ICANN believes that the IETF has issued a problematic 
> specification, then ICANN needs to ask the IETF to fix it, rather than to hav
> e 
> ICANN, or anyone else, issue a modification/clarification.
> 
> d/
> 
> -- 
> 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

[Mark Andrews]

> So the "problem" isn't whether some string not listed in 2606
> can be allocated, it is how it is used after it is allocated.
> And _that_ situation has a lot more to do about "buyer beware"
> and understanding of conflicting expectations about use than it
> does about ownership. 
> 
> john

I really wish it was *just* "buyer beware".  If http://museum/
only works for some clients and not other then there really
isn't a problem.  By "works" here I mean connects to
83.145.59.103 or nowhere.

The problem is that it isn't just "buyer beware".  If the
buyer adds any records are looked up by search mechanisms
as a part on normal application activity, A,  and MX
are simple examples, then *ALL* the users of the Internet
need to be aware that they are there.

This is a security problem, not a buyer beware problem.

This is a namespace clash and namespace clashes are bad for
many reasons.

Now as far as I can see there are two solutions which attack
the problem from different ends.

1. ban the adding of any records which meet the above criteria.
2. rewrite resolvers to not lookup single labels against the
   root.

Note banning would have to be described is a manner that
didn't preclude the negative advertisement of a service.
It would also have to be writen to exclude records that a
looked up with a prefix added.

Also what is the penalty for adding banned records?

Mark


; <<>> DiG 9.3.4-P1 <<>> museum
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61108
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0

;; QUESTION SECTION:
;museum.IN  A

;; ANSWER SECTION:
museum. 86034   IN  A   83.145.59.103

;; AUTHORITY SECTION:
museum. 22099   IN  NS  ns-ext.vix.com.
museum. 22099   IN  NS  ns1.getty.edu.
museum. 22099   IN  NS  nic.icom.org.
museum. 22099   IN  NS  ns.icann.org.
museum. 22099   IN  NS  nic.museum.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul  5 08:22:30 2008
;; MSG SIZE  rcvd: 162

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[Dave Crocker]

John Levine wrote:

The problem isn't just "inability to use" -- it's that other parties
exist who may claim the usage right, and provide citations to RFCs to
back up their claim.


There are several ICANN documents describing the new process that
include a set of recommendations to guide the process.  You must have
read them, since you are concerned about this proposal.  Do you think
that recommendations 3, 4, and 20 are adequate to address this
problem?  If not, why not?



John, et al,

While I think it entirely appropriate to check whether any of us has a clue 
about what ICANN is actually doing, I do suggest that reference to a document 
warrants providing a specific citation, particularly when there are so many 
possible choices at the ICANN cite.


I'm guessing you mean:



and specifically the Recommendations table.

If so...

No. 3 is about legal infringement.  That seems wholly irrelevant to the scope of 
IETF work, although I agree that the ietf list thread has started using language 
that sounds related.


No. 4 says "Strings must not cause any technical instability." which sounds 
exactly within IETF scope covers the gist of the technical aspects of the ietf 
list discussion.


No. 20 seems to have to do with failing a popularity contest.  Probably a good 
escape clause to include, but not all that relevant to our I discussion... I hope.


Let me stress that I do think language like "claim the usage right" makes No. 3 
sound appropriate, but that the scope of IETF RFCs is technical specifications, 
rather than "rights".  While yes, one can say that reserving a name or 
proscribing against the use of a name -- such as a single, top-level label as a 
standalone name -- can be interpreting as declaring a "right", I suggest that an 
IETF discussion will fare much better by focusing on the technical issues that 
lead to the constraints, rather than attempting a quasi-pseudo-meta-legal 
discussion.


Simply put:  If an IETF specification has gone through the IETF consensus 
process and been approved, the requirements and constraints imposed are almost 
by definition technical requirements.


Violating one of them invites instability, if only because it invites variable 
implementations.  At the least, treating such constraints as subject to creative 
interpretation by another body renders all output of the IETF fluid.


And just to press this to a logical conclusion, albeit not one that seems to be 
at issue... yet:  If ICANN believes that the IETF has issued a problematic 
specification, then ICANN needs to ask the IETF to fix it, rather than to have 
ICANN, or anyone else, issue a modification/clarification.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Services and top-level DNS names (was: Re: Update of RFC 2606

[John Levine]

>Is generic "buyer beware" disclaimer really sufficient here? 

The cost to get a domain from ICANN under the new rules is estimated
to be about $100,000.  Don't you think we can assume that people who
are laying out that kind of money are big boys and girls who will do
adequate due diligence?

>The problem isn't just "inability to use" -- it's that other parties
>exist who may claim the usage right, and provide citations to RFCs to
>back up their claim.

There are several ICANN documents describing the new process that
include a set of recommendations to guide the process.  You must have
read them, since you are concerned about this proposal.  Do you think
that recommendations 3, 4, and 20 are adequate to address this
problem?  If not, why not?

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

[Bernard Aboba]

> Not really.  ICANN isn't "selling" single-label domains.  They
> are selling (and I believe "selling" is probably now the correct
> term) plain, ordinary, TLD delegations.  If I get one of those
> and populate the TLD zone only with delegation records, there
> are no problems with what ICANN has done at all, whether you
> describe it as a property right or in some other way.  

Agreed. 

> On the other hand, if they delegate one and the enterprise that buys it
> chooses to populate the zone with service records, then ICANN's
> position will certainly be that any inability to use those
> service records isn't ICANN's problem -- any more than
> difficulties using .museum or .aero were ICANN's problem when
> those to whom those domains were delegated discovered that a lot
> of applications software thought that the one TLD label of more
> than three characters was "ARPA".

Is generic "buyer beware" disclaimer really sufficient here? 
The problem isn't just "inability to use" -- it's that other parties exist 
who may claim the usage right, and provide citations to RFCs to back up their 
claim.

For example, typing http://brooklynbridgepark/ into a browser utilizing
a resolver compliant with RFC 1536 will bring you to the web site of 
Brooklyn Bridge Park Conservancy, assuming that .org is in your searchlist.

If ICANN sells the brooklynbridgepark TLD delegation to another party who 
populates
the zone with service records,  should that party expect that 
http://brooklynbridgepark/  
will now resolve to their site?  RFC 1536 says "no".  

Similar problems will occur when the party purchasing the brooklynbridgepark 
TLD 
attempts to use the single-label name "brooklynbridgepark" for other uses, such 
as
network access. 

> And _that_ situation has a lot more to do about "buyer beware"
> and understanding of conflicting expectations about use than it
> does about ownership. 

Today there is a distinction between types of property rights - surface, 
subsurface,
or rights to the air above a property.  As noted at 
http://geology.com/articles/mineral-rights.shtml 
this was not always the case: 

  If we go back in time to the days before drilling and  mining, real 
estate transactions 
  were fee simple transfers.  However, 
once  subsurface mineral production became 
  possible, the ways in which people own property became much more complex.


If the analogy holds (and I'm not a lawyer, so I have no idea if it does), then
we could be talking about a "fee simple" transfer in a situation where 
sub-rights may 
be claimed to belong to someone else.  


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

[John C Klensin]

--On Friday, 04 July, 2008 10:49 -0700 Bernard Aboba
<[EMAIL PROTECTED]> wrote:

> 
>> Single label names are local in scope.  Attempting to use
>> them in a global context does not work.  As the names in
>> "." get more interesting the probability of collisions with
>> existing names goes up.  Not many people choose two letter
>> labels for the least significant parts of their host names
>> unless they are choosing their initials.
>> 
>> Single label hostnames are not globally unique.  They SHOULD
>> NOT be used in a context where globally unique names are
>> required.
>> 
>> Mark,
>> 
>> With the understanding that I agree with everything you say
>> above, there are some interesting problems
> 
> Referring to the point Mark is making as a "problem" is a bit
> like saying that someone attempting to sell the Brooklyn
> Bridge has a "problem".  While the potential bridge purchaser
> may in fact very much desire to own the bridge, the "problem"
> is that the seller may not in fact have the right to sell it. 
> 
> That's really at the core of what Mark is arguing -- that
> various RFCs allocate single-label names for local use, and
> therefore that ICANN may not possess the right to sell that
> property to another party. 
> 
>> (1) ICANN is well aware of the problem you mention
>> As I understand it, they have explicitly decided to ignore
>> that problem...
> 
> Someone attempting to sell the Brooklyn Bridge can also
> explicitly decide to ignore the "problem" of whether they in
> fact own it.  That won't make the "problem" go away. 
> 
> In this particular case, we are talking about RFCs that are
> included as requirements for purchase worth billions of
> dollars annually, as well as local names currently in local
> use by hundreds of millions of people. So we're not talking
> about selling a single Brooklyn Bridge here, but many. 
>  
>> (2) Regardless of what some of us may think about the
>> desirability (or not) of associating services with TLD names
> 
> The issue is not "desirability".  Someone might very much
> "desire" to purchase the Brooklyn Bridge.  It has many
> excellent qualities -- it is used by many people over the
> course of a day, it is a registered historical site making it
> of great interest to tourists, etc.   The "problem" is whether
> the seller can establish title. 
>   
>> So, much as I'd like it if we could say "Single label names
>> are local in scope...does not work"
> 
> Mark's point is that several RFCs already say this.  So what
> we have here isn't really an technical argument or one about
> "desirability" -- it's a property rights argument. 

Not really.  ICANN isn't "selling" single-label domains.  They
are selling (and I believe "selling" is probably now the correct
term) plain, ordinary, TLD delegations.  If I get one of those
and populate the TLD zone only with delegation records, there
are no problems with what ICANN has done at all, whether you
describe it a property rights or in some other way.  On the
other hand, if they delegate one and the enterprise that buys it
chooses to populate the zone with service records, then ICANN's
position will certainly be that any inability to use those
service records isn't ICANN's problem -- any more than
difficulties using .museum or .aero were ICANN's problem when
those to whom those domains were delegated discovered that a lot
of applications software thought that the one TLD label of more
than three characters was "ARPA".

So the "problem" isn't whether some string not listed in 2606
can be allocated, it is how it is used after it is allocated.
And _that_ situation has a lot more to do about "buyer beware"
and understanding of conflicting expectations about use than it
does about ownership. 

john





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

[Bernard Aboba]

>Single label names are local in scope.  Attempting to use
>them in a global context does not work.  As the names in
> "." get more interesting the probability of collisions with
>existing names goes up.  Not many people choose two letter
> labels for the least significant parts of their host names
> unless they are choosing their initials.
>
> Single label hostnames are not globally unique.  They SHOULD
> NOT be used in a context where globally unique names are
> required.
> 
> Mark,
> 
> With the understanding that I agree with everything you say
> above, there are some interesting problems

Referring to the point Mark is making as a "problem" is a bit like
saying that someone attempting to sell the Brooklyn Bridge has
a "problem".  While the potential bridge purchaser may in fact very
much desire to own the bridge, the "problem" is that the seller may
not in fact have the right to sell it. 

That's really at the core of what Mark is arguing -- that various
RFCs allocate single-label names for local use, and therefore that
ICANN may not possess the right to sell that property
to another party. 

> (1) ICANN is well aware of the problem you mention
> As I understand it, they have explicitly decided to ignore that problem...

Someone attempting to sell the Brooklyn Bridge can also explicitly
decide to ignore the "problem" of whether they in fact own it. 
That won't make the "problem" go away. 

In this particular case, we are talking about RFCs that are included
as requirements for purchase worth billions of dollars annually, as
well as local names currently in local use by hundreds of millions of
people. So we're not talking about selling a single Brooklyn Bridge
here, but many. 
 
> (2) Regardless of what some of us may think about the
> desirability (or not) of associating services with TLD names

The issue is not "desirability".  Someone might very much "desire"
to purchase the Brooklyn Bridge.  It has many excellent qualities -- it is
used by many people over the course of a day, it is a registered historical
site making it of great interest to tourists, etc.   The "problem" is whether 
the
seller can establish title. 
  
> So, much as I'd like it if we could say "Single label names are
> local in scope...does not work"

Mark's point is that several RFCs already say this.  So what we have
here isn't really an technical argument or one about "desirability" -- it's
a property rights argument. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf