Re: Cogent depeers ESnet

2011-06-18 Thread George B.
On Sat, Jun 18, 2011 at 5:26 PM, Nick Hilliard  wrote:
> Slightly old news, but it looks like Cogent depeered ESnet last week:
>
>>
>> http://www.es.net/news-and-publications/esnet-news/2011/important-status-announcement-regarding-cogent-connectivity/
>
> Current traceroutes indicate that ESnet is reaching Cogent via 6939_1299.
>
> In other news, automatically dropping interconnects at around the time of
> your HQ's close of business while your peering co-ordinator is on vacation
> seems to be the new gold standard.
>
> Nick

I suppose the moral of the story is:  "never single-home to Cogent"



Cogent depeers ESnet

2011-06-18 Thread Nick Hilliard

Slightly old news, but it looks like Cogent depeered ESnet last week:


http://www.es.net/news-and-publications/esnet-news/2011/important-status-announcement-regarding-cogent-connectivity/


Current traceroutes indicate that ESnet is reaching Cogent via 6939_1299.

In other news, automatically dropping interconnects at around the time of 
your HQ's close of business while your peering co-ordinator is on vacation 
seems to be the new gold standard.


Nick




Re: ICANN to allow commercial gTLDs

2011-06-18 Thread John R. Levine

run by agencies of the US government, who knows what will happen in
the future.


I'm not so sure volunteer root operators are in a position to editorialize
and for that to have a positive effect.  ICANN could go down the
path of stating that this causes internet stability  (due to operators
publishing a partial root).


It is not my impression that the volunteer root operators have any great 
love for ICANN.  They have carefully avoided making any agreements with 
ICANN that oblige them to do anything other than notify ICANN if they 
think something interesting is going on.  If the USG operators said 
"sorry, the DOJ anti-trust rules don't allow us to serve a zone with 
.HONDA and .BACARDI", why would the the pressure be on them rather than on 
ICANN?  Nobody outside the ICANN bubble cares about more TLDs.



That would then be sufficient justification to  remove root server
operators from the root zone


How do you propose to do that?  The addresses of the roots are hard wired 
into the config of a million DNS caches around the world.  If it came to 
a fight between ICANN and the root operators, it is hard to see how ICANN 
could win.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly



Re: So... is it time to do IPv6 day monthy yet?

2011-06-18 Thread Owen DeLong

On Jun 18, 2011, at 8:00 AM, Jimmy Hess wrote:

> On Sat, Jun 18, 2011 at 4:31 AM, Mark Andrews  wrote:
>> Not really.  A  record adds 28 octets (a A record takes 16).  Unless
>> you have a lot of name servers most referrals still fall within 512 octets
>> additionally most answers also still fall withing 512 octets.
> 
> I agree.. not that it should be assumed there is no v6 DNS issue.
> With IPv6, the main issue may
> be 'firewalls' and  'boxes in the middle'  silently munging, eating,
> or destroying  responses.
> 
> DNSSEC  and not  is really the reason to have need for EDNS0 or TRUNC
> on validating resolvers.   records should be fine for sane domains.
> 
> consider a referral for   example.com -> subdomain.example.com  with
> 8 nameservers.
> mydomainname.example.com;   and assume you get both  and A
> additional responses.
> 
> Total = 402 octets   -- still safe;  your domain name could be ~100
> characters longer and it would still be fine.
> 
> Header <   2 (id)  + 2 (qr,opcode,aa,tc,rd,ra,z,rcode,qdcount)  + 2
> (ancount)  + 2 (nscount)  + 2 (arcount)
>   = 10 octets
> Authority Section
> ns1.subdomain.example.com.  IN  NS  ns1.subdomain.example.com.   <
> 26name + 2 + 2 + 4 + 2 +   2(pointer) =  36 octets
> ns2.subdomain.example.com.  IN NS  ns2.subdomain.example.com.   <  4
> name + 2(pointer)  + 2 + 2 + 4 + 2 +2(pointer) = 18 octets
> ns3.subdomain.example.com.  IN NS  ns3.subdomain.example.com.   <  4
> name + 2 + 2 + 2 + 4 + 2 + 2 =  18 octets
> ns4.subdomain.example.com.  IN NS  ns4.subdomain.example.com.   <  18 octets
> ns5.subdomain.example.com.  IN NS  ns5.subdomain.example.com.   <  18 octets
> ns6.subdomain.example.com.  IN NS  ns6.subdomain.example.com.   <  18 octets
> ns7.subdomain.example.com.  IN NS  ns7.subdomain.example.com.   <  18 octets
> ns8.subdomain.example.com.  IN NS  ns8.subdomain.example.com.   <  18 octets
> 
> Additional Section
> ns1.subdomain.example.com.  IN   2001:DB8::0<  2(pointer)
> +4TTL+2RDLENGTH+16RDATA =  24 octets
> ns2.subdomain.example.com.  IN   2001:DB8::1< 24 octets
> ns3.subdomain.example.com.  IN   2001:DB8::2< 24 octets
> ns4.subdomain.example.com.  IN   2001:DB8::3< 24 octets
> ns5.subdomain.example.com.  IN   2001:DB8::4< 24 octets
> ns6.subdomain.example.com.  IN   2001:DB8::5< 24 octets
> ns7.subdomain.example.com.  IN   2001:DB8::6< 24 octets
> ns8.subdomain.example.com.  IN   2001:DB8::7< 24 octets
> ns1.subdomain.example.com.  IN A 192.0.0.0.1   <  2(pointer)
> +4TTL+2RDLENGTH+4RDATA =  12 octets
> ns2.subdomain.example.com.  IN A 192.0.0.0.1   <  12 octets
> ns3subdomain.example.com.  IN A 192.0.0.0.1   <  12 octets
> ns4.subdomain.example.com.  IN A 192.0.0.0.1   <  12 octets
> 
> 
> Total = 402 octets   -- still safe;  your domain name could be  ~100
> characters longer and it would still be fine.
> 
This ignores the extra baggage that tends to come along in a DNS payload.

