Refresh Public Suffix List for the latest ICANN-contracted registries

Refresh Public Suffix List for the latest ICANN-contracted registries

This updates to the following revision:
a0e75c5556af 2014-01-21 11:40 -0500

It includes changes from revision 8e7edf512909
(2013-12-11 10:35 -0500) to revision a0e75c5556af
(2014-01-21 11:40 -0500), listed at http://hg.mozilla.org/mozilla-central/filelog/a0e75c5556af/netwerk/dns/effective_tld_names.dat

BUG=37436
R=pkasting@chromium.org, pkasting

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=247037

[Ryan Sleevi, 2014-01-24 21:32:26]

Peter: Refresh for the ICANN-contracted domains since November.

[Peter Kasting, 2014-01-24 21:35:20]

LGTM

Wow, that's a lot of domains.  I wonder why Mozilla is listing them in
chronological order like this instead of in alphabetical order.  That seems
strange, and not as maintainable.

[Ryan Sleevi, 2014-01-24 21:36:47]

On 2014/01/24 21:35:20, Peter Kasting wrote:
> LGTM
> 
> Wow, that's a lot of domains.  I wonder why Mozilla is listing them in
> chronological order like this instead of in alphabetical order.  That seems
> strange, and not as maintainable.

These are names that ICANN has contracted with, but has not delegated. That is,
they're not "live" in the Root Zone Database, but they are approved by ICANN and
thus going through domain stress testing.

As these names are delegated ("turned on") by IANA, Mozilla's plan is to migrate
them into their "final" resting place within alphabetical order.

[Peter Kasting, 2014-01-24 21:39:47]

On 2014/01/24 21:36:47, Ryan Sleevi wrote:
> On 2014/01/24 21:35:20, Peter Kasting wrote:
> > LGTM
> > 
> > Wow, that's a lot of domains.  I wonder why Mozilla is listing them in
> > chronological order like this instead of in alphabetical order.  That seems
> > strange, and not as maintainable.
> 
> These are names that ICANN has contracted with, but has not delegated. That
is,
> they're not "live" in the Root Zone Database, but they are approved by ICANN
and
> thus going through domain stress testing.
> 
> As these names are delegated ("turned on") by IANA, Mozilla's plan is to
migrate
> them into their "final" resting place within alphabetical order.

Ah.

Personally, I'd slightly prefer if Chrome didn't treat such domains as real when
they're not, yet -- but I don't care too much.

[Ryan Sleevi, 2014-01-24 22:20:03]

On 2014/01/24 21:39:47, Peter Kasting wrote:
> On 2014/01/24 21:36:47, Ryan Sleevi wrote:
> > On 2014/01/24 21:35:20, Peter Kasting wrote:
> > > LGTM
> > > 
> > > Wow, that's a lot of domains.  I wonder why Mozilla is listing them in
> > > chronological order like this instead of in alphabetical order.  That
seems
> > > strange, and not as maintainable.
> > 
> > These are names that ICANN has contracted with, but has not delegated. That
> is,
> > they're not "live" in the Root Zone Database, but they are approved by ICANN
> and
> > thus going through domain stress testing.
> > 
> > As these names are delegated ("turned on") by IANA, Mozilla's plan is to
> migrate
> > them into their "final" resting place within alphabetical order.
> 
> Ah.
> 
> Personally, I'd slightly prefer if Chrome didn't treat such domains as real
when
> they're not, yet -- but I don't care too much.

They are real domains - they're just not "live" yet. The timeline for when they
turn "live" is contingent upon several variables, but I want to make sure that
Chrome will recognize these domains the moment they go live. That's what part of
the Domain Stress Test is meant to ensure.

From the "Are they (going to be) real" the answer is yes. In addition to being
consistent with Mozilla (which I've been working with, along with our internal
gTLD teams), it's also consistent with how we're trying to treat these in other
products/services.

For example, "guitars" (contracted 2013-11-14) has a sunrise registration of
1/27/2014 - see
http://newgtlds.icann.org/en/program-status/sunrise-claims-periods - which is
when applicants can start pre-registering domains (
http://www.icann.org/en/resources/compliance/registries/sdrp )

Anyways, minor objection noted, although no ill-effects and helps ensure that as
domains are brought up, Chrome recognizes them (eg: inc. stable releases)

[Ryan Sleevi, 2014-01-25 00:38:24]

Committed patchset #1 manually as r247037 (presubmit successful).

[Alpha Left Google, 2014-01-25 03:46:25]

A revert of this CL has been created in
https://codereview.chromium.org/143943019/ by hclam@chromium.org.

The reason for reverting is: Speculative revert to see if it resolves the size
regression..