Dear Ching, All,
I vote in favour of the proposed resolution.
I believe that the proposed response to the Board’s letter as proposed by the joint working party has found a fair balance between the interest directly involved and proposes a practical way forward for the IDN ccTLDs who now and in future have to deal with this issue.
With respect to Ching’s position and decision I have to say that although I respect it, I was surprised, in particular by the “variance”, i.e., LGR argument.
- The working party prepared a response to the Board’s questions and in discussion with SSAC representatives found a common position, which now has been adopted by SSAC. Adoption by SSAC means that they have accepted the clarification, i.e., apparently SSAC believes that the letter has clarified the ambiguities, i.e., reconciled the differences, if any.
- Although I appreciate Ching’s observations, I am not sure I fully understand them. As said in my response "lower-case-prevails" does not imply that by definition and under all circumstances only a string in lower-case is the only relevant factor in case of confusingly similarity in upper case. This was also never suggested by the EPSRP WG.
If I understand the work of the EPSRP WG and I believe that by now I do, it has always been a matter of striking the balance between the principles Ching mentions: “lower – case prevails” and “conservatism prevails”. The working party, which included members from the ccNSO (both were members of the WG EPSRP) and from SSAC, was able to find common grounds and therefore proposed a balance that works for both.
Related, and just for clarity, I do not understand what you mean by “Works are still to be done AFTER the confusing string delegated -- quoting p6 of the response "The level of the threshold, or the acceptable level of residual risk when confusability is evaluated in context of the proposed mitigation methods, needs to be determined."
My reading of section you quote from the paper (in italics and underlined) is that as part of the Fast Track process and after it is determined a string is confusingly similar, the requestor of the string may propose mitigating measures. To be clear, this IS part of the Fast Track process. It is also my understanding that the Fast Track process only looks at the string selection for IDN ccTLD to substitute / complement RFC 1591 with respect to the string selection. The delegation process will only start after the string selection, i.e., when all conditions of the Fast Track process have been completed, including – and only if necessary - the proposal and acceptance of mitigating measures. In the Fast Track Implementation plan this is explicitly documented: the delegation process is similar to two-letter code delegation process and out of scope to the Fast Track (See Module 6 page 38 of the Fast Track process).
Please note – it is not reasonable to ask from the (potential) registry submitting their application for an IDN ccTLD string to propose mitigation measures together with the initial submission. They may have NO CLUE that their strings might be found confusingly similar to some other strings. Only when the confusing similarity is established, can the registry think and propose mitigation measures, which will be evaluated (and either accepted or not).
- As to the LGR mechanism to which Ching refers, “ICANN is preparing a better LGR mechanism for future TLDs b) setting a new and potentially dangerous path of TLD delegation without considering the existing bundling / blocking approach (a conservative / inclusive approach) used by existing IDN ccTLD / gTLD programs.”
This argument may currently be relevant for gTLDs, however, to date the ccNSO and broader ccTLD community have not discussed the “variance” issue. Hence, we have not discussed LGR, nor its implications. The proposed policy for selection of IDNc cTLD strings includes a placeholder. In my view, we should not pre-empt any outcomes of this discussion up and until there is a stable technical resolution of the issues pertaining to “variants” and the community has discussed and agreed on the policy implications for IDN ccTLDs. This discussion may become relevant in the future as part of the further discussion on the overall policy, but not as part of the confusingly similarity discussion and our response to the Board.
- As to the final argument, I agree that this additional step may prolong the validation process, however, it is my understanding that when needed it does not affect any other applications as you seem to imply, and could only be triggered by the requestor of the string. The situation we are looking at only applies when a string is found to be confusingly similar (so if not, as in the vast majority of cases, the duration is not affected).
- Please also note, that the Board in its letter asked the ccNSO and SSAC to respond by 30 September. SSAC has already adopted the response.
Kind regards,
]{atrina
From: 喬敬 <chiao@brandma.co>
Date: Monday, 4 September 2017 at 11:20
To: HiroHOTTA <hotta@jprs.co.jp>
Cc: Katrina Sataki <katrina@nic.lv>, "ccnso-council@icann.org" <ccnso-council@icann.org>
Subject: Re: [ccnso-council] DECISION NEEDED: Joint ccNSO-SSAC response to the ICANN Board
Thank you very much Hotta-san and Katrina for the hard work and detail explanation. It's very helpful to understand how ccNSO and SSAC would like to reach the wording agreement on the proposed mechanism of dealing with upper-case-lower-case issue.
Even so, at this point I am very sorry that I can only oppose the proposed resolution, but I am open to have continuous dialog with SSAC, even the Board IDN WG, on this particular issue. Therefore, I can accept that we postpone the decision until Abu Dhabi or later.
Three reasons behind my decision:
1) I do not see the letter actually reconcile the differences between ccNSO and SSAC. It recognizes / emphasizes the differences of ccNSO "lower-case-prevails" position and SSAC "conservatism prevails" position. Works are still to be done AFTER the confusing string delegated -- quoting p6 of the response "The level of the threshold, or the acceptable level of residual risk when confusability is evaluated in context of the proposed mitigation methods, needs to be determined."
2) I also believe that this resolution confuses the overall community by: a) offering "lower-case prevails" approach while ICANN is preparing a better LGR mechanism for future TLDs b) setting a new and potentially dangerous path of TLD delegation without considering the existing bundling / blocking approach (a conservative / inclusive approach) used by existing IDN ccTLD / gTLD programs.
3) On risk mitigation -- ICANN consult on experts AFTER delegation -- this could be even more time consuming and prolong any single application in the fast track process.
I hope these points make sense to you and other Councilors. Your further feedback and thoughts are very welcome!
Best regards,
Ching
On Fri, Sep 1, 2017 at 6:57 PM, HiroHOTTA <hotta@jprs.co.jp> wrote:
I agree to the resolution.
Hiro
On Thu, 31 Aug 2017 19:57:58 +0300
"Katrina Sataki" <katrina@nic.lv> wrote:
> Dear Councillors,
>
>
>
> On our last call Hiro informed us that the EPSRP working party concluded its
> work and the SSAC was in the process to decide whether to adopt the paper
> prepared by the working party. Hiro also indicated that he would submit the
> final paper to chair once adopted by SSAC.
>
>
>
> I am pleased to inform you that Hiro has formally sent me the paper after he
> and I were informed that SSAC has adopted the document (included) "as is".
> So now it is up to us.
>
>
>
> According to our internal rules
> (https://ccnso.icann.org/about/guidelines-council- )practices-09feb17-en.pdf
> and as agreed at our last call on 24 August we will take an email decision.
> I therefore propose the following resolution:
>
>
>
> Proposed Resolution
>
>
>
> Background
>
> In its letter dated 24 April 2017, the ICANN Board of Directors noted
> divergent views of the SSAC and ccNSO with respect to the following topics:
> Interpretation of RFC 6912; On similarity findings, and On mitigation
> measures. The Board suggested the ccNSO and SSAC collaboratively arrive at
> conclusions on these 3 issues and requested a joint briefing to further the
> Board's understanding of the topic. The ccNSO and SSAC agreed to set up a
> working party with two members from each group tasked to develop a common
> position on the 3 topics, if feasible. Both the ccNSO Council and SSAC would
> approve the document according to their own rules and procedures and then
> would send and present it to the Board. The Chair of the ccNSO and ccNSO
> members on the working party were informed that SSAC has adopted the Joint
> ccNSO SSAC Response to ICANN Board on EPSRP as proposed by the working
> party.
>
>
>
> Decision.
>
> The ccNSO Council suports the observations and recommendations of the
> working party and adopts the Joint ccNSO-SSAC Response to ICANN Board on
> EPSRP as proposed by the working party. The ccNSO Council particularly
> welcomes the proposed changes to section 5.6.3 of the current version of the
> Fast Track Implementation Plan
> (https://www.icann.org/en/system/files/files/idn-cctld- implementation-plan-0
> 5nov13-en.pdf ). The ccNSO Council request its Chair to inform the Chair of
> SSAC accordingly, and jointly submit the Joint Response. The ccNSO Council
> thanks and congratulates the members of the working party: Suzanne Woolf
> (SSAC), Jeff Bedser (SSAC), Hiro Hotta (ccNSO), Wafa Dahmani (ccNSO), for
> their work on the paper and for finding a common position.
>
>
>
> According to our rules this resolution will be considered adopted if none of
> us raises objections by 8 September 2017 23.59 UTC or, in case at least one
> of us raises an objection by a majority vote.
>
>
>
> So, please let your voice be heard on this topic, preferably as soon as
> possible but no later than 8 September 23.59 UTC.
>
>
>
> Thank you!
>
>
>
> Kindest regards,
>
>
>
> ]{atrina
>______________________________
_________________
Ccnso-council mailing list
Ccnso-council@icann.org
https://mm.icann.org/mailman/listinfo/ccnso-council
--
Ching Chiao
Founder & CEO
Brandma Internet Group
中域国际集团
Beijing . Chengdu . Hangzhou . Hong Kong . Shenzhen. Taipei