Just the root:

; <<>> DiG 9.6.0-APPLE-P2 <<>> +trace -t any www.delong.com
;; global options: +cmd
.   379756  IN  NS  e.root-servers.net.
.   379756  IN  NS  i.root-servers.net.
.   379756  IN  NS  l.root-servers.net.
.   379756  IN  NS  f.root-servers.net.
.   379756  IN  NS  k.root-servers.net.
.   379756  IN  NS  b.root-servers.net.
.   379756  IN  NS  j.root-servers.net.
.   379756  IN  NS  d.root-servers.net.
.   379756  IN  NS  c.root-servers.net.
.   379756  IN  NS  g.root-servers.net.
.   379756  IN  NS  m.root-servers.net.
.   379756  IN  NS  h.root-servers.net.
.   379756  IN  NS  a.root-servers.net.
;; Received 512 bytes from 192.159.10.2#53(192.159.10.2) in 7 ms


Or the GTLD servers list:

com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
;; Received 495 bytes fr

Re: So... is it time to do IPv6 day monthy yet?

2011-06-18 Thread Owen DeLong
>> 
> 
> Not really.  A  record adds 28 octets (a A record takes 16).  Unless
> you have a lot of name servers most referrals still fall within 512 octets
> additionally most answers also still fall withing 512 octets.
> 
1.  Most != All even in IPv4 (ran into this in a few hotels with some
prominent MMORPG login sites)

2.  512/16 = 32, 512 / 28 = 18 (the 19th record will TRUNC).

So, you get just over half the number of records to fit within
the same space.

I would say that my statement that you are much more likely to
encounter TRUNC results and need a TCP query with IPv6 stands.

It also matches my experience.

Owen




Re: Business Ethernet Services

2011-06-18 Thread Aftab Siddiqui
Try Maipu S3400 series, Chinese boxes and it is working really good
for us fr couple of years.

It would suits ur need n price range.

On Saturday, June 18, 2011, Adrian Minta  wrote:
> On 06/17/11 21:55, Elliot Finley wrote:
>
> Anyone using a CPE that is reliable and costs<= $300 ?
>
> features needed:
>
> SFP for uplink, QnQ, basic layer 2 functionality.
>
> If you're using something with the above parameters and you like it,
> please share. :)
>
> Thanks,
> Elliot
>
>
>
> Something like Zyxel MES-2110 ?
>
>
>
>
>

-- 
Regards,

