[IDN-WG] Request for comments to Draft Recommendations on IDN for Subsequent Procedures

Edmon edmon at isoc.hk
Fri Jun 12 02:26:01 UTC 2020


Thanks Justine for the detailed report.

 

1&2 ok.

 

3. First of all, I do not agree with the staff report.  We were going to address that in the IDN Variants PDP that should address the issue more holistically.  So I hope SubPro would not just take the staff report as-is, but stay with what was also a hard fought battle prior to and during the 2012 round.

 

4&5.

Some minor edits to the first sentence:

============

Recommendation xx (Rationale 4): IDN gTLDs identified as IDN Variants of already existing or applied for gTLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant gTLD bundling must be captured in relevant Registry Agreements.

============

 

For second sentence, I think it is best to avoid the phrase “apply for”, and for simplicity, I would suggest:

============

This working group has not discussed the process of allocating and delegating an IDN variant of an existing TLD.

============

 

For the last part, I am not sure it is true… the issue must have been discussed, even though the WG may not have come to any conclusion to it.

I would suggest completely removing it.

The 2012 AGB did include a question for the applicant to identify the IDN Variants though.

 

Edmon

 

 

 

 

From: Justine Chew <justine.chew.icann at gmail.com> 
Sent: Friday, June 12, 2020 9:57 AM
To: Edmon <edmon at isoc.hk>; IDN-WG <idn-wg at atlarge-lists.icann.org>
Subject: Re: [IDN-WG] Request for comments to Draft Recommendations on IDN for Subsequent Procedures

 

Hi Edmon, all,

The SubPro PDP WG discussed your proposed amendment (put forward by me on behalf of the IDN-WG) at its most recent WG call.

Allow me to summarize the outcome,

1. Firstly, there was an edit to the earlier draft Recommendation xx (Rationale 4) which essentially led to it being read as follows, but does not change the point that you (i.e. Edmon) had highlighted.


Original Text:
Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for [IDN] TLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements.

2. What the SubPro PDP WG discussed was the text submitted (on behalf of the IDN-WG), as amended to take into account the above edit.
 
Text suggested by Justine:
[Recommendation xx (Rationale 4): IDN gTLDs deemed to be variants of already existing or applied for TLDs will not be allowed for separate application and allowed for activation by the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements.]

And the rationale provided for this text:
The recommendation seems to expect that an IDN Variant TLD go through the same "application process". An IDN Variant TLD should only be "activated" not "applied for" by the same Registry Operator. This is consistent with how the 2012 round was envisioned and handled.  Allowing IDN Variant TLDs to be "applied for" is problematic for the concept of IDN Variants.



3. During the SubPro PDP WG call, there was some support for our proposed text but Leadership and staff pointed out that there is no policy for IDN gTLD variants to be activated without going through the standard gTLD application process, only that such application for a deemed IDN gTLD variant is to be restricted to the same registry operator and back-end registry service provider which already has an existing or applied for ("linked") IDN TLD.

(a) Here is the context provided by staff:

 

From: Steve Chan

Date: Fri, 12 Jun 2020 at 06:10

Subject: Re: [Gnso-newgtld-wg] FW: IDN Variant - Activation or Application?

To: Aikman-Scalese, Anne , Jeff Neuman 

Cc: gnso-newgtld-wg at icann.org <mailto:gnso-newgtld-wg at icann.org> 

 

 

Dear Anne, all,

 

It may be helpful to review the entire set of documentation for IDN variant TLD management here: https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-en

 

Document three (https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-analysis-25jan19-en.pdf) on this page provides the recommendations and analysis. To your question, I think sections 3.3 and 3.3.1 are most applicable. Section 3.3 references several RFCs and SAC060 to note that a conservative approach should be taken in allocating IDN variant TLDs; just because an IDN variant can be allocated does not mean that it should be allocated. Section 3.3.1 mentions that the study recommends that the application process and fee apply to variant labels, similar to any gTLD label, which is consistent and furthers the principle of conservative allocation of variants.

 

To summarize and in response to your questions, based on my reading, the paper says IDN variants would be available for application (not simply activation) and only to the same entity.  

 

