Request for early input to SO/AC/SG/Cs - IDNs EPDP

[Tomslin Samme-Nlar]

Thanks for the comments Farzi.

I take your point on representation and agree that it needs fixing now so
as not to make it 'normal'. Even though I have concerns about our ability
to find and fill more than 2 reps in most WGs, I also appreciate that the
issue of equal representation needs to be separated from our challenge to
have representatives appointed to achieve the objective. This is something
I want our community to think about.

Regarding your comment on the EPDP being unnecessary, that's where I beg to
differ. Some issues the EPDP is addressing are ones that the SubPro WG
deferred because of lack of expertise, like who should apply for a new gTLD
that is a variant of an existing TLD. I also don't think that the current
applicant guide book provides for things like an applicant challenge
process for the outcome of an LGR rules evaluation, perhaps due to an
omission of a letter in a script by a Generation Panel and encouraged by
the conservation principles of the RZ-LGR, but which an applicant believes
is important for their string.

Cheers,
Tomslin


On Mon, 4 Oct 2021 at 11:31, farzaneh badii <farzaneh.badii at gmail.com>
wrote:

> Thank you Tomslin,
>
> There we go, with another unnecessary EPDP. And a bunch of staff
> introduced questions. And as I mentioned before, underrepresented NCSG on
> an EPDP. Which is not an oversight - or if it is, can you please fix it at
> the GNSO council level at some point? NCSG has 3 reps and CSG has 9! I'd
> like the GNSO council members of NCSG to take note of this. It should not
> happen in the future.
>
> In short, I think these questions are unnecessary. The technical
> definitions are out there, and the management and coordination decisions
> have to be made by policy groups that work on generic names-
>
> So going to the questions. Let me clarify why I even understand a page of
> this long-winded document: I was a part of the LGR RZ and helped with the
> Persian version (a Persian speaking linguist took over from me, which is a
> good thing).
>
> There we talked about and came to consensus for technical definitions.
> Next step was for the applicants to just follow ICANN's process to apply to
> manage the variants. The problem is not that the IDNs technical definition
> is ambiguous. The problem is that, ICANN's delegation and coordination
> process are not clear. So this is technically not an IDN related issue.
> It's the generic name delegation process. But what about the ccTLD-IDNs?
> well ICANN decided to give the operation to the operators that managed the
> ccTLDs in latin. Do they want to fix that? I guess not. But they might want
> to expand the definitions in this way to the name of cities in other
> languages. And I think that is what we need to watch and be worried about.
>
> It would be good not to repeat the past mistakes, for example not to
> reserve the second level domains for the same applicant but I tried to
> fight that multiple times and found out this is really a
> rhetorical question, not a policy one. You either confirm what the practice
> is now or you can make eternal objections.
>
> Best
>
>
>
> Farzaneh
>
>
> On Sun, Oct 3, 2021 at 7:56 PM Tomslin Samme-Nlar <mesumbeslin at gmail.com>
> wrote:
>
>> Dear members,
>>
>> As you know, the Internationalized Domain Names (IDNs EPDP) has just
>> begun its work. For those not following it, this is the WG assigned the
>> task to develop policy recommendations on: 1) the definition of gTLDs and
>> the management of variant labels; and 2) how the IDN Implementation
>> Guidelines, which Contracted Parties are required to comply with, should be
>> updated in the future.
>>
>> As a member of the WG myself, I can quickly update that the group has
>> just sent its proposed work schedule to the GNSO council for approval and
>> have started substantial deliberations on the first topic: Consistent
>> definition and technical utilization of Root Zone - Label Generation Rules
>> (RZ-LGR).
>>
>> Which brings me to the reason for my email. The WG is seeking early
>> inputs from the community as part of GNSO policy development requirements.
>> Please see the attached document for more details.
>>
>> Best regards,
>> Tomslin
>>
>> ---------- Forwarded message ---------
>> From: Nathalie Peregrine <nathalie.peregrine at icann.org>
>> Date: Wed, Sep 29, 2021 at 3:20 PM
>> Subject: Request for early input to SO/AC/SG/Cs - IDNs EPDP
>> To: Bruna Martins dos Santos <bruna.mrtns at gmail.com>
>> Cc: Maryam Bakoshi <maryam.bakoshi at icann.org>, Brenda Brewer <
>> brenda.brewer at icann.org>, Andrea Glandon <andrea.glandon at icann.org>,
>> Steve Chan <steve.chan at icann.org>, Emily Barabas <emily.barabas at icann.org>,
>> gnso-secs at icann.org <gnso-secs at icann.org>
>>
>>
>> Dear Bruna,
>>
>>
>>
>> Please find attached a request from the GNSO *Expedited Policy
>> Development Process on Internationalized Domain Names (IDNs EPDP**)*
>>
>> for input from your group on topics within the EPDP’s charter. Responses
>> are requested by 10 November 2021 and may be sent to gnso-secs at icann.org.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> Emily Barabas
>>
>>
>>
>>
>> --
>>
>> *Bruna Martins dos Santos *
>>
>> German Chancellor Fellow 21' (Bundeskanzler-Stipendiatinnen) | Alexander
>> von Humboldt Foundation <https://www.humboldt-foundation.de/>
>>
>> Member | Coalizão Direitos na Rede <https://direitosnarede.org.br/>
>> Chair | Non-Commercial Stakeholder Group at ICANN
>> <https://gnso.icann.org/en/about/stakeholders-constituencies/ncsg>
>> Co-Coordinator | Internet Governance Caucus  <https://igcaucus.org/>
>>
>> Twitter: @boomartins <https://twitter.com/boomartins> // Skype:
>> bruna.martinsantos
>> bruna at dataprivacybr.org and bruna.mrtns at gmail.com
>> _______________________________________________
>> NCSG-PC mailing list
>> NCSG-PC at lists.ncsg.is
>> https://lists.ncsg.is/mailman/listinfo/ncsg-pc
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20211012/b7899b07/attachment.htm>