Aftab A. Siddiqui



Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Jimmy Hess
On Sat, Jun 18, 2011 at 9:55 AM, John Levine  wrote:
> That has always been the case in the past.  Given the level of public
> unhappiness that the US Dep't of Commerce has with ICANN's plan to add
> zillions of new TLDs, and noting that several of the root servers are

Speaking of some public unhappiness with new TLD plan... if you hadn't noticed,
the DoC  published a notice  of inquiry regarding renewal of the ICANN
contract expiring in September
for the IANA functions
http://www.ntia.doc.gov/frnotices/2011/FR_IANA_FurtherNOI_06102011.pdf

If not pleased with ICANN's performance it might be worth reading the
published DRAFT SOW for the renewal from the federal register and
Investigate if the proposed terms seem to provide sufficient
accountability/constraint.

If not,  it would be prudent to submit comments answering the
questions listed in the inquiry :)

Specifically,  regarding  "C.2.2.1.3.2 Responsibility and Respect for
Stakeholders 

For delegation requests for new generic TLDS (gTLDs), the Contractor
shall include documentation to demonstrate how the proposed string has
received consensus support from relevant stakeholders and is supported
by the global public interest.".



> run by agencies of the US government, who knows what will happen in
> the future.

I'm not so sure volunteer root operators are in a position to editorialize
and for that to have a positive effect.  ICANN could go down the
path of stating that this causes internet stability  (due to operators
publishing
a partial root).

That would then be sufficient justification to  remove root server
operators from
the root zone, and use the proceeds of gTLD sales  and gTLD renewal fees
to hire (non-volunteer) operators,  under contract  requiring hired root
operators to publish exactly an ICANN sanctified root.

> R's,
> John
--
-JH



Re: ICANN to allow commercial gTLDs

2011-06-18 Thread John Levine
>I believe the root server operators have stated (the equivalent of)
>that it is not their job to make editorial decisions on what the root
>zone contains.  They distribute what the ICANN/NTIA/Verisign gestalt
>publishes.

That has always been the case in the past.  Given the level of public
unhappiness that the US Dep't of Commerce has with ICANN's plan to add
zillions of new TLDs, and noting that several of the root servers are
run by agencies of the US government, who knows what will happen in
the future.

R's,
John



Re: So... is it time to do IPv6 day monthy yet?

2011-06-18 Thread Jimmy Hess
On Sat, Jun 18, 2011 at 4:31 AM, Mark Andrews  wrote:
> Not really.  A  record adds 28 octets (a A record takes 16).  Unless
> you have a lot of name servers most referrals still fall within 512 octets
> additionally most answers also still fall withing 512 octets.

I agree.. not that it should be assumed there is no v6 DNS issue.
With IPv6, the main issue may
be 'firewalls' and  'boxes in the middle'  silently munging, eating,
or destroying  responses.

DNSSEC  and not  is really the reason to have need for EDNS0 or TRUNC
on validating resolvers.   records should be fine for sane domains.

consider a referral for   example.com -> subdomain.example.com  with
8 nameservers.
mydomainname.example.com;   and assume you get both  and A
additional responses.

Total = 402 octets   -- still safe;  your domain name could be ~100
characters longer and it would still be fine.

Header <   2 (id)  + 2 (qr,opcode,aa,tc,rd,ra,z,rcode,qdcount)  + 2
(ancount)  + 2 (nscount)  + 2 (arcount)
   = 10 octets
Authority Section
ns1.subdomain.example.com.  IN  NS  ns1.subdomain.example.com.   <
26name + 2 + 2 + 4 + 2 +   2(pointer) =  36 octets
ns2.subdomain.example.com.  IN NS  ns2.subdomain.example.com.   <  4
name + 2(pointer)  + 2 + 2 + 4 + 2 +2(pointer) = 18 octets
ns3.subdomain.example.com.  IN NS  ns3.subdomain.example.com.   <  4
name + 2 + 2 + 2 + 4 + 2 + 2 =  18 octets
ns4.subdomain.example.com.  IN NS  ns4.subdomain.example.com.   <  18 octets
ns5.subdomain.example.com.  IN NS  ns5.subdomain.example.com.   <  18 octets
ns6.subdomain.example.com.  IN NS  ns6.subdomain.example.com.   <  18 octets
ns7.subdomain.example.com.  IN NS  ns7.subdomain.example.com.   <  18 octets
ns8.subdomain.example.com.  IN NS  ns8.subdomain.example.com.   <  18 octets