Best,

Steve

 

 (b) I noted that Maxim Alzoba and Rubens Kuhl (both from GNSO) offered some helpful information, namely that above position is one made and held by ICANN Org with little community consultation, and that GNSO has established a scoping team to develop policy on this issue, See:  <https://www.google.com/url?q=https://gnso.icann.org/sites/default/files/file/field-file-attach/idn-scoping-team-final-report-17jan20-en.pdf&sa=D&usd=2&usg=AOvVaw3QI49G_cuissHe5_ehYI0b> https://gnso.icann.org/sites/default/files/file/field-file-attach/idn-scoping-team-final-report-17jan20-en.pdf


 4. SubPro PDP WG members have now been asked to consider the original text with an added sentence,

Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for TLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements. This working group has not discussed the process by which an existing registry operator could apply for, or be given, an IDN variant of an existing TLD.  Nor has it discussed who one would include in its application for a new gTLD its desire for an IDN Variant.

5. My question then to this group/Edmon is what is our position or reaction to the highlighted text above?

 

Thanking all in advance for reading this long email and for responding,

Justine 

------

 

 

On Tue, 5 May 2020 at 20:00, Edmon <edmon at isoc.hk <mailto:edmon at isoc.hk> > wrote:

I would propose a simple edit to Recommendation 4 as follows:

 

(a) Recommendation xx (Rationale 4): IDN gTLDs deemed to be IDN variants of already existing or applied for TLDs will be not be allowed for separate application and allowed for activation only by the same registry operator [and back-end registry service provider,] implementing by force of written agreement a policy of cross-variant TLD bundling.

 

Edmon

 

 

 

 

From: Justine Chew <justine.chew.icann at gmail.com <mailto:justine.chew.icann at gmail.com> > 
Sent: Tuesday, May 5, 2020 5:57 PM
To: Edmon <edmon at isoc.hk <mailto:edmon at isoc.hk> >
Cc: IDN-WG <idn-wg at atlarge-lists.icann.org <mailto:idn-wg at atlarge-lists.icann.org> >
Subject: Re: [IDN-WG] Request for comments to Draft Recommendations on IDN for Subsequent Procedures

 

Hi Edmon,

How would you propose to change to address the said perception? Is there some way to clarify, say, by adding a footnote or changing the text somehow?

Thanks,
Justine

------

 

 

On Tue, 5 May 2020 at 16:43, Edmon <edmon at isoc.hk <mailto:edmon at isoc.hk> > wrote:

I have some concern with Recommendation 4.
The recommendation seems to expect that an IDN Variant TLD go through the same "application process"
I believe, any IDN Variant TLD should only be "activated" not "applied for" by the same Registry Operator.
This is consistent with how the 2012 round was envisioned and handled.  Allowing IDN Variant TLDs to be "applied for" is problematic for the concept of IDN Variants I think.
Edmon



