[NCSG-PC] Public comment on spec

[Johan Helsingius]

Great! Fully support this.

	Julf


On 27/01/2026 4:23 pm, farzaneh badii via NCSG-PC wrote:
> Here is what our penholders have drafted: https://docs.google.com/ 
> document/d/1hxr_WoU0tidEu6dgdZ0mbcgwEVrsIcYHud9ZgfeXui0/edit?usp=sharing 
> <https://docs.google.com/document/ 
> d/1hxr_WoU0tidEu6dgdZ0mbcgwEVrsIcYHud9ZgfeXui0/edit?usp=sharing>
> 
> Submitting it in a few hours.
> 
> 
> Farzaneh
> 
> 
> On Tue, Jan 27, 2026 at 12:32 AM farzaneh badii 
> <farzaneh.badii at gmail.com <mailto:farzaneh.badii at gmail.com>> wrote:
> 
>     Hi
> 
>     We are late but we have drafted a one paragraph which we need to
>     submit tomorrow in response to a call for public comment on spec 14.
>     Yao has come up with an excellent system for NPOC which we can use.
>     (have to check with him)
>       If you have other comments let me know.
> 
>     Specification 14 - Variant TLDs: Registrant Choice and Bundling Concerns
>     NCSG is concerned that Section 2.15’s mandatory bundling of variant
>     second-level domain names across TLD Sets inadequately considers
>     registrant autonomy in multilingual contexts. While we understand
>     the technical rationale for preventing confusion through unified
>     allocation, requiring that “all second-level domain names, and any
>     allocatable variants thereof, under the TLD Set is either allocated
>     to the same registrant, or else withheld for possible allocation
>     only to that registrant” creates a forced bundling mechanism that
>     could increase costs and reduce flexibility for community
>     organizations, civil society groups, and individual registrants
>     operating across multiple scripts and languages. This is
>     particularly problematic for communities where different
>     organizations may legitimately represent the same concept or entity
>     in different linguistic or cultural contexts. We recommend that
>     ICANN develop clearer guidance on how registrants can decline
>     variant bundles they do not need, ensure pricing structures do not
>     penalize those required to hold variants they have no use for, and
>     consider whether exceptions should be available for demonstrated
>     community need where different parties have legitimate claims to
>     variants in different scripts. The specification should explicitly
>     preserve registrant choice rather than defaulting to mandatory
>     acquisition models that primarily serve registry operator
>     administrative convenience.​​​​​​​​​​​​​​​​
> 
> 
>     Farzaneh
> 
> 
> _______________________________________________
> NCSG-PC mailing list
> NCSG-PC at lists.ncsg.is
> https://lists.ncsg.is/mailman/listinfo/ncsg-pc