Additional Section
ns1.subdomain.example.com.  IN   2001:DB8::0<  2(pointer)
+4TTL+2RDLENGTH+16RDATA =  24 octets
ns2.subdomain.example.com.  IN   2001:DB8::1< 24 octets
ns3.subdomain.example.com.  IN   2001:DB8::2< 24 octets
ns4.subdomain.example.com.  IN   2001:DB8::3< 24 octets
ns5.subdomain.example.com.  IN   2001:DB8::4< 24 octets
ns6.subdomain.example.com.  IN   2001:DB8::5< 24 octets
ns7.subdomain.example.com.  IN   2001:DB8::6< 24 octets
ns8.subdomain.example.com.  IN   2001:DB8::7< 24 octets
ns1.subdomain.example.com.  IN A 192.0.0.0.1   <  2(pointer)
+4TTL+2RDLENGTH+4RDATA =  12 octets
ns2.subdomain.example.com.  IN A 192.0.0.0.1   <  12 octets
ns3subdomain.example.com.  IN A 192.0.0.0.1   <  12 octets
ns4.subdomain.example.com.  IN A 192.0.0.0.1   <  12 octets


Total = 402 octets   -- still safe;  your domain name could be  ~100
characters longer and it would still be fine.


--
-JH



Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Randy Bush
i am not learning anything here.  well, except maybe that someone who
normally has his head up his butt also had it in the sand.

what's new?  how about the operational technical effects, like data from
modeling various resolvers' responses to a large root zone?

randy



Re: Yup; the Internet is screwed up.

2011-06-18 Thread Eugeniu Patrascu
On Sun, Jun 12, 2011 at 22:48, Chris Adams  wrote:
> Once upon a time, Eugeniu Patrascu  said:
>> I need 100Mbs at home because I want to see a streamed movie NOW, not
>> in a month because someone considers broadband a luxury :)
>> Pretty simple usage scenario I might say.
>
> The top profile for Blu-Ray is 36 megabits per second, and that is
> not used on most titles.  Over-the-air HDTV is 19 megabits or less.
> Cable HD channels are often only 12-15 megabits per second.  OTA and
> cable HD is typically MPEG2, and MPEG4 can reach similar quality in half
> the bandwidth, which means TV quality HD can be 6-10 megabits per
> second.

Even though, my point stands. I don't want to wait forever for stuff
to load just because a dialup should be enough for browsing :)



Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Robert Bonomi


> Subject: Re: ICANN to allow commercial gTLDs
> From: Owen DeLong 
> Date: Sat, 18 Jun 2011 01:24:37 -0700
>
[[..  sneck  ..]]
>
> While that is true, there are several McDonalds registered in various 
> spaces that actually predate even the existance of Mr. Crok's famous 
> burger joints.

Just for the recorcd, that's a crock.

The man who made the burger chain a household word is Mr Ray _Kroc_.

"Spelling counts."





Re: Business Ethernet Services

2011-06-18 Thread Adrian Minta

On 06/17/11 21:55, Elliot Finley wrote:

Anyone using a CPE that is reliable and costs<= $300 ?

features needed:

SFP for uplink, QnQ, basic layer 2 functionality.

If you're using something with the above parameters and you like it,
please share. :)

Thanks,
Elliot



Something like Zyxel MES-2110 ?






Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Owen DeLong

On Jun 18, 2011, at 1:47 AM, Mark Andrews wrote:

> 
> In message <201106180718.p5i7irbe020...@mail.r-bonomi.com>, Robert Bonomi 
> write
> s:
>> 
>>> Subject: Re: ICANN to allow commercial gTLDs
>>> From: Owen DeLong 
>>> 
>>> MacDonald's would likely get title to .macdonalds under the new rules, 
>>> right?
>>> 
>>> Well... Which MacDonald's?
>>> 
>>> 1.  The fast food chain
>>> 2.  O.C. MacDonald's Plumbing Supply
>>> 3.  MacDonald and Sons Paving Systems
>>> 4.  MacDonald and Madison Supply Company
>>> 5.  etc.
>> 
>> Easy to resolve (excuse the pun) _that_ one.
>> 
>> The _senior_ claimant to that domain would be Clan MacDonald, of Scotland.
>> 
>> Who gets 'apple'?  Apple (the computer company), Apple (the record company)?
>>  How about the 'fruit of the month' club?
>> 
>> Now, if you want a _hard_ problem, who gets to register 'YellowPages' ?
>> <*EVIL* grin>
> 
> YellowPages would work.  It's used under licence.
> 
> au.YellowPages
> uk.YellowPages
> 
> As for single label hostnames, RFC 897 got rid of single label
> hostnames and they should not come back.  They are a security issue,
> see RFC 1535.
> 
> This has been pointed out in the past.
> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

