910651 - Add newly-minted gTLDs (from July and August 2013) to the PSL

Status: RESOLVED FIXED

(Core Graveyard :: Networking: Domain Lists, defect)

Description

[Gervase Markham [:gerv]]

They are:

TLD			English Meaning	Approval Date

xn--ngbc5azd (شبكة.) 	Web or Network	July 13, 2013
xn--80asehdb (онлайн)	Online		July 14, 2013
xn--80aswg (сайт)	Web site	July 14, 2013
xn--unup4y (.游戏)	Game		July 14, 2013
lighting				August 27, 2013
estate					August 27, 2013
bike					August 27, 2013
xn--vhquv (企业)	Company/firm/enterprise	August 27, 2013
holdings				August 27, 2013
equipment				August 27, 2013
clothing				August 27, 2013
voyage					August 27, 2013
guru					August 27, 2013
ventures				August 27, 2013
singles					August 27, 2013
camera					August 27, 2013

None of them have told us about any sub-structure, but Chrome (at least) likes to have all TLDs in the list regardless.

Gerv

Comment 1

[Jothan Frakes]

Gerv-

The first four are contracted, but not in the zone yet / delegated.  

There is, until contract and delegation of the TLD, a number of intervening factors that might merit some thought...  for example, the opportunity for the TLD to not be delegated is present should they withdraw their application or not pass the application process.  Also applicant contention (two companies+, one string) could be still in the process of sorting out...  so the "official" request from the registry operator may be ambiguous in some cases.  

What is the policy to be used for which are and are not included in PSL, and when?

-Jothan

Comment 2

[Gervase Markham [:gerv]]

This list comes from the notifications on the gTLD mailing list:
https://mm.icann.org/mailman/listinfo/gtldnotification

Each of those represents a signed contract between ICANN and a specific applicant. So I think applicant contention is sorted out, and a withdrawal is unlikely. 

My proposal is that we use the appearance of a TLD on this mailing list as a trigger to add it to the PSL. (CAs are using it as a trigger to contact customers who have clashing certs.) As a data source, it has the advantage of simplicity, completeness and (I think) timeliness. It also allows updated PSLs to get some distribution before the domain goes live. If you don't think we should do this, what data source or event do you think we should trigger on?

Gerv

Comment 3

[Gervase Markham [:gerv]]

Also:

tattoo     August 30, 2013

Gerv

Comment 4

[Jothan Frakes]

Your proposal sounds solid.  So it shall be done.

Comment 5

[Jothan Frakes]

Just a suggestion... for managing the additions that are going to come in 'thundering herds' over the next 18-24 months - there are many updates on the way.  

To mitigate the diffs becoming unwieldy, could I recommend that it is time to split the gTLDs from the ccTLDs as individual sections within the ICANN region.  

There will be approximately 1400 new gTLDs coming in, the majority of which are going to be flat, while the ccTLDs have much variety and nuance.

If these are separated and remain distinct, I suspect the diffs / update process will work smoother.

Comment 6

[Gervase Markham [:gerv]]

I have had a submission from CoreNIC which indicates that the two new Russian TLDs are flat.

Gerv

Comment 7

[Gervase Markham [:gerv]]

Weppos: can you prepare a patch here?

I also seem to remember that there was a proposal to separate out CCTLDs from gTLDs. I can't remember where that was made. If that's going to happen, it should be a separate, previous patch. I'm not sure whether or not it would improve maintenance.

Gerv

Comment 8

[Simone Carletti]

I don't recall about the proposal. I personally suggest to start using the same list, we always have time to split it in a second step.

Do you agree?

Comment 9

[Gervase Markham [:gerv]]

weppos: happy to wait and see, as you say. Could you prepare a patch for the TLDs in the Google Doc Jothan created?

These emails seem to be coming through thick and fast. Perhaps we should establish a 2-week rhythm, or something like that?

Gerv

Comment 10

[Simone Carletti]

@Gerv

I have no access to the docs. Can you share it with me?
My gmail account is easy to guess ;).

-- Simone

Comment 11

[Jothan Frakes]

@simone

I have a PM to you so I can ensure you have access to the Google spreadsheet.

@simone, @gerv, et al contributors

