Further on dot québec
![](https://secure.gravatar.com/avatar/76a1f8e5f58cac351462046aebc54e12.jpg?s=120&d=mm&r=g)
I have been studying the Latin Script Root Zone Label Generation Rules [here <https://www.icann.org/sites/default/files/lgr/proposal-japanese-lgr-20dec21-en.xml>] and, for practical purposes, (U+0065) vs. é (U+00E9) are not variants. The variants for lower case Latin letter "e" are listed under "Variant Set 3" and consist of one homoglyph (forward and reverse mapping) and one out-of-repertoire (reflexive) instance, both which do not apply here. Also, é (U+00E9) is recognized as part of the French language in the document, so linguistic relevance is recognized there. Potential for malice also does not come up as a significant concern in the LGR, as opposed to something like dotted i (U+0069) vs. dotless i (U+0131), for example. That said, considering that we are dealing with a geoTLD, linguistic and cultural relevance are important aspects, and looking into the writing of the word "Québec" on the Web, both the the "e" and "é" cases seem to be widely employed, in such a way that they are interchangeable in a way. If these TLDs were to be managed independently, that would almost certainly lead to confusion. However, the requestor of the accented TLD is the same as that of the ASCII TLD, which is PointQuébec, so we are looking into a "same entity" situation. If PointQuébec were to run both TLDs as if they were the same (as if they were variants), meaning that domain names would resolve consistently instead of being operated independently, this would allow the people of Québec the linguistic freedom to utilize their language while at the same time avoiding confusion. Since, as Seb pointed out, this is the only applicant from the first round reaching out to have this issue resolved, it does not seem to be out of scope to simply recognize their request, and allow them to operate the TLDs in this way, more than anything because there seems to be no good reason not to. We would just need to be very clear about the necessity of both TLDs operating in this consistent manner. Best, -- Mark W. Datysgeld [markwd.website <https://markwd.website>] Director at Governance Primer [governanceprimer.com <https://governanceprimer.com>] ICANN GNSO Councilor
![](https://secure.gravatar.com/avatar/fcf74043cc2f75a28592e1a65aa13b80.jpg?s=120&d=mm&r=g)
Thanks for your analysis, Mark. I may have missed this, but has there been any discussion around grandfathering or bundles of SLDs under both TLDs that would help avoid confusion of an identical second level domain under both TLDs? Thomas Von: council <council-bounces@gnso.icann.org> im Auftrag von Mark Datysgeld via council <council@gnso.icann.org> Antworten an: Mark Datysgeld <mark@governanceprimer.com> Datum: Sonntag, 22. Oktober 2023 um 10:17 An: "council@gnso.icann.org" <council@gnso.icann.org> Betreff: [council] Further on dot québec I have been studying the Latin Script Root Zone Label Generation Rules [here<https://www.icann.org/sites/default/files/lgr/proposal-japanese-lgr-20dec21-en.xml>] and, for practical purposes, (U+0065) vs. é (U+00E9) are not variants. The variants for lower case Latin letter "e" are listed under "Variant Set 3" and consist of one homoglyph (forward and reverse mapping) and one out-of-repertoire (reflexive) instance, both which do not apply here. Also, é (U+00E9) is recognized as part of the French language in the document, so linguistic relevance is recognized there. Potential for malice also does not come up as a significant concern in the LGR, as opposed to something like dotted i (U+0069) vs. dotless i (U+0131), for example. That said, considering that we are dealing with a geoTLD, linguistic and cultural relevance are important aspects, and looking into the writing of the word "Québec" on the Web, both the the "e" and "é" cases seem to be widely employed, in such a way that they are interchangeable in a way. If these TLDs were to be managed independently, that would almost certainly lead to confusion. However, the requestor of the accented TLD is the same as that of the ASCII TLD, which is PointQuébec, so we are looking into a "same entity" situation. If PointQuébec were to run both TLDs as if they were the same (as if they were variants), meaning that domain names would resolve consistently instead of being operated independently, this would allow the people of Québec the linguistic freedom to utilize their language while at the same time avoiding confusion. Since, as Seb pointed out, this is the only applicant from the first round reaching out to have this issue resolved, it does not seem to be out of scope to simply recognize their request, and allow them to operate the TLDs in this way, more than anything because there seems to be no good reason not to. We would just need to be very clear about the necessity of both TLDs operating in this consistent manner. Best, -- Mark W. Datysgeld [markwd.website<https://markwd.website>] Director at Governance Primer [governanceprimer.com<https://governanceprimer.com>] ICANN GNSO Councilor
![](https://secure.gravatar.com/avatar/76a1f8e5f58cac351462046aebc54e12.jpg?s=120&d=mm&r=g)
I'm not aware. I wonder if IDN EPDP members could clarify. On 22 Oct 2023 10:37, Thomas Rickert | rickert.law wrote:
Thanks for your analysis, Mark.
I may have missed this, but has there been any discussion around grandfathering or bundles of SLDs under both TLDs that would help avoid confusion of an identical second level domain under both TLDs?
Thomas
*Von: *council <council-bounces@gnso.icann.org> im Auftrag von Mark Datysgeld via council <council@gnso.icann.org> *Antworten an: *Mark Datysgeld <mark@governanceprimer.com> *Datum: *Sonntag, 22. Oktober 2023 um 10:17 *An: *"council@gnso.icann.org" <council@gnso.icann.org> *Betreff: *[council] Further on dot québec
I have been studying the Latin Script Root Zone Label Generation Rules [here <https://www.icann.org/sites/default/files/lgr/proposal-japanese-lgr-20dec21-en.xml>] and, for practical purposes, (U+0065) vs. é (U+00E9) are not variants. The variants for lower case Latin letter "e" are listed under "Variant Set 3" and consist of one homoglyph (forward and reverse mapping) and one out-of-repertoire (reflexive) instance, both which do not apply here. Also, é (U+00E9) is recognized as part of the French language in the document, so linguistic relevance is recognized there.
Potential for malice also does not come up as a significant concern in the LGR, as opposed to something like dotted i (U+0069) vs. dotless i (U+0131), for example.
That said, considering that we are dealing with a geoTLD, linguistic and cultural relevance are important aspects, and looking into the writing of the word "Québec" on the Web, both the the "e" and "é" cases seem to be widely employed, in such a way that they are interchangeable in a way. If these TLDs were to be managed independently, that would almost certainly lead to confusion.
However, the requestor of the accented TLD is the same as that of the ASCII TLD, which is PointQuébec, so we are looking into a "same entity" situation. If PointQuébec were to run both TLDs as if they were the same (as if they were variants), meaning that domain names would resolve consistently instead of being operated independently, this would allow the people of Québec the linguistic freedom to utilize their language while at the same time avoiding confusion.
Since, as Seb pointed out, this is the only applicant from the first round reaching out to have this issue resolved, it does not seem to be out of scope to simply recognize their request, and allow them to operate the TLDs in this way, more than anything because there seems to be no good reason not to. We would just need to be very clear about the necessity of both TLDs operating in this consistent manner.
Best,
-- Mark W. Datysgeld [markwd.website <https://markwd.website>] Director at Governance Primer [governanceprimer.com <https://governanceprimer.com>] ICANN GNSO Councilor
-- Mark W. Datysgeld [markwd.website <https://markwd.website>] Director at Governance Primer [governanceprimer.com <https://governanceprimer.com>] ICANN GNSO Councilor
![](https://secure.gravatar.com/avatar/1dbf8c451f9f2ade280a83eb78d82c6b.jpg?s=120&d=mm&r=g)
thanks this is helpful. Does the fact that Canadians tend to use the CSA standard bilingual keyboard make any difference? If you select a french keyboard you have no problem, otherwise it is tough to do accents...not sure this assists this argument, but it is life in an officially bilingual environment... cheers Stephanie Sent from my iPhone On Oct 22, 2023, at 10:42, Mark Datysgeld via council <council@gnso.icann.org> wrote: I'm not aware. I wonder if IDN EPDP members could clarify. On 22 Oct 2023 10:37, Thomas Rickert | rickert.law wrote: Thanks for your analysis, Mark. I may have missed this, but has there been any discussion around grandfathering or bundles of SLDs under both TLDs that would help avoid confusion of an identical second level domain under both TLDs? Thomas Von: council <council-bounces@gnso.icann.org><mailto:council-bounces@gnso.icann.org> im Auftrag von Mark Datysgeld via council <council@gnso.icann.org><mailto:council@gnso.icann.org> Antworten an: Mark Datysgeld <mark@governanceprimer.com><mailto:mark@governanceprimer.com> Datum: Sonntag, 22. Oktober 2023 um 10:17 An: "council@gnso.icann.org"<mailto:council@gnso.icann.org> <council@gnso.icann.org><mailto:council@gnso.icann.org> Betreff: [council] Further on dot québec I have been studying the Latin Script Root Zone Label Generation Rules [here<https://www.icann.org/sites/default/files/lgr/proposal-japanese-lgr-20dec21-en.xml>] and, for practical purposes, (U+0065) vs. é (U+00E9) are not variants. The variants for lower case Latin letter "e" are listed under "Variant Set 3" and consist of one homoglyph (forward and reverse mapping) and one out-of-repertoire (reflexive) instance, both which do not apply here. Also, é (U+00E9) is recognized as part of the French language in the document, so linguistic relevance is recognized there. Potential for malice also does not come up as a significant concern in the LGR, as opposed to something like dotted i (U+0069) vs. dotless i (U+0131), for example. That said, considering that we are dealing with a geoTLD, linguistic and cultural relevance are important aspects, and looking into the writing of the word "Québec" on the Web, both the the "e" and "é" cases seem to be widely employed, in such a way that they are interchangeable in a way. If these TLDs were to be managed independently, that would almost certainly lead to confusion. However, the requestor of the accented TLD is the same as that of the ASCII TLD, which is PointQuébec, so we are looking into a "same entity" situation. If PointQuébec were to run both TLDs as if they were the same (as if they were variants), meaning that domain names would resolve consistently instead of being operated independently, this would allow the people of Québec the linguistic freedom to utilize their language while at the same time avoiding confusion. Since, as Seb pointed out, this is the only applicant from the first round reaching out to have this issue resolved, it does not seem to be out of scope to simply recognize their request, and allow them to operate the TLDs in this way, more than anything because there seems to be no good reason not to. We would just need to be very clear about the necessity of both TLDs operating in this consistent manner. Best, -- Mark W. Datysgeld [markwd.website<https://markwd.website>] Director at Governance Primer [governanceprimer.com<https://governanceprimer.com>] ICANN GNSO Councilor -- Mark W. Datysgeld [markwd.website<https://markwd.website>] Director at Governance Primer [governanceprimer.com<https://governanceprimer.com>] ICANN GNSO Councilor _______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council _______________________________________________ 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.
![](https://secure.gravatar.com/avatar/cfd6147db81921c1c0fd4a73657bed48.jpg?s=120&d=mm&r=g)
Absolutely Thomas, it is not just a simple question of "let them have the TLD". Susan Payne Head of Legal Policy Com Laude T +44 (0) 20 7421 8250 Ext 255 [cid:image001.png@01DA04D6.62A2A670]<https://comlaude.com/> Follow us on Linkedin<https://t-uk.xink.io/Tracking/Index/pRkAAGVfAADw_RQA0> and YouTube<https://t-uk.xink.io/Tracking/Index/bhkAAGVfAADw_RQA0> From: council <council-bounces@gnso.icann.org> On Behalf Of Thomas Rickert | rickert.law via council Sent: Sunday, October 22, 2023 10:38 AM To: Mark Datysgeld <mark@governanceprimer.com>; council@gnso.icann.org Subject: Re: [council] Further on dot québec Thanks for your analysis, Mark. I may have missed this, but has there been any discussion around grandfathering or bundles of SLDs under both TLDs that would help avoid confusion of an identical second level domain under both TLDs? Thomas Von: council <council-bounces@gnso.icann.org<mailto:council-bounces@gnso.icann.org>> im Auftrag von Mark Datysgeld via council <council@gnso.icann.org<mailto:council@gnso.icann.org>> Antworten an: Mark Datysgeld <mark@governanceprimer.com<mailto:mark@governanceprimer.com>> Datum: Sonntag, 22. Oktober 2023 um 10:17 An: "council@gnso.icann.org<mailto:council@gnso.icann.org>" <council@gnso.icann.org<mailto:council@gnso.icann.org>> Betreff: [council] Further on dot québec I have been studying the Latin Script Root Zone Label Generation Rules [here<https://www.icann.org/sites/default/files/lgr/proposal-japanese-lgr-20dec21-en.xml>] and, for practical purposes, (U+0065) vs. é (U+00E9) are not variants. The variants for lower case Latin letter "e" are listed under "Variant Set 3" and consist of one homoglyph (forward and reverse mapping) and one out-of-repertoire (reflexive) instance, both which do not apply here. Also, é (U+00E9) is recognized as part of the French language in the document, so linguistic relevance is recognized there. Potential for malice also does not come up as a significant concern in the LGR, as opposed to something like dotted i (U+0069) vs. dotless i (U+0131), for example. That said, considering that we are dealing with a geoTLD, linguistic and cultural relevance are important aspects, and looking into the writing of the word "Québec" on the Web, both the the "e" and "é" cases seem to be widely employed, in such a way that they are interchangeable in a way. If these TLDs were to be managed independently, that would almost certainly lead to confusion. However, the requestor of the accented TLD is the same as that of the ASCII TLD, which is PointQuébec, so we are looking into a "same entity" situation. If PointQuébec were to run both TLDs as if they were the same (as if they were variants), meaning that domain names would resolve consistently instead of being operated independently, this would allow the people of Québec the linguistic freedom to utilize their language while at the same time avoiding confusion. Since, as Seb pointed out, this is the only applicant from the first round reaching out to have this issue resolved, it does not seem to be out of scope to simply recognize their request, and allow them to operate the TLDs in this way, more than anything because there seems to be no good reason not to. We would just need to be very clear about the necessity of both TLDs operating in this consistent manner. Best, -- Mark W. Datysgeld [markwd.website<https://markwd.website/>] Director at Governance Primer [governanceprimer.com<https://governanceprimer.com/>] ICANN GNSO Councilor ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the "Com Laude Group") does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com<https://comlaude.com/>
![](https://secure.gravatar.com/avatar/76a1f8e5f58cac351462046aebc54e12.jpg?s=120&d=mm&r=g)
But it is an exception, at least for the time being. Can we be on the same page that it is an exception? On 22 Oct 2023 10:56, Susan Payne wrote:
Absolutely Thomas, it is not just a simple question of “let them have the TLD”.
Susan Payne Head of Legal Policy Com Laude *T*+44 (0) 20 7421 8250 *Ext* 255
/Follow us on Linkedin <https://t-uk.xink.io/Tracking/Index/pRkAAGVfAADw_RQA0> and YouTube <https://t-uk.xink.io/Tracking/Index/bhkAAGVfAADw_RQA0>/
*From:*council <council-bounces@gnso.icann.org> *On Behalf Of *Thomas Rickert | rickert.law via council *Sent:* Sunday, October 22, 2023 10:38 AM *To:* Mark Datysgeld <mark@governanceprimer.com>; council@gnso.icann.org *Subject:* Re: [council] Further on dot québec
Thanks for your analysis, Mark.
I may have missed this, but has there been any discussion around grandfathering or bundles of SLDs under both TLDs that would help avoid confusion of an identical second level domain under both TLDs?
Thomas
*Von: *council <council-bounces@gnso.icann.org> im Auftrag von Mark Datysgeld via council <council@gnso.icann.org> *Antworten an: *Mark Datysgeld <mark@governanceprimer.com> *Datum: *Sonntag, 22. Oktober 2023 um 10:17 *An: *"council@gnso.icann.org" <council@gnso.icann.org> *Betreff: *[council] Further on dot québec
I have been studying the Latin Script Root Zone Label Generation Rules [here <https://www.icann.org/sites/default/files/lgr/proposal-japanese-lgr-20dec21-en.xml>] and, for practical purposes, (U+0065) vs. é (U+00E9) are not variants. The variants for lower case Latin letter "e" are listed under "Variant Set 3" and consist of one homoglyph (forward and reverse mapping) and one out-of-repertoire (reflexive) instance, both which do not apply here. Also, é (U+00E9) is recognized as part of the French language in the document, so linguistic relevance is recognized there.
Potential for malice also does not come up as a significant concern in the LGR, as opposed to something like dotted i (U+0069) vs. dotless i (U+0131), for example.
That said, considering that we are dealing with a geoTLD, linguistic and cultural relevance are important aspects, and looking into the writing of the word "Québec" on the Web, both the the "e" and "é" cases seem to be widely employed, in such a way that they are interchangeable in a way. If these TLDs were to be managed independently, that would almost certainly lead to confusion.
However, the requestor of the accented TLD is the same as that of the ASCII TLD, which is PointQuébec, so we are looking into a "same entity" situation. If PointQuébec were to run both TLDs as if they were the same (as if they were variants), meaning that domain names would resolve consistently instead of being operated independently, this would allow the people of Québec the linguistic freedom to utilize their language while at the same time avoiding confusion.
Since, as Seb pointed out, this is the only applicant from the first round reaching out to have this issue resolved, it does not seem to be out of scope to simply recognize their request, and allow them to operate the TLDs in this way, more than anything because there seems to be no good reason not to. We would just need to be very clear about the necessity of both TLDs operating in this consistent manner.
Best,
-- Mark W. Datysgeld [markwd.website <https://markwd.website/>] Director at Governance Primer [governanceprimer.com <https://governanceprimer.com/>] ICANN GNSO Councilor
------------------------------------------------------------------------ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com <https://comlaude.com/>
-- Mark W. Datysgeld [markwd.website <https://markwd.website>] Director at Governance Primer [governanceprimer.com <https://governanceprimer.com>] ICANN GNSO Councilor
![](https://secure.gravatar.com/avatar/969a94dd658fe1318210c671a6be45c9.jpg?s=120&d=mm&r=g)
Hi all - I think this conversation points out the need for an Issues Report before Council can deal effectively with recommended next steps. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2024 anneicanngnso@gmail.com On Sun, Oct 22, 2023 at 2:04 AM Mark Datysgeld via council < council@gnso.icann.org> wrote:
But it is an exception, at least for the time being. Can we be on the same page that it is an exception? On 22 Oct 2023 10:56, Susan Payne wrote:
Absolutely Thomas, it is not just a simple question of “let them have the TLD”.
Susan Payne Head of Legal Policy Com Laude *T* +44 (0) 20 7421 8250 *Ext* 255
*Follow us on Linkedin <https://t-uk.xink.io/Tracking/Index/pRkAAGVfAADw_RQA0> and YouTube <https://t-uk.xink.io/Tracking/Index/bhkAAGVfAADw_RQA0>*
*From:* council <council-bounces@gnso.icann.org> <council-bounces@gnso.icann.org> *On Behalf Of *Thomas Rickert | rickert.law via council *Sent:* Sunday, October 22, 2023 10:38 AM *To:* Mark Datysgeld <mark@governanceprimer.com> <mark@governanceprimer.com>; council@gnso.icann.org *Subject:* Re: [council] Further on dot québec
Thanks for your analysis, Mark.
I may have missed this, but has there been any discussion around grandfathering or bundles of SLDs under both TLDs that would help avoid confusion of an identical second level domain under both TLDs?
Thomas
*Von: *council <council-bounces@gnso.icann.org> im Auftrag von Mark Datysgeld via council <council@gnso.icann.org> *Antworten an: *Mark Datysgeld <mark@governanceprimer.com> *Datum: *Sonntag, 22. Oktober 2023 um 10:17 *An: *"council@gnso.icann.org" <council@gnso.icann.org> *Betreff: *[council] Further on dot québec
I have been studying the Latin Script Root Zone Label Generation Rules [ here <https://www.icann.org/sites/default/files/lgr/proposal-japanese-lgr-20dec21-en.xml>] and, for practical purposes, (U+0065) vs. é (U+00E9) are not variants. The variants for lower case Latin letter "e" are listed under "Variant Set 3" and consist of one homoglyph (forward and reverse mapping) and one out-of-repertoire (reflexive) instance, both which do not apply here. Also, é (U+00E9) is recognized as part of the French language in the document, so linguistic relevance is recognized there.
Potential for malice also does not come up as a significant concern in the LGR, as opposed to something like dotted i (U+0069) vs. dotless i (U+0131), for example.
That said, considering that we are dealing with a geoTLD, linguistic and cultural relevance are important aspects, and looking into the writing of the word "Québec" on the Web, both the the "e" and "é" cases seem to be widely employed, in such a way that they are interchangeable in a way. If these TLDs were to be managed independently, that would almost certainly lead to confusion.
However, the requestor of the accented TLD is the same as that of the ASCII TLD, which is PointQuébec, so we are looking into a "same entity" situation. If PointQuébec were to run both TLDs as if they were the same (as if they were variants), meaning that domain names would resolve consistently instead of being operated independently, this would allow the people of Québec the linguistic freedom to utilize their language while at the same time avoiding confusion.
Since, as Seb pointed out, this is the only applicant from the first round reaching out to have this issue resolved, it does not seem to be out of scope to simply recognize their request, and allow them to operate the TLDs in this way, more than anything because there seems to be no good reason not to. We would just need to be very clear about the necessity of both TLDs operating in this consistent manner.
Best,
-- Mark W. Datysgeld [markwd.website] Director at Governance Primer [governanceprimer.com] ICANN GNSO Councilor ------------------------------ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com <https://comlaude.com/>
-- Mark W. Datysgeld [markwd.website] Director at Governance Primer [governanceprimer.com] ICANN GNSO Councilor _______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
_______________________________________________ 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.
participants (5)
-
Anne ICANN
-
Mark Datysgeld
-
Stephanie Perrin
-
Susan Payne
-
Thomas Rickert | rickert.law