All true. However, since TLDs will now be run by anyone with $185k/year to get
what they want...

Owen




Re: So... is it time to do IPv6 day monthy yet?

2011-06-18 Thread Mark Andrews

In message , Owen DeLong write
s:
> 
> On Jun 17, 2011, at 6:11 PM, Mark Andrews wrote:
> 
> >=20
> > In message , =
> Michael Dillon writes:
> >>> The last v6day was an isoc effort, there can be a separate nanog =
> effort or
> >>> your own.
> >>=20
> >> It does make a lot of sense for NANOG (perhaps jointly with RIPE and
> >> other NOGs) to organize monthly IPv6 days with a theme or focus for
> >> each month. If you have a focus, then you can recruit a lot of IPv6
> >> testers to try out certain things on IPv6 day and get a more thorough
> >> test and more feedback
> >>=20
> >> Skip July and August because it takes time to get this organized, and
> >> then start the next one on September the 8th or thereabouts.
> >>=20
> >> For instance, one month could focus on full IPv6 DNS support, but
> >> maybe not right away. A nice easy start would be to deal with IPv6
> >> peering and weird paths that result from tunnels. That is the kind of
> >> thing that would work good with a lot of testers participating and an
> >> application that traces IPv4 and IPv6 paths and measures hop count,
> >> latency, packet loss.
> >>=20
> >> In conjunction with the monthly IPv6 day, NANOG should set up a blog
> >> page or similar to publicly collect incident reports and solutions.
> >=20
> > I really don't know why anyone is worried about advertising 
> > records for authoritative nameservers.  It just works.  Recursive
> > nameservers have been dealing with authoritative nameservers having
> > IPv6 addresses for well over a decade now.  This includes dealing
> > with them being unreachable.
> >=20
> > DNS/UDP is not like HTTP/TCP.  You don't have connect timeouts to
> > worry about.  Recursive nameservers have much shorter timeouts as
> > they need to deal with IPv4 nameservers not being reachable.  They
> > also have to do all this re-trying within 3 or so seconds or else
> > the stub clients will have timed out.
> >=20
> Ah, but, with IPv6 records, you are much more likely to end up with
> a TRUNC result and a TCP query than with IPv4.

Not really.  A  record adds 28 octets (a A record takes 16).  Unless
you have a lot of name servers most referrals still fall within 512 octets
additionally most answers also still fall withing 512 octets.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org



Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Mark Andrews

In message <201106180718.p5i7irbe020...@mail.r-bonomi.com>, Robert Bonomi write
s:
> 
> > Subject: Re: ICANN to allow commercial gTLDs
> > From: Owen DeLong 
> >
> > MacDonald's would likely get title to .macdonalds under the new rules, 
> > right?
> >
> > Well... Which MacDonald's?
> >
> >  1. The fast food chain
> >  2. O.C. MacDonald's Plumbing Supply
> >  3. MacDonald and Sons Paving Systems
> >  4. MacDonald and Madison Supply Company
> >  5. etc.
> 
> Easy to resolve (excuse the pun) _that_ one.
> 
> The _senior_ claimant to that domain would be Clan MacDonald, of Scotland.
> 
> Who gets 'apple'?  Apple (the computer company), Apple (the record company)?
>   How about the 'fruit of the month' club?
> 
> Now, if you want a _hard_ problem, who gets to register 'YellowPages' ?
> <*EVIL* grin>
 
YellowPages would work.  It's used under licence.

au.YellowPages
uk.YellowPages
 
As for single label hostnames, RFC 897 got rid of single label
hostnames and they should not come back.  They are a security issue,
see RFC 1535.

This has been pointed out in the past.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org



Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Owen DeLong