I know I have suggested a few ideas on how to structure PSL for best addressing the thundering herd of new gTLD entries that are coming.  Ignore those.

Now that I see how these are coming in, and the pace that ICANN is contracting, I'd like to suggest that these new gTLDs have a section to themselves which we order by arrival of the email announcements from ICANN, and that we do this for the duration of the contracting phase, until we have the majority of them (say 1200ish).   

After the majority have arrived, we can then better organize them, but it will allow us more agility in the interim if we do by arrival.

This will keep the DIFF process clean and be simpler to track so that nothing is accidentally overlooked.

-Jothan

Comment 12

[Jothan Frakes]

Attachment: 2013-07-14-to-2013-10-01-newgtlds.txt - please make unified diff and add

Simone or Gerv can you make a unified diff of this and add it to the PSL

Comment 13

[Gervase Markham [:gerv]]

Simone: are you able to take this on? I think we need to get into the habit of adding these on a regular basis.

Gerv

Comment 14

[Simone Carletti]

I'm looking into that. As far as I read, we decided to go with a separate file?

Comment 15

[Gervase Markham [:gerv]]

A separate file? I'm not sure where you got that idea. The PSL is one file. Do you mean a separate section? Yes, I think we should go with that, and see how we get on. We can always merge in later if it seems advantageous.

Gerv

Comment 16

[Simone Carletti]

Attachment: GTLDS.patch

I generated a patch.

Gerv, let me know if the section header looks fine for you or you want to use a different label.

Comment 17

[Simone Carletti]

Attachment: GTLDS.patch

New patch, the previous one contained an invalid quote.

Comment 18

[Gervase Markham [:gerv]]

Comment on attachment 813047 [details] [diff] [review]
GTLDS.patch

> // ===END PRIVATE DOMAINS===
>+// ===BEGIN NEW gTLD DOMAINS===

We can't do this; people will expect the new domains to be in the "ICANN DOMAINS" section. We should add them in a block, as you have done, but add them at the bottom of that section, not in a new section.

>+// kim : 2013-09-24  Afilias Limited 
>+kim

Can we remove the double space, and separate with a comma?

Other than that, great.

Gerv

Comment 19

[Simone Carletti]

OK, I'll update the patch ASAP.

Comment 20

[Simone Carletti]

Attachment: GTLDS.patch

I updated the patch with the following changes:

1. I moved the group inside the existing ICANN group
2. I replaced the double space with a new format. The double space was the result of the formula printing a separator when no punycode exists. In this case, I moved the punycode/unicode at the beginning followed by : as we're doing for the other existing IDN TLDs.
3. I updated the list to the latest released gTLD.

Comment 21

[Gervase Markham [:gerv]]

Comment on attachment 817182 [details] [diff] [review]
GTLDS.patch

>+// ===BEGIN NEW gTLD DOMAINS===

I'm not sure we need this. Who would want to distinguish between these and the other ICANN domains? Also, it's dangerous to label anything "New" - see http://en.wikipedia.org/wiki/New_College,_Oxford (founded 1379).

>+// xn--q9jyb4c : 2013-09-17 Charleston Road Registry 
>+xn--q9jyb4c

This one seems to be in punycode form...

>+// xn--fiQ64b : 2013-10-14 CITIC Group Corporation 
>+中信"

Stray closing quote here?

>+// ===END NEW gTLD DOMAINS===

Don't forget to remove this one too.

Gerv

Comment 22

[Simone Carletti]

> I'm not sure we need this.

It means you don't want to use a custom group anymore? You said

> We should add them in a block, as you have done, but add them at the bottom of that section, not in a new section.

Please let me know what is the name of the group you want to use, and I'll use it.

Comment 23

[Gervase Markham [:gerv]]

Sorry I wasn't clear. By "in a block", I merely meant "not scattered throughout the file". I don't think the block needs delimiters.

Gerv

Comment 24

[Simone Carletti]

Attachment: GTLDS.patch

Comment 25

[Gervase Markham [:gerv]]

Comment on attachment 817201 [details] [diff] [review]
GTLDS.patch

r=gerv.

Gerv

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9767cf9a0150

Comment 27

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/9767cf9a0150