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

Justine Chew justine.chew.icann at gmail.com
Fri Jun 12 01:57:15 UTC 2020 

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


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://gnso.icann.org/sites/default/files/file/field-file-attach/idn-scoping-team-final-report-17jan20-en.pdf
<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>

 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> 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>
> *Sent:* Tuesday, May 5, 2020 5:57 PM
> *To:* Edmon <edmon at isoc.hk>
> *Cc:* 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,
>
> 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> 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> On Behalf Of
> Justine
> > Chew
> > Sent: Tuesday, May 5, 2020 10:23 AM
> > To: IDN-WG <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
> >
> > 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> 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>
> > >> wrote:
> > >>
> > >>
> > >> Comments inline below:
> > >>
> > >> > -----Original Message-----
> > >> > From: IDN-WG [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>
> > >> > 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>
> 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
> > >> than
> > >> > > 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>
> > >> > > 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>
> > >> > >
> > >> > >
> > >> > > 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
> > >> > 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
> > >> 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
> > 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