On Jun 17, 2011, at 10:05 PM, Jeff Wheeler wrote:

> On Sat, Jun 18, 2011 at 12:04 AM, George B.  wrote:
>> I think I will get .payme  and make sure coke.payme, pepsi.payme,
>> comcast.payme, etc. all get registered at the low-low price of
>> $10/year.  All I would need is 100,000 registrations to provide me
>> with a million dollar a year income stream for the rest of my life.
> 
> I have read this thread, but certainly not any ICANN garbage.  It
> seems to me that a TLD for a brand, like Coca-Cola, would not be used
> in the same way as GTLDs.  Will George actually be allowed to carve up
> his own TLD and sell bits of it to anyone who is willing to click a
> checkbox on GoDaddy.com?  Obviously there is not any technical
> limitation in place to prevent this, but will there be legal / "layer
> 9" limitations?
> 
Um, that'll be just GoDaddy. soon enough.


> I kinda figured additional GTLDs is not very useful given that
> probably every domain registrar drives customers to "protect their
> brand," avoid phishing attacks against their customers, etc. by buying
> not only example.com, but also net|org|biz|etc.  I imagine that
> registrars may be really excited about this idea, because it
> represents additional fees/revenue to them.  I can't understand why it
> is good for anyone else.  Does McDonald's really want to print
> http://mcdonalds/ or www.mcdonalds instead of www.mcdonalds.com on
> their soft drink cups and TV ads?
> 
Ah, but at $185k/year/TLD to ICANN, Mr. Beckstrom has to be loving
it.

> Is Owen so disconnected from reality that he thinks the chain with the
> golden arches is spelled "MacDonald's?"
> 
No, just didn't want to get caught infringing. ;-)

I did say that I made several of the examples up.

> I don't particularly care about the intellectual property questions
> (in the context of NANOG) but if you really want to bang your head
> against that, I suggest reading about the current trademark status of
> "Standard Oil."  In short, it remains a legally protected mark but has
> several distinct owners throughout the United States -- a result of
> the break-up.  "Waffle House" is a little complex, too.  Somehow the
> GTLD system continues to function.  I imagine the relevant authorities
> are capable of figuring out who should be allowed to register which
> brand-TLD.
> 
I find your faith most disturbing.

Owen




Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Owen DeLong

On Jun 18, 2011, at 12:18 AM, Robert Bonomi wrote:

> 
>> Subject: Re: ICANN to allow commercial gTLDs
>> From: Owen DeLong 
>> 
>> MacDonald's would likely get title to .macdonalds under the new rules, 
>> right?
>> 
>> Well... Which MacDonald's?
>> 
>> 1.   The fast food chain
>> 2.   O.C. MacDonald's Plumbing Supply
>> 3.   MacDonald and Sons Paving Systems
>> 4.   MacDonald and Madison Supply Company
>> 5.   etc.
> 
> Easy to resolve (excuse the pun) _that_ one.
> 
> The _senior_ claimant to that domain would be Clan MacDonald, of Scotland.
> 
> Who gets 'apple'?  Apple (the computer company), Apple (the record company)?
>  How about the 'fruit of the month' club?
> 
> Now, if you want a _hard_ problem, who gets to register 'YellowPages' ?
> <*EVIL* grin>
> 
> 
> 

That's easy... Oracle as the successor to Sun Microsystems. :p

Owen




Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Owen DeLong

On Jun 17, 2011, at 8:47 PM, John Osmon wrote:

> On Fri, Jun 17, 2011 at 11:44:07AM -1000, Paul Graydon wrote:
>> [...]   I don't mind new TLDs, but company ones are crazy 
>> and going to lead to a confusing and messy internet.
> 
> Maybe we could demote the commercial ones to live under a single 
> TLD to make things simpler/neater...  :-)

I have an idea... Let's call it COM.

Owen




Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Owen DeLong

On Jun 17, 2011, at 8:36 PM, Jay Ashworth wrote:

