On 6/19/11 10:47 PM, Paul Vixie wrote:
Date: Sun, 19 Jun 2011 22:32:59 -0700
From: Doug Barton
... the highly risk-averse folks who won't unconditionally enable IPv6
on their web sites because it will cause problems for 1/2000 of their
customers.
let me just say that if i was making millions
On 06/19/2011 22:47, Paul Vixie wrote:
Date: Sun, 19 Jun 2011 22:32:59 -0700
From: Doug Barton
... the highly risk-averse folks who won't unconditionally enable IPv6
on their web sites because it will cause problems for 1/2000 of their
customers.
let me just say that if i was making millions o
> Date: Sun, 19 Jun 2011 22:32:59 -0700
> From: Doug Barton
>
> ... the highly risk-averse folks who won't unconditionally enable IPv6
> on their web sites because it will cause problems for 1/2000 of their
> customers.
let me just say that if i was making millions of dollars a day and i had
the
On 06/19/2011 19:31, Paul Vixie wrote:
Date: Sun, 19 Jun 2011 19:22:46 -0700
From: Michael Thomas
that's a good question. marka mentioned writing an RFC, but i expect
that ICANN could also have an impact on this by having applicants sign
something that says "i know that my single-label top lev
In message , "John R. Levine" wr
ites:
> > And your technical solution to ensure "http://apple/"; always resolves
> > to "apple." and doesn't break people using "http://apple/"; to reach
> > "http://apple.example.net/"; is?
>
> Whatever people have been doing for the past decade to deal with
> h
Mark,
RTFDAG.
Regards,
-drc
On Jun 19, 2011, at 7:14 PM, Mark Andrews wrote:
>> In order to obtain a gTLD, you have to sign a contractual agreement with =
>> ICANN.
>
> David, you are missing the point. The TM holder doesn't want the
> gtld, they just want to protect their trademark. The TM h
I've reformatted the transcript of the discussion and vote on new gTLD's for
easier readability.
http://isoc-ny.org/icann41/06-20_singapore_gtld_vote.txt
On Sun, Jun 19, 2011 at 10:21 PM, Scott Howard wrote:
> Guessing some people here might be interested in this, but it seems to have
> only
In message <83163718-fa5b-47ba-ba50-67701abd5...@virtualized.org>, David Conrad
writes:
> On Jun 19, 2011, at 6:39 PM, Mark Andrews wrote:
> > I'm curious how anyone that has not signed a agreement with ICANN
> > can be bound to anything in any applicant guide book. =20
>
> In order to obtain a
By the way, the ICANN board just voted to approve the new gTLD program.
Time to place bets on what the next move will be.
My money is on lawsuits by US trademark lawyers.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment befo
>Adding gtlds and opening up the root to brands effectively requires
>TM holders to register/bid to protect their TM rights.
If you had read the applicant handbook, you would know that's not
true.
But I'm glad to see that people are taking my advice and continuing
the traditional uninformed nanog
> Really, if you're going to opine on the disasters that will befall ICANN as a
> result of the new gTLD program, you might want to actually read what that
> program does and doesn't do. Really.
you made my morning dave. thanks for the chuckle!
And your technical solution to ensure "http://apple/"; always resolves
to "apple." and doesn't break people using "http://apple/"; to reach
"http://apple.example.net/"; is?
Whatever people have been doing for the past decade to deal with
http://dk/ and http://bi/.
As I think I said in fairly
I am in Brazil and am having a heckuva time finding a Cisco 7201
router and Cisco ME 4924 switch.
Anyone have any ideas on where I could buy these easily? And if not,
any suggestions on Huawei equivalents?
--
Also on LinkedIn? Feel free to connect if you too are an open
networker: scubac...@gm
On Jun 19, 2011, at 6:39 PM, Mark Andrews wrote:
> I'm curious how anyone that has not signed a agreement with ICANN
> can be bound to anything in any applicant guide book.
In order to obtain a gTLD, you have to sign a contractual agreement with ICANN.
> Also rfp-clean-30may11-en.pdf basically
> >
> > I would guess that most of these are going to be purchased simply to
> > prevent someone else from getting them
>
> I would agree with this part.
>
> > and that most of them will never
> > actually be placed into production.
>
> But not with this part.
Well, I said "most", some will lik
In message <20110620033503.20835.qm...@joyce.lan>, "John Levine" writes:
> >i think he's seen RFC 1034 :-). anyway, i don't see the difference between
> >http://sony/ and http://sony./
>
> Neither do any of the browsers I use, which resolve http://bi/ as well
> as http://dk./ just fine. Whateve
Mark Andrews wrote:
_Now_ I get rend up at http://www.dk.com/ if I don't
That's your browser "trying" to be helpful. If it is Firefox this
can be turned off with about:config and browser.fixup.alternate.enabled
to false. The default is true.
Ah, thanks. I imagined it was FF trying to be he
In message <1bc921a3-c4cd-4fff-9ae5-49c1218d5...@virtualized.org>, David Conrad
writes:
> On Jun 19, 2011, at 5:46 PM, Mark Andrews wrote:
> >> I would guess that most of these are going to be purchased simply to
> >> prevent someone else from getting them
> > I would agree with this part.
>
> I
In message <4dfec221.90...@mistral.co.uk>, Adam Atkinson writes:
> Adam Atkinson wrote:
>
> It was a very long time ago, but I seem to recall being shown
> http://dk,
> the home page of Denmark, some time in the mid 90s.
>
> >> DK should NOT be doing this.
> >
> > Oh, I'm no
On Jun 19, 2011, at 5:46 PM, Mark Andrews wrote:
>> I would guess that most of these are going to be purchased simply to
>> prevent someone else from getting them
> I would agree with this part.
I suspect you underestimate the desires and power of marketing folks at larger
organizations.
> Addin
- Original Message -
> From: "John Levine"
> >i think he's seen RFC 1034 :-). anyway, i don't see the difference
> >between http://sony/ and http://sony./
>
> Neither do any of the browsers I use, which resolve http://bi/ as well
> as http://dk./ just fine. Whatever problem unqualified T
In message <5a6d953473350c4b9995546afe9939ee0d633...@rwc-ex1.corp.seven.com>, G
eorge Bonser writes:
> > The failure rate isn't going to be high enough for natural selection
> > to take effect. Remember the protocols we use were designed to
> > work back when there was only a single flat namespac
Adam Atkinson wrote:
It was a very long time ago, but I seem to recall being shown
http://dk,
the home page of Denmark, some time in the mid 90s.
DK should NOT be doing this.
Oh, I'm not claiming it does it now. It certainly doesn't.
I should have checked before I wrote that. The _last_ t
>i think he's seen RFC 1034 :-). anyway, i don't see the difference between
>http://sony/ and http://sony./
Neither do any of the browsers I use, which resolve http://bi/ as well
as http://dk./ just fine. Whatever problem unqualified TLD names
might present to web browsers has been around for a
Mark Andrews wrote:
It was a very long time ago, but I seem to recall being shown http://dk,
the home page of Denmark, some time in the mid 90s.
DK should NOT be doing this.
Oh, I'm not claiming it does it now. It certainly doesn't.
I _think_ I was shown http://dk in about 1993 or 1994 as a
>
> The failure rate isn't going to be high enough for natural selection
> to take effect. Remember the protocols we use were designed to
> work back when there was only a single flat namespace. Simple
> hostnames will appear to work fine for 99.999% of people. It's
> just when you get namespac
In message <4dfeaef6.70...@mtcc.com>, Michael Thomas writes:
> Isn't this problem self regulating? If sufficient things break
> with a single label, people will stop making themselves
> effectively unreachable, right?
The failure rate isn't going to be high enough for natural selection
to take ef
> Date: Sun, 19 Jun 2011 19:22:46 -0700
> From: Michael Thomas
>
> > that's a good question. marka mentioned writing an RFC, but i expect
> > that ICANN could also have an impact on this by having applicants sign
> > something that says "i know that my single-label top level domain name
> > will
On Jun 19, 2011, at 4:08 PM, Paul Vixie wrote:
> ICANN could also have an impact on this by having applicants sign something
Well, yes, ICANN could have contracted parties (e.g., the new gTLDs) do this. A
bit late to get it into the Applicant's Guidebook, but maybe something could be
slipped in
On Mon, Jun 20, 2011 at 02:08:18AM +, Paul Vixie wrote:
> > From: David Conrad
> > Date: Sun, 19 Jun 2011 16:04:09 -1000
> >
> > On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote:
> >
> > > i think we have to just discourage lookups of single-token names,
> > > universally.
> >
> > How?
>
> th
On 06/19/2011 07:08 PM, Paul Vixie wrote:
From: David Conrad
Date: Sun, 19 Jun 2011 16:04:09 -1000
On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote:
i think we have to just discourage lookups of single-token names,
universally.
How?
that's a good question. marka mentioned w
Guessing some people here might be interested in this, but it seems to have
only been sent to APAC-based *NOGs...
Scott
-- Forwarded message --
From: Save Vocea
Date: Sun, Jun 19, 2011 at 5:30 PM
Subject: [AusNOG] ICANN 41 - now underway
To: "aus...@ausnog.net"
Dear all,
T
On Sun, Jun 19, 2011 at 08:22:17PM -0400, Jay Ashworth wrote:
> - Original Message -
> > From: "Paul Vixie"
>
> > inevitably there will be folks who register .FOOBAR and advertise it as
> > "http://foobar/"; on a billboard and then get burned by all of the local
> > "foobar.this.tld" and
> From: David Conrad
> Date: Sun, 19 Jun 2011 16:04:09 -1000
>
> On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote:
>
> > i think we have to just discourage lookups of single-token names,
> > universally.
>
> How?
that's a good question. marka mentioned writing an RFC, but i expect
that ICANN cou
On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote:
> i think we have to just discourage lookups of single-token names, universally.
How?
Regards,
-drc
> From geor...@gmail.com Sun Jun 19 17:48:31 2011
> Date: Sun, 19 Jun 2011 15:48:32 -0700
> Subject: Re: Cogent depeers ESnet
> From: "George B."
> To: valdis.kletni...@vt.edu
> Cc: Robert Bonomi , nanog@nanog.org
>
> On Sun, Jun 19, 2011 at 2:47 PM, wrote:
> > On Sun, 19 Jun 2011 03:15:09 CDT,
Adding records for existing nameservers will NOT cause TC to
be set where it would not be set without records unless you
do a "ANY" lookup of the nameserver where it MAY result in TC being
set.
All current implementations, including named, fail to set TC when
adding glue records to a re
Vix:
> i think he's seen RFC 1034 :-). anyway, i don't see the difference
> between http://sony/ and http://sony./
The fact that the resolution of "sony." is deterministic, and that of
"sony" is location dependent?
> i think we have to just discourage lookups of single-token names,
> universally
On 6/19/2011 9:24 PM, Paul Vixie wrote:
> i think we have to just discourage lookups of single-token names, universally.
Not to mention the folks of the Redmond persuasion with their
additionally ambiguous \\hostname single names.
(In the absence of a configured search domain, Windows won't even
> Date: Sun, 19 Jun 2011 19:30:58 -0500
> From: Jeremy
>
> "DK" may not be hierarchical, but "DK." is. If you try to resolve "DK"
> on it's own, many (most? all?) DNS clients will attach the search
> string/domain name of the local system in order to make it a FQDN. The
> same happens when you tr
In message , Jeremy writes:
>
> "DK" may not be hierarchical, but "DK." is. If you try to resolve "DK" on
"DK." is NOT a hostname (RFC 952). It is NOT legal in a SMTP transaction.
It is NOT legal in a HTTP header.
> it's own, many (most? all?) DNS clients will attach the search string/domain
>
In message , Owen DeLong write
s:
> Appears to now get you a redirect to https://www.dk-hostmaster.dk/
>
> For those arguing that 512+ octet replies don't occur:
I don't think anyone argues that 512+ octet replies don't occur.
They have occured for as long as the DNS has existed. Even RFC
1123
A surprising number of TLDs have A records. Many are hosts with web
servers, a few are hosts with misconfigured or unconfigured web
servers (ph. and bi.), some don't respond. No TLD has an record,
confirming the theory that nobody actually cares about IPv6.
ac. 193.223.78.210
ai. 209.59.11
"DK" may not be hierarchical, but "DK." is. If you try to resolve "DK" on
it's own, many (most? all?) DNS clients will attach the search string/domain
name of the local system in order to make it a FQDN. The same happens when
you try and resolve a non-existent domain. Such as
alskdiufwfeiuwdr3948dx
- Original Message -
> From: "Paul Vixie"
> inevitably there will be folks who register .FOOBAR and advertise it as
> "http://foobar/"; on a billboard and then get burned by all of the local
> "foobar.this.tld" and "foobar.that.tld" names that will get reached
> instead of their TLD. i sa
In message <21633.1308527...@nsa.vix.com>, Paul Vixie writes:
> Jay Ashworth writes:
>
> > ... and that the root wouldn't be affected by the sort of things that
> > previously-2LD now TLD operators might want to do with their
> > monocomponent names...
>
> someone asked me privately a related q
- Original Message -
> From: "Paul Vixie"
> Adam Atkinson writes:
> > It was a very long time ago, but I seem to recall being shown
> > http://dk, the home page of Denmark, some time in the mid 90s.
> >
> > Must I be recalling incorrectly?
>
> no you need not must be. it would work as l
Original Message -
> From: "Owen DeLong"
> OTOH, I can easily see $COMPANY deciding that $RFC is not in their
> best interests and find the http://microsoft construct not at all
> unlikely.
>
> I realize that no responsible software vendor would ever deliberately
> do something insecure
Appears to now get you a redirect to https://www.dk-hostmaster.dk/
For those arguing that 512+ octet replies don't occur:
baikal:owen (14) ~ % dig @a.nic.dk -t any dk.2011/06/19
17:03:56
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.6.0-APPLE-P2 <<>> @a.nic.dk -t any
In message , Paul Vixie writes:
> Adam Atkinson writes:
>
> > It was a very long time ago, but I seem to recall being shown http://dk,
> > the home page of Denmark, some time in the mid 90s.
> >
> > Must I be recalling incorrectly?
>
> no you need not must be. it would work as long as no dk.th
On Jun 19, 2011, at 11:59 AM, David Conrad wrote:
> On Jun 19, 2011, at 8:49 AM, Chris Adams wrote:
>> Once upon a time, Randy Bush said:
Now I'm tempted to be the guy that gets .mail
>>> express that temptation in dollars, and well into two commas.
>> Imagine the "typo-squating" someone co
On Jun 19, 2011, at 9:51 AM, Jay Ashworth wrote:
> - Original Message -
>> From: "Paul Vixie"
>
>> David Conrad writes:
>>> 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. T
Jay Ashworth writes:
> ... and that the root wouldn't be affected by the sort of things that
> previously-2LD now TLD operators might want to do with their
> monocomponent names...
someone asked me privately a related question which is, if there's a .SONY
and someone's web browser looks up http:
Adam Atkinson writes:
> It was a very long time ago, but I seem to recall being shown http://dk,
> the home page of Denmark, some time in the mid 90s.
>
> Must I be recalling incorrectly?
no you need not must be. it would work as long as no dk.this or dk.that
would be found first in a search li
On Jun 19, 2011, at 5:47 PM, valdis.kletni...@vt.edu wrote:
> On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said:
>
>> Anybody got draft language for a SLA clause that requires routing 'at least
>> one hop _past_ the provider's network edge' for every AS visible at major
>> public peering points
On Sun, Jun 19, 2011 at 2:47 PM, wrote:
> On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said:
>
>> Anybody got draft language for a SLA clause that requires routing 'at least
>> one hop _past_ the provider's network edge' for every AS visible at major
>> public peering points and/or LookingGlas
On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said:
> Anybody got draft language for a SLA clause that requires routing 'at least
> one hop _past_ the provider's network edge' for every AS visible at major
> public peering points and/or LookingGlass sites?
*every* ASN? Oh my. ;)
pgpZ65dL0bm
The same type that Colombia/NeuStar is doing with .co?
On Sun, Jun 19, 2011 at 2:49 PM, Chris Adams wrote:
> Once upon a time, Randy Bush said:
>> > Now I'm tempted to be the guy that gets .mail
>>
>> express that temptation in dollars, and well into two commas.
>
> Imagine the "typo-squating"
It was a very long time ago, but I seem to recall being shown http://dk,
the home page of Denmark, some time in the mid 90s.
Must I be recalling incorrectly?
On Jun 19, 2011, at 8:49 AM, Chris Adams wrote:
> Once upon a time, Randy Bush said:
>>> Now I'm tempted to be the guy that gets .mail
>> express that temptation in dollars, and well into two commas.
> Imagine the "typo-squating" someone could do with .con.
See section 2.2.1.1 (and section 2.1.2)
Once upon a time, Randy Bush said:
> > Now I'm tempted to be the guy that gets .mail
>
> express that temptation in dollars, and well into two commas.
Imagine the "typo-squating" someone could do with .con.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't spe
On Sat, Jun 18, 2011 at 1:35 PM, Owen DeLong wrote:
> This ignores the extra baggage that tends to come along in a DNS payload.
> Just the root:
.
> Note, none of these came with glue. They ONLY included the name data.
> Had they come with glue, we would easily have been over 512 in both
> cas
> Now I'm tempted to be the guy that gets .mail
express that temptation in dollars, and well into two commas.
randy
Now I'm tempted to be the guy that gets .mail
On Fri, Jun 17, 2011 at 20:47, Jay Ashworth wrote:
> - Original Message -
> > From: "John Levine"
>
> > >The notion of a single-component FQDN would be quite a breakage for
> > >the basic concept of using both FQDNs and Unqualified names.
>
On Jun 19, 2011, at 4:16 AM, Robert Bonomi wrote:
>
>>
> Anybody got draft language for a SLA clause that requires routing 'at least
> one hop _past_ the provider's network edge' for every AS visible at major
> public peering points and/or LookingGlass sites?
This is relevant to my interests. I'd
- Original Message -
> From: "Paul Vixie"
> David Conrad writes:
> > 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
> > p
David Conrad writes:
> 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.
yes. for one example, see:
http://www.icann.org
> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Sun Jun 19 01:46:06
> 2011
> Date: Sat, 18 Jun 2011 23:44:28 -0700
> Subject: Re: Cogent depeers ESnet
> From: "George B."
> To: Nick Hilliard
> Cc: "nanog@nanog.org"
>
> On Sat, Jun 18, 2011 at 5:26 PM, Nick Hilliard wrote:
> > Slightl
68 matches
Mail list logo
