[ChineseGP] CJK Joint meeting record and homework

[王伟]

Dear All

	Please find the attached documents of meeting agenda & record, and
the action item (homework)

	Thanks everyone who join the meeting in the two days. We will keep
working on it.


Regards
WANG Wei

-----邮件原件-----
发件人: chinesegp-bounces at icann.org [mailto:chinesegp-bounces at icann.org] 代
表 HiroHOTTA
发送时间: 2016年3月21日 8:53
收件人: ChineseGP at icann.org; JapaneseGP at icann.org; KoreanGP at icann.org
主题: [ChineseGP] how 'blocked' can help us

(During 4 hours struggle with the letters without significant  output ...)

A question has come to my mind and won't disappear...

What are the future of "allocatable labels"?

Let's assume the case where
  registrant-X applied for label-A,
  and label-B is marked as 'allocatable' by LGR,
  then, label-A is delegated to registrant-X.

As far as I understand, the above means "only registrant-X has the right to
apply for label-B in the future." If registrant-X wants label-B to be
delegated, he/she needs to make a separate application to ICANN. And ICANN
will evaluate the label-B by a human panel (maybe supported by some
automatic mechanism).

Then, what's the difference between
(1) all variants are allocatable
(2) some variants are allocatable and the others are blocked 
    (or invalid)

I understand (2) can make the applicant know that the application for some
strings (that are blocked/invalid) will definitely be rejected in any case.
However, this does not reduce the number of TLD delegations significantly
because the applicant does want only a few variant TLDs in reality, for
money-wise reason or usage-wise reason. 

then,,,,, why is (1) so evil?

Hiro

_______________________________________________
ChineseGP mailing list
ChineseGP at icann.org
https://mm.icann.org/mailman/listinfo/chinesegp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2016 March 20-21 CJK Coordination Meeting Agenda Update 20160318.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 355725 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/chinesegp/attachments/20160321/63f16979/2016March20-21CJKCoordinationMeetingAgendaUpdate20160318-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CJK Action Item List 20160321 1700.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 16157 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/chinesegp/attachments/20160321/63f16979/CJKActionItemList201603211700-0001.docx>