> - Original Message -
>> From: "Owen DeLong" 
> 
>> apple.com is a delegation from .com just as apple is a delegation from
>> .
>> 
>>> apple. and www.apple. are *not* -- and the root operators may throw
>>> their hands up in the air if anyone asks them to have anything in
>>> their
>>> zone except glue -- rightly, I think; it's not a degree of
>>> complexity
>>> that's compatible with the required stability of the root zone.
>> 
>> Sir, either you are very confused, or, I am. I am saying that TLDs
>> behave with the same delegation rules as SLDs, which I believe
>> to be correct. You are claiming that TLDs are in some way magical
>> and that the ability to delegate begins at SLDs. I think the fact that
>> there is data in the COM zone separate from the root indicates that
>> I am correct.
> 
> I could be wrong--Cricket Liu I am not--but the point I'm trying to make
> is that the record "apple." does not *live* inside the zone server for 
> the "apple" TLD; it lives in ".".
> 

You are, indeed, wrong.

In . lives a pointer to apple. consisting of one or more NS records and possibly
some A/ glue for those nameservers if they are within apple.

In the apple. zone file lives everything else about apple. including the SOA 
record
for apple.

Just as in COM lives one or more NS records for APPLE.COM and possibly some
A/ glue for NS that live within APPLE.COM. Inside the APPLE.COM zone
file, OTOH, lives everything else about APPLE.COM including the SOA
for APPLE.COM.

> The people who operate the "apple" zone can apply an A record to 
> "www.apple"...
> 
> Oh.  Wait.
> 
> I'm sorry: you're right.  It's been so long since I climbed that far 
> up the tree, I'd forgotten, the TLDs don't *live* in the root servers.
> 
EXACTLY.

> So people operating a cTLD like "apple." would have to run their
> own analog of gtld-servers.net, to which the zone would be delegated,
> and such fanciness could happen there.  
> 
EXACTLY.

> Ok; so *this* bit of opposition was a red herring.  :-)
> 
YES.

Have a nice day.

Owen




Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Owen DeLong

On Jun 17, 2011, at 8:39 PM, Jay Ashworth wrote:

> - Original Message -
>> From: "Owen DeLong" 
> 
>> MacDonald's would likely get title to .macdonalds under the new rules,
>> right?
>> 
>> Well... Which MacDonald's?
>> 
>> 1. The fast food chain
>> 2. O.C. MacDonald's Plumbing Supply
>> 3. MacDonald and Sons Paving Systems
>> 4. MacDonald and Madison Supply Company
>> 5. etc.
>> 
>> All of them have legitimate non-conflicting trademarks on the name 
>> MacDonald's
>> (or at least could, I admit I made some of them up). I said when this mess
>> first started that mapping trademarks to DNS would only lead to dysfunction.
>> It did. Now the dysfunction is becoming all-encompassing. It will be 
>> interesting to watch the worlds IP lawyers (IP as in Intellectual Property,
>> not Internet Protocol)
>> eat their young over these issues for the next several decades.
> 
> Indeed.
> 
> It's actually "McDonalds", of course, and the US trademark law system has
> a provision for "famous" marks.  I don't recall what the rules are, but 
> once they've decide your mark is "famous", then it no longer competes only
> in its own line-of-business category; *no one* can register a new mark in 
> any category using your word.
> 

While that is true, there are several McDonalds registered in various spaces
that actually predate even the existance of Mr. Crok's famous burger joints.

> Coca-Cola, Sony, and I think Kodak, are the canonical examples of a
> famous mark.
> 

Let us not also forget the over-extension of that situation, as applied to 
Jell-O
where there are now very bizarre rules about who can and can't refer to just
any gelatine dessert as Jell-O.

Owen




Re: ICANN to allow commercial gTLDs

2011-06-18 Thread Robert Bonomi

> Subject: Re: ICANN to allow commercial gTLDs
> From: Owen DeLong 
>
> MacDonald's would likely get title to .macdonalds under the new rules, 
> right?
>
> Well... Which MacDonald's?
>
>  1.   The fast food chain
>  2.   O.C. MacDonald's Plumbing Supply
>  3.   MacDonald and Sons Paving Systems
>  4.   MacDonald and Madison Supply Company
>  5.   etc.

Easy to resolve (excuse the pun) _that_ one.

The _senior_ claimant to that domain would be Clan MacDonald, of Scotland.

Who gets 'apple'?  Apple (the computer company), Apple (the record company)?
  How about the 'fruit of the month' club?

Now, if you want a _hard_ problem, who gets to register 'YellowPages' ?
<*EVIL* grin>