> -----Original Message-----
> From: IDN-WG <idn-wg-bounces at atlarge-lists.icann.org <mailto:idn-wg-bounces at atlarge-lists.icann.org> > On Behalf Of Justine
> Chew
> Sent: Tuesday, May 5, 2020 10:23 AM
> To: IDN-WG <idn-wg at atlarge-lists.icann.org <mailto:idn-wg at atlarge-lists.icann.org> >
> Subject: Re: [IDN-WG] Request for comments to Draft Recommendations on
> IDN for Subsequent Procedures
> 
> I have not received any response to my request below. Does that mean no one
> in this IDN-WG has anything else to say about these Subsequent Procedures
> recommendations?
> 
> Justine
> ------
> 
> 
> On Tue, 28 Apr 2020 at 18:10, Justine Chew <justine.chew.icann at gmail.com <mailto:justine.chew.icann at gmail.com> >
> wrote:
> 
> > Dear IDN-WG colleagues,
> >
> > Just to follow up on the earlier conversation.
> >
> > We now have draft recommendations and corresponding rationales from
> > the Subsequent Procedures PDP WG for our consideration.
> >
> > These can be viewed at this Googledoc:
> >
> https://docs.google.com/document/d/1uEVRugHtDTGlioo0lXBQBIYuxZIjcrolea
> > dyAsflCxY/edit?usp=sharing
> >
> > I am hoping that folks in this IDN-WG can alert me to any concerns,
> > omissions, support or needed amendments, clarity etc for any of the
> > recommendations. *Please do so on via comments on the Googledoc by 4th
> > May.*
> >
> > Much obliged,
> > Justine
> >
> > ------------------------------------------------------------
> > *Justine Chew*
> > CPWG SubPro Small Team Lead
> > ------------------------------------------------------------
> > ------
> >
> >
> > On Wed, 11 Mar 2020 at 22:35, Bill Jouris <b_jouris at yahoo.com <mailto:b_jouris at yahoo.com> > wrote:
> >
> >> Hi Edmon,
> >>
> >> A couple of thoughts.
> >>
> >> First, you speak of "IDN Variant TLDs".  But the situation is rather
> >> murkier than that.  As the TLD process is being implemented, there
> >> are two distinct categories of conflicts: Variants and "Confusables".
> >> The Variants label is being restricted to an extremely limited number
> >> of cases which are so overwhelmingly indistinguishable that rejection
> >> of conflicting cases can be automated.  For proposed registrations
> >> which involve mere Confusables, the plan is for a Similarity Review Panel to
> manually compare the two TLDs.
> >>
> >> That panel is not available for SLDs.  And involves a level of
> >> judgement which may or may not be provided by whatever (if any)
> >> mechanisms the registries choose to provide for cases involving
> >> Confusables.  If we keep saying TLD Variants, there is the risk that
> >> the registries will simply ignore cases with Confusables as "review
> >> not required" -- that is, the situation remains mostly in react mode.
> >>
> >> Second, as noted the criteria for Variants are being drawn extremely
> >> narrowly.  In the Generation Panel I am on, everyone has been so
> >> immersed in the various glyphs that even the non-linguists among us
> >> have what amounts to a professional knowledge of what the different
> >> diactitics are, and how they differ from one another.  (We retain
> >> some divergence of opinion as to what a "reasonably careful user"
> >> will actually be able to distinguish. But nobody is under the
> >> misapprehension that the ability of normal users to distinguish
> >> similar glyphs is anywhere near that.)  Plus, we are making out
> >> judgments while comparing glyphs side-by-side -- a luxury that normal
> >> users will not have.  For some of us, a difference of just 1 or
> >> 2 pixels seems to be sufficient to reject a pair as Variants.
> >>
> >> Third, the Latin Generation Panel has received direction that the
> >> sets of variants must not be "too large".  That is, if there is a set
> >> of variants (generated via transitivity) which is too big, we must
> >> select one pair, no matter how similar, to demote to Confusable.  It
> >> isn't clear whether the problem is here.  Perhaps there is some
> >> restriction on what the software for comparing proposed TLDs can
> >> handle -- wildly unlikely as that would be with modern computing
> >> capacity.  But no other justification presents itself.  But whatever
> >> the reason, this further reduces the number of cases of "Variants".
> >>
> >> At minimum, I would think that the registries' direction from ICANN
> >> when addressing SLD conflicts should include everything identified as
> >> either Variant or Confusable.  That will still leave scope for
> >> problems, but at least will reduce it.  And then, in my opinion that
> >> direction should take the form of an amendment to the contracts.
> >> Anything less leaves way too much discretion.
> >>
> >> I would also note again that ICANN is publishing tables of those
> >> Variants and Confusables.  Which makes us an accessory before the
> >> fact whenever a bad actor uses those tables to generate an abusive
> >> domain name.  Not sure where ICANN's lawyers are on this.  But having
> >> seen California courts in action on class action law suits, I worry
> >> about what will potentially hit ICANN as a result.
> >>
> >> Bill Jouris
> >>
> >>
> >> On Thursday, February 27, 2020, 07:56:27 PM PST, Edmon
> >> <edmon at isoc.hk <mailto:edmon at isoc.hk> >
> >> wrote:
> >>
> >>
> >> Comments inline below:
> >>
> >> > -----Original Message-----
> >> > From: IDN-WG [mailto:idn-wg-bounces at atlarge-lists.icann.org <mailto:idn-wg-bounces at atlarge-lists.icann.org> ] On
> >> > Behalf
> >> Of
> >> > Justine Chew
> >> > Sent: Friday, February 28, 2020 11:35 AM
> >> > To: IDN-WG <idn-wg at atlarge-lists.icann.org <mailto:idn-wg at atlarge-lists.icann.org> >
> >> > Subject: Re: [IDN-WG] Request for comments to IDN and UA
> >> > preliminary scorecards in context to Subsequent Procedures
> >> >
> >> > In  Internationalized Domain Names draft preliminary scorecard as
> >> > at 16
> >> Feb
> >> > 2020
> >> > <
> >>
> https://community.icann.org/download/attachments/111390697/02.%20DRAF
> >> T%20
> >> > At-Large%20SubPro%20Scorecard%2016.02.2020%20-
> >> >
> %20IDNs%20Internationalized%20Domain%20Names.pdf?version=1&modifica
> >> > tion
> >> > Date=1581914542839&api=v2>
> >>
> >> 1 comment on the scorecard:
> >> Regarding PDT, I think in general, I understand and can agree to the
> >> principal that PDT should be required.  However, in the future there
> >> should be 1 PDT for delegation of ALL IDN variant TLDs alongside the
> >> primary (applied for) IDN TLD (i.e. 1 PDT for whatever TLD delegated,
> >> IDN or ASCII, with or without IDN Variant TLDs).  That way it does
> >> not discriminate IDN TLDs that need IDN Variant TLDs to best serve
> >> users to have to jump through more hoops.  For already delegated IDN
> >> gTLDs, I can see the value for a simple PDT.
> >>
> >> > under
> >> > 'Pending Issues':
> >> >
> >> > *Point 8.  RZ-LGRs limited to generating IDN variants* Q1. What
> >> > about
> >> when RZ-
> >> > LGRs are not yet in existence? Should absence lead to variant label
> >> being blocked
> >> > or not being able to be allocated?
> >> >
> >>
> >> It needs to be blocked/reserved and not being able to be allocated,
> >> this is to avoid a situation where another IDN TLD application comes
> >> along and has a conflict with the IDN Variant.  I.e. there needs to
> >> at least be a way to say if a new IDN TLD application arrives,
> >> whether it is the primary TLD (applied for string) or its IDN
> >> Variants, they must not conflict with the IDN Variants of the earlier
> >> applied for IDN TLD (and its possible IDN
> >> Variants)
> >>
> >> >  ....*"the ICANN Board resolved on 25 September 2010 that "no
> >> > variants
> >> of gTLDs
> >> > will be delegated ... until appropriate variant management
> >> > solutions
> >> are developed."
> >> > Subsequent work by ICANN organization and the community led to the
> >> identification
> >> > of two issues: (i) there is no accepted definition for variant
> >> > TLDs,
> >> and (ii) there is no
> >> > 'variant management' mechanism for
> >> > TLDs.*
> >> >
> >> > *The first issue is addressed by the Root Zone Label Generation
> >> > Rules
> >> > (RZ-LGR) Project
> >> > <https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en>.
> >> To address
> >> > the second issue, ICANN organization is working with the community
> >> > to
> >> develop
> >> > mechanisms for IDN variant TLD implementation."*
> >> >
> >> > Source:
> >> >
> >> https://www.icann.org/resources/pages/idn-variant-tld-implementation-
> >> 2018-07-26-en
> >> >
> >> > Q2. Are scripts for which RZ-LGRs Project does not yet cover in
> >> > danger
> >> of
> >> > potential/incidence of hijacking, abuse etc because no LGRs
> >> > currently
> >> exist for those
> >> > scripts?
> >> >
> >> > *Point 11. Coordination with IDN Variant Management Framework* Q3.
> >> > If
> >> the answer
> >> > to Q2 is yes, then does the IDN Variant TLD Implementation (4.0?) <
> >> https://www.icann.org/resources/pages/idn-variant-tld-implementation-
> >> 2018-07-26-
> >> > en>Framework
> >> > provide adequate insight and/or solution to this issue?
> >> >
> >>
> >> Yes it should. In those cases, it is a policy question whether the
> >> application can continue to be pending in the first place, and it is
> >> a technical/security issue that it cannot be delegated into the root.
> >>
> >> > *Point 9. Bundling of SL IDN variants* Bill's comments below
> >> > appears to raise an issue of SLD confusion
> >> involving IDN
> >> > characters (perhaps I'm not using the correct term but Bill has
> >> described an example
> >> > below) where harm exists - whether it is exploited through
> >> > malicious
> >> acts or not.
> >> >
> >> > Q4. Do rules for bundling of SL IDN variants even consider this? Or
> >> > it
> >> is an issue
> >> > that goes far beyond bundling?
> >>
> >> Yes it should. This was supposed to be dealt with in the ICANN IDN
> >> Implementation guidelines 4.0, which is incorporated into the
> >> Registry RAs and Registrar RAAs.  However, the RySG has been raising
> >> some concerns for its adoption by the board.  Once the IDN
> >> Implementation Guidelines can be updated, it should provide a much
> stronger framework for SLDs and bundling.
> >>
> >> >
> >> > Q5. What could be done to better address this issue? Would
> >> > requiring
> >> "*registry
> >> > contracts be modified to require that SLDs which differ only by
> >> variants (and
> >> > confusables) be blocked*." be an acceptable solution?
> >>
> >> Push through for the adoption of the IDN Implementation guidelines
> >> 4.0 I think is the most immediate one.  This will/should also be part
> >> of the IDN Variant PDP that hopefully would come soon from the GNSO.
> >>
> >> Edmon
> >>
> >>
> >> >
> >> > Thanks,
> >> > Justine
> >> >
> >> > On Fri, 28 Feb 2020 at 02:54, Bill Jouris <b_jouris at yahoo.com <mailto:b_jouris at yahoo.com> > wrote:
> >> >
> >> > > I have been working on one of the IDN project groups (the Latin
> >> > > Generation Panel).  As a result, I have seen some disconnects
> >> > > between what we are doing there and what is discussed in the
> presentation.
> >> > > Allow me to note a couple of issues I see:
> >> > >
> >> > > First, there are references (for example Slides 7 and 8) to
> >> "variants".
> >> > > At the Generation Panel, we are making decisions about what
> >> > > constitutes a variant.  There is strong push from above to make
> >> > > the criteria as strict/narrow as possible, so as to keep the
> >> > > number of variants low.  To the point of requests to remove some
> >> > > variant pairs which are truly indistinguishable, simple because
> >> > > the variant set is
> >> "too large".
> >> > >
> >> > > Most of the cases of characters (letters plus diacritics in our
> >> > > particular script, although there are also cross-script variants
> >> > > to
> >> > > consider) which are readily mistaken for each other are being
> >> relegated to
> >> > "confusables".
> >> > > That is, characters with differences that a few sharp-eyed users
> >> > > will notice, even though the vast majority of users will not.
> >> > > For TLDs, there are apparently plans to have cases involving the
> >> > > latter manually evaluated.  But whether they should be considered
> >> > > "variants" as the WG uses the term, or how else to identify them, is not
> obvious.
> >> > >
> >> > > Second, most of the discussion here involves TLDs.  But there
> >> > > would seem to be an even larger potential for problems with SLDs.
> >> > > At the moment, decisions about what registrations of SLDs to
> >> > > allow and what to block are left entirely to the discretion of
> >> > > the individual registries.  ICANN makes no requirement, either in
> >> > > the registry contracts or otherwise, restricting the use of
> >> > > variants (under
> >> whatever definition).
> >> > >
> >> > > There was discussion at Montreal of a recent problem involving
> >> > > someone registering a domain name which was identical to the name
> >> > > used by EasyJet, except that the J was replaced by an I.  (The
> >> > > problem was eventually resolved by revoking the second
> >> > > registration.)  Even though users are typically very familiar
> >> > > with both letters, there were a number of users who were
> >> > > successfully scammed by the second
> >> registration.
> >> > >
> >> > > How much easier would it be to sow confusion if the registration
> >> > > involved characters that most users are NOT familiar with?  For
> >> > > example, a Small Letter I with Ogonek ( į ) occurs only in Lithuanian.
> >> > > Like a Small Letter J, it continues below the line -- making it
> >> > > substantially harder to spot as a substitution.  easyįet.com <http://xn--easyet-e9a.com> 
> >> <http://xn--easyet-e9a.com>
> >> > > <http://xn--et-9oa.com> is even easier to mistake for easyjet.com <http://easyjet.com> 
> >> than
> >> > > easyiet.com <http://easyiet.com>  was.  For TLD registrations, attempted registration
> >> > > with only this difference would be blocked.  But for SLDs, it
> >> > > would be available.  And this is just one of dozens, perhaps
> >> > > hundreds, of
> >> opportunities for
> >> > user confusion.
> >> > >
> >> > > Note also that ICANN will be publishing tables of variants (and
> >> > > confusables) whose use in TLDs is restricted.  Those tables then
> >> > > become a resource for any bad actor looking for ways to create an
> >> > > SLD which will confuse users.
> >> > >
> >> > > My thought is that the registry contracts should be modified to
> >> > > *require* that SLDs which differ only by variants (and
> >> > > confusables)
> >> be blocked.
> >> > > Otherwise, we are looking at significant increases in the number
> >> > > of cases which, like with the EasyJet case, are only addressed
> >> > > after the damage has been done.  Prevention seems like a far better
> way to go.
> >> > >
> >> > > Bill Jouris
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > From: *Justine Chew* <justine.chew.icann at gmail.com <mailto:justine.chew.icann at gmail.com> >
> >> > > Date: Mon, 17 Feb 2020 at 14:26
> >> > > Subject: Request for comments to IDN and UA preliminary
> >> > > scorecards in context to Subsequent Procedures
> >> > > To: IDN-WG <idn-wg at atlarge-lists.icann.org <mailto:idn-wg at atlarge-lists.icann.org> >
> >> > >
> >> > >
> >> > > Dear IDN-WG colleagues,
> >> > >
> >> > > Some of you will know that the At-Large Consolidated Policy
> >> > > Working Group
> >> > > (CPWG) is in the process of reviewing the anticipated
> >> > > recommendations (also affirmations and implementation guidance
> >> > > where available) of the New gTLD Subsequent Procedures PDP WG
> >> > > ahead of the release of its draft final report later this year.
> >> > >
> >> > > The process adopted by CPWG is to review a series of At-Large
> >> > > preliminary scorecards on various topics of high and medium
> >> > > priority from the end-users' perspective. It was agreed that
> >> > > assistance be sought from members of the IDN-WG on the
> >> > > preliminary scorecards for Universal Acceptance and
> >> > > Internationalized Domain Names, as both areas are considered key
> >> > > foci for the IDN-WG, given the expertise and
> >> interest of its
> >> > membership.
> >> > >
> >> > > Thus, please find for comments the following:
> >> > >
> >> > >    - Universal Acceptance draft preliminary scorecard as at 16
> >> > > Feb
> >> 2020
> >> > >
> >> > <
> >>
> https://community.icann.org/download/attachments/111390697/03.%20DRAF
> >> T%20
> >> > At-Large%20SubPro%20Scorecard%2016.02.2020%20-
> >> >
> %20UA%20Universal%20Acceptance.pdf?version=1&modificationDate=15819
> >> > 1464
> >> > 8067&api=v2> (contains
> >> > >    draft SubPro WG affirmations, recommendations & implementation
> >> guidelines)
> >> > >    - Internationalized Domain Names draft preliminary scorecard
> >> > > as at
> >> 16
> >> > >    Feb 2020
> >> > >
> >> > > <
> >>
> https://community.icann.org/download/attachments/111390697/02.%20DRAF
> >> > > T%20At-Large%20SubPro%20Scorecard%2016.02.2020%20-
> >> > %20IDNs%20Internatio
> >> > >
> >> >
> nalized%20Domain%20Names.pdf?version=1&modificationDate=15819145428
> >> > 39&
> >> > > api=v2>
> >> > >
> >> > >
> >> > > Please bear in mind that while we welcome comments in general,
> >> > > the CPWG Small Team working to finalize and consolidate the
> >> > > scorecards in due course will attempt to do so by considering
> >> > > feedback which ought to be taken up (or re-taken up, as the case
> >> > > may be) versus which
> >> might be omitted.
> >> > >
> >> > > The format of the preliminary scorecards provide an idea on the
> >> > > Small Team's approach. We also suggest that you peruse the
> >> > > presentation <
> >>
> https://community.icann.org/download/attachments/111390697/01.%20SubP
> >> > >
> >> >
> ro%20IDNs%20as%20at%2026.08.2019%20for%20CPWG.pdf?version=1&modifi
> c
> >> > a
> >> > ti
> >> > > onDate=1566791519000&api=v2> setting out the status of SubPro WG
> >> > deliberations against the ALAC's last public comment input as at 26
> >> August 2019.
> >> > >
> >> > > Perhaps some consideration for these preliminary scorecards can
> >> > > factored into any planned face-to-face meeting at ICANN67.
> >> > >
> >> > > Many thanks in advance,
> >> > > Justine
> >> > >
> >> > > ------------------------------------------------------------
> >> > > *Justine Chew*
> >> > > CPWG SubPro Small Team Lead
> >> > > At-Large liaison for Subsequent Procedures
> >> > > ------------------------------------------------------------
> >> > >
> >> > _______________________________________________
> >> > IDN-WG mailing list
> >> > IDN-WG at atlarge-lists.icann.org <mailto:IDN-WG at atlarge-lists.icann.org> 
> >> > https://atlarge-lists.icann.org/mailman/listinfo/idn-wg
> >> >
> >> > IDN WG Wiki:
> >> https://community.icann.org/display/atlarge/At-Large+IDN+Policy
> >> > _______________________________________________
> >> > By submitting your personal data, you consent to the processing of
> >> > your
> >> personal
> >> > data for purposes of subscribing to this mailing list accordance
> >> > with
> >> the ICANN
> >> > Privacy Policy (https://www.icann.org/privacy/policy) and the
> >> > website
> >> Terms of
> >> > Service (https://www.icann.org/privacy/tos). You can visit the
> >> > Mailman
> >> link above to
> >> > change your membership status or configuration, including
> >> unsubscribing, setting
> >> > digest-style delivery or disabling delivery altogether (e.g., for a
> >> vacation), and so on.
> >>
> >>
> >> _______________________________________________
> >> IDN-WG mailing list
> >> IDN-WG at atlarge-lists.icann.org <mailto:IDN-WG at atlarge-lists.icann.org> 
> >> https://atlarge-lists.icann.org/mailman/listinfo/idn-wg
> >>
> >> IDN WG Wiki:
> >> https://community.icann.org/display/atlarge/At-Large+IDN+Policy
> >> _______________________________________________
> >> By submitting your personal data, you consent to the processing of
> >> your personal data for purposes of subscribing to this mailing list
> >> accordance with the ICANN Privacy Policy
> >> (https://www.icann.org/privacy/policy) and the website Terms of
> >> Service (https://www.icann.org/privacy/tos). You can visit the
> >> Mailman link above to change your membership status or configuration,
> >> including unsubscribing, setting digest-style delivery or disabling delivery
> altogether (e.g., for a vacation), and so on.
> >>
> >
> _______________________________________________
> IDN-WG mailing list
> IDN-WG at atlarge-lists.icann.org <mailto:IDN-WG at atlarge-lists.icann.org> 
> https://atlarge-lists.icann.org/mailman/listinfo/idn-wg
> 
> IDN WG Wiki: https://community.icann.org/display/atlarge/At-
> Large+IDN+Policy
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance with
> the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the
> website Terms of Service (https://www.icann.org/privacy/tos). You can visit
> the Mailman link above to change your membership status or configuration,
> including unsubscribing, setting digest-style delivery or disabling delivery
> altogether (e.g., for a vacation), and so on.



More information about the IDN-WG mailing list