I am on a business call that is not ending until the top of the hour. I will join after that. Greg On Mon, Sep 1, 2025 at 9:29 PM ICANN At-Large Staff via CPWG <cpwg@icann.org> wrote:

Dear All,

The next *At-Large Consolidated Policy Working Group (CPWG*) Call has been scheduled for *Wednesday, 03 September 2025 at 19:00 UTC* * for 90 mins.*

For other times: https://tinyurl.com/2hhwbxxf

The agenda (to be updated) and call details can be found at: https://icann-community.atlassian.net/wiki/x/AYD9Gg

*Zoom Room: * *https://icann.zoom.us/j/765717566?pwd=UTJCdWRSZVdJNEhOYW02OVBqQVQ1Zz09* <https://icann.zoom.us/j/765717566?pwd=UTJCdWRSZVdJNEhOYW02OVBqQVQ1Zz09> * / **Passcode:* #CPWG2345*

*Real time transcription (RTT)* available at *(subject to availability)*: https://www.streamtext.net/player?event=ICANN

At-Large Consolidated Policy Working Group (CPWG) Wiki Space: https://community.icann.org/x/jYDpB

If you require a dial-out please contact At-Large staff at: staff@atlarge.icann.org

Thank you.

Kind regards,

At-Large Staff

ICANN Policy Staff in support of the At-Large Community

www.icann.org

<https://owa.icann.org/owa/PolicyCalendar@icann.org/?offline=disabled>

_______________________________________________ CPWG mailing list -- cpwg@icann.org To unsubscribe send an email to cpwg-leave@icann.org

_______________________________________________ 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.

-- *____________________* *Greg Shatan* *Chair, NARALO* ​gregshatanalac@gmail.com

Hi, If there was a 2nd round (2026) gTLD applicant that has aligned their application precisely with RFC 8890: a gTLD that doesn’t put the registrant but the internet user (“end user”) front and center: would the list be interested in learning about it? Because in the existing denominations of the DNS nobody cares about the “end user” – ICANN cares about registries, registries care about registrars and registrars care about registrants. The “end user” (internet user) is somehow readily available consumption mass that will willingly endure whatever they get exposed to (I am being sarcastic here): For example scam sites, fake sites, parked (monetized) sites, phishing sites, overly complicated URLs, etc. Regards, Alexander ___________________________________________________________________ Alexander Schubert LinkedIn.com/in/alexanderschubert U.S. +1(202)684-6806 Germany +49(030)8643-7863 From: David Mackey via CPWG <cpwg@icann.org> Sent: Tuesday, September 2, 2025 10:35 PM To: Christopher Wilkinson <cw@christopherwilkinson.eu> Cc: cpwg@icann.org Subject: [CPWG] Re: The Internet is for end users – RFC 8890 (2020) This document is a great find Christopher! Thanks for bringing to everyone's attention. I've been aware of the document since about September 2020, but it hasn't received much attention in the ICANN community. One of the potential weaknesses of the document is Section 5, IANA Considerations ... 5. IANA Considerations This document has no IANA actions. Cheers David On Tue, Sep 2, 2025 at 2:45 PM lists--- via CPWG <cpwg@icann.org <mailto:cpwg@icann.org> > wrote: Good evening: At last week’s CPWG meeting, I mentioned the existence of this document (10 pp). It can be found at: <https://www.rfc-editor.org/info/rfc8890> https://www.rfc-editor.org/info/rfc8890 In general I find it is an admirable statement of intent on behalf of the Internet Architecture Board (IAB), although it does not go into how its aspirations might be realised. Thus it does not amount to a standard or a policy statement. In the words of the principal author (in an e-mail to myself): <<RFC 8890 was an explanation of the IAB's thinking regarding how the IETF community should engage with other communities that its work affects. There were not concrete follow-on steps, beyond a continuing effort to refine how we engage. This has proven relevant especially in policy-adjacent efforts such as the AI Preferences Working Group.>> For present purposes I suggest that we leave it at that, particularly in light of the ICANN and CPWG work loads for the coming months. However, I do think that there is an overhanging question about how the user community engages with the identification, preparation and governance of the Internet Standards that are the RFCs. Regards Christopher Wilkinson (Posted to CPWG mailing List, 2 September 2025) On 27 Aug 2025, at 18:32, ICANN At-Large Staff via CPWG <cpwg@icann.org <mailto:cpwg@icann.org> > wrote _______________________________________________ CPWG mailing list -- cpwg@icann.org <mailto:cpwg@icann.org> To unsubscribe send an email to cpwg-leave@icann.org <mailto:cpwg-leave@icann.org> _______________________________________________ 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.

Dear Olivier, I have summarized it at www.dotairport.org/rfc8890 <http://www.dotairport.org/rfc8890> (feel free to share) Here just a taster: * .airport is for the Internet User – not “for airports” * Thus, our AI agent identifies all relevant domains (think sea.airport, seattle.airport, seatac.airport) of all 4,000 commercial airports globally, registers the domains and forwards them to the respective airport site -e.g. flysea.org (paid for by the registry operator, funded by the EU). * This so the Internet user doesn’t have to wait for the lazy airports to adopt the system: the user may type in ANY known identifier.airport and reaches the official respective airport site. This solves the “registrant adoption problem”: we don’t wait, we do it ON BEHALF of the airports. Airport benefit: They don’t even have to become registrants and can immediately start to use these domains in their public outreach. * Furthermore: for the 1st time EVER internet user behavior can lead to the automatic creation of new domains: once enough users try to reach gattwick.airport (typo with 2 “t”!) the system auto generates that domain and routes it to gatwick.airport! Or disneyworld.airport -> would create that domain and display all airports serving Disneyworld. Sicily.airport! Poland.aiprot! Florida.airport! * It’s like “desire paths” in parks: once a few start to use a certain route (florida.airport) we pave it for all others (create the domain and display all airports serving Florida). Our AI agent does the legwork. * The Internet user is the “King”: if we serve them well, we serve the airports, too! Happy internet user = happy airports! * Public-benefit, EU-based, EU funded nonprofit community priority applicant with harsh eligibility and authentication requirements: “The .bank for airports” – but with 100% built in community member adoption from day one. Airports can instantly use “their” domain without having to register it. They can also become the registrant of course, subject to authentication and commitment to route it to the official website. * I build gTLD applicants for 2 decades now: started .berlin in autumn of 2005, and later the community applicant for .gay. I started .airport in 2017. Small problem: The current AGB draft doesn’t allow us to run thousands of domains on behalf of the airport community members and to the benefit of the Internet user! See www.dotairport.org/agb <http://www.dotairport.org/agb> The AGB doesn’t support that kind of innovation and Internet User Empowering. More about .airport in general: www.dotairport.org <http://www.dotairport.org> – and yes: I will be in Dublin. Regards, Alexander ___________________________________________________________________ Alexander Schubert LinkedIn.com/in/alexanderschubert www.dotAIRPORT.org U.S. +1(202)888-2029 EU +371 26633466 From: Olivier MJ Crépin-Leblond <ocl@gih.com> Sent: Friday, September 5, 2025 12:25 AM To: alexander@schubert.berlin; cpwg@icann.org Subject: Re: [CPWG] Re: The Internet is for end users – RFC 8890 (2020) Dear Alexander, I am intrigued. How would they align with RFC 8890? It has been an aim for At-Large to represent the interests of *all* Internet *users* and not just domain name registrants. Kindest regards, Olivier On 04/09/2025 18:10, alexander--- via CPWG wrote: Hi, If there was a 2nd round (2026) gTLD applicant that has aligned their application precisely with RFC 8890: a gTLD that doesn’t put the registrant but the internet user (“end user”) front and center: would the list be interested in learning about it? Because in the existing denominations of the DNS nobody cares about the “end user” – ICANN cares about registries, registries care about registrars and registrars care about registrants. The “end user” (internet user) is somehow readily available consumption mass that will willingly endure whatever they get exposed to (I am being sarcastic here): For example scam sites, fake sites, parked (monetized) sites, phishing sites, overly complicated URLs, etc. Regards, Alexander ___________________________________________________________________ Alexander Schubert LinkedIn.com/in/alexanderschubert U.S. +1(202)684-6806 Germany +49(030)8643-7863 From: David Mackey via CPWG <mailto:cpwg@icann.org> <cpwg@icann.org> Sent: Tuesday, September 2, 2025 10:35 PM To: Christopher Wilkinson <mailto:cw@christopherwilkinson.eu> <cw@christopherwilkinson.eu> Cc: cpwg@icann.org <mailto:cpwg@icann.org> Subject: [CPWG] Re: The Internet is for end users – RFC 8890 (2020) This document is a great find Christopher! Thanks for bringing to everyone's attention. I've been aware of the document since about September 2020, but it hasn't received much attention in the ICANN community. One of the potential weaknesses of the document is Section 5, IANA Considerations ... 5. IANA Considerations This document has no IANA actions. Cheers David On Tue, Sep 2, 2025 at 2:45 PM lists--- via CPWG <cpwg@icann.org <mailto:cpwg@icann.org> > wrote: Good evening: At last week’s CPWG meeting, I mentioned the existence of this document (10 pp). It can be found at: <https://www.rfc-editor.org/info/rfc8890> https://www.rfc-editor.org/info/rfc8890 In general I find it is an admirable statement of intent on behalf of the Internet Architecture Board (IAB), although it does not go into how its aspirations might be realised. Thus it does not amount to a standard or a policy statement. In the words of the principal author (in an e-mail to myself): <<RFC 8890 was an explanation of the IAB's thinking regarding how the IETF community should engage with other communities that its work affects. There were not concrete follow-on steps, beyond a continuing effort to refine how we engage. This has proven relevant especially in policy-adjacent efforts such as the AI Preferences Working Group.>> For present purposes I suggest that we leave it at that, particularly in light of the ICANN and CPWG work loads for the coming months. However, I do think that there is an overhanging question about how the user community engages with the identification, preparation and governance of the Internet Standards that are the RFCs. Regards Christopher Wilkinson (Posted to CPWG mailing List, 2 September 2025) On 27 Aug 2025, at 18:32, ICANN At-Large Staff via CPWG <cpwg@icann.org <mailto:cpwg@icann.org> > wrote _______________________________________________ CPWG mailing list -- cpwg@icann.org <mailto:cpwg@icann.org> To unsubscribe send an email to cpwg-leave@icann.org <mailto:cpwg-leave@icann.org> _______________________________________________ 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. _______________________________________________ CPWG mailing list -- cpwg@icann.org <mailto:cpwg@icann.org> To unsubscribe send an email to cpwg-leave@icann.org <mailto:cpwg-leave@icann.org> _______________________________________________ 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.

Dear Sivasubramanian, Thanks for your response. There are two issues: 1. Who is eligible as registrant, trying to prevent fraud, imposing, domain hording, ransom requests (aka “domain investing”), etc. 2. Then there is the question of RFC 8890 – how a namespace is (eg .airport or .dublin) managed in a way that PUTS THE INTEREST OF THE INTERNET USER FIRST (and not the interest of ICANN, the RSP, the registry operator, the registrars or the registrants). I have described it in detail on www.dotairport.org/spec5 <http://www.dotairport.org/spec5> on the example of future city gTLDs like “.dublin” (not yet existing), the article is titled: “Unlocking Public Benefit in Generic Term-Based Community-Oriented New gTLDs”. And our .airport registry will do exactly that: putting the needs of the INTERNET USER first! Which is why we want to operate all airport identifiers from day one and already route them to the airports – as a service for the Internet User. Regards, Alexander ___________________________________________________________________ Alexander Schubert LinkedIn.com/in/alexanderschubert www.dotAIRPORT.org U.S. +1(202)888-2029 From: Sivasubramanian M <6.internet@gmail.com> Sent: Wednesday, September 10, 2025 8:57 PM To: alexander@schubert.berlin Cc: CPWG <cpwg@icann.org>; christopher. wilkinson <cw@christopherwilkinson.eu>; Olivier MJ Crepin-Leblond <ocl@gih.com>; avri <doriavr@gmail.com>; Jonathan Zuck <JZuck@innovatorsnetwork.org> Subject: Re: [CPWG] Re: The Internet is for end users – RFC 8890 (2020) First of all, apologies to cpwg for having missed the meeting today. I always look forward to attending cpwg meetings but sometimes miss the meetings ! Thank you CW, RFC 8890 that you have posted here is a very thoughtful RFC. I notice that it was published in 2020. Is there something that CPWG could take this forward, perhaps also debate to expand it it address various concerns? The Internet community has always believed that the Internet is (and should be) user centric. Alexander Schubert, what you have proposed in your message here is also very interesting and pertinent as a notion. That can also be debated and taken forward to the extent possible. There is already some thinking that some important 'generic ' second level domains shouldn't be given away to the first person who pays $10, without the caution that such an important generic names could be mis-commercialised, or become a portal for malware or other form of abuse. Please elaborate. Thank you Sivasubramanian Muthusamy Sivasubramanian Muthusamy sender On Fri, 5 Sept, 2025, 04:21 alexander--- via CPWG, <cpwg@icann.org <mailto:cpwg@icann.org> > wrote: Dear Olivier, I have summarized it at www.dotairport.org/rfc8890 <http://www.dotairport.org/rfc8890> (feel free to share) Here just a taster: * .airport is for the Internet User – not “for airports” * Thus, our AI agent identifies all relevant domains (think sea.airport, seattle.airport, seatac.airport) of all 4,000 commercial airports globally, registers the domains and forwards them to the respective airport site -e.g. flysea.org <http://flysea.org> (paid for by the registry operator, funded by the EU). * This so the Internet user doesn’t have to wait for the lazy airports to adopt the system: the user may type in ANY known identifier.airport and reaches the official respective airport site. This solves the “registrant adoption problem”: we don’t wait, we do it ON BEHALF of the airports. Airport benefit: They don’t even have to become registrants and can immediately start to use these domains in their public outreach. * Furthermore: for the 1st time EVER internet user behavior can lead to the automatic creation of new domains: once enough users try to reach gattwick.airport (typo with 2 “t”!) the system auto generates that domain and routes it to gatwick.airport! Or disneyworld.airport -> would create that domain and display all airports serving Disneyworld. Sicily.airport! Poland.aiprot! Florida.airport! * It’s like “desire paths” in parks: once a few start to use a certain route (florida.airport) we pave it for all others (create the domain and display all airports serving Florida). Our AI agent does the legwork. * The Internet user is the “King”: if we serve them well, we serve the airports, too! Happy internet user = happy airports! * Public-benefit, EU-based, EU funded nonprofit community priority applicant with harsh eligibility and authentication requirements: “The .bank for airports” – but with 100% built in community member adoption from day one. Airports can instantly use “their” domain without having to register it. They can also become the registrant of course, subject to authentication and commitment to route it to the official website. * I build gTLD applicants for 2 decades now: started .berlin in autumn of 2005, and later the community applicant for .gay. I started .airport in 2017. Small problem: The current AGB draft doesn’t allow us to run thousands of domains on behalf of the airport community members and to the benefit of the Internet user! See www.dotairport.org/agb <http://www.dotairport.org/agb> The AGB doesn’t support that kind of innovation and Internet User Empowering. More about .airport in general: www.dotairport.org <http://www.dotairport.org> – and yes: I will be in Dublin. Regards, Alexander ___________________________________________________________________ Alexander Schubert LinkedIn.com/in/alexanderschubert www.dotAIRPORT.org <http://www.dotAIRPORT.org> U.S. +1(202)888-2029 EU +371 26633466 From: Olivier MJ Crépin-Leblond <ocl@gih.com <mailto:ocl@gih.com> > Sent: Friday, September 5, 2025 12:25 AM To: alexander@schubert.berlin <mailto:alexander@schubert.berlin> ; cpwg@icann.org <mailto:cpwg@icann.org> Subject: Re: [CPWG] Re: The Internet is for end users – RFC 8890 (2020) Dear Alexander, I am intrigued. How would they align with RFC 8890? It has been an aim for At-Large to represent the interests of *all* Internet *users* and not just domain name registrants. Kindest regards, Olivier On 04/09/2025 18:10, alexander--- via CPWG wrote: Hi, If there was a 2nd round (2026) gTLD applicant that has aligned their application precisely with RFC 8890: a gTLD that doesn’t put the registrant but the internet user (“end user”) front and center: would the list be interested in learning about it? Because in the existing denominations of the DNS nobody cares about the “end user” – ICANN cares about registries, registries care about registrars and registrars care about registrants. The “end user” (internet user) is somehow readily available consumption mass that will willingly endure whatever they get exposed to (I am being sarcastic here): For example scam sites, fake sites, parked (monetized) sites, phishing sites, overly complicated URLs, etc. Regards, Alexander ___________________________________________________________________ Alexander Schubert LinkedIn.com/in/alexanderschubert U.S. +1(202)684-6806 Germany +49(030)8643-7863 From: David Mackey via CPWG <mailto:cpwg@icann.org> <cpwg@icann.org> Sent: Tuesday, September 2, 2025 10:35 PM To: Christopher Wilkinson <mailto:cw@christopherwilkinson.eu> <cw@christopherwilkinson.eu> Cc: cpwg@icann.org <mailto:cpwg@icann.org> Subject: [CPWG] Re: The Internet is for end users – RFC 8890 (2020) This document is a great find Christopher! Thanks for bringing to everyone's attention. I've been aware of the document since about September 2020, but it hasn't received much attention in the ICANN community. One of the potential weaknesses of the document is Section 5, IANA Considerations ... 5. IANA Considerations This document has no IANA actions. Cheers David On Tue, Sep 2, 2025 at 2:45 PM lists--- via CPWG <cpwg@icann.org <mailto:cpwg@icann.org> > wrote: Good evening: At last week’s CPWG meeting, I mentioned the existence of this document (10 pp). It can be found at: <https://www.rfc-editor.org/info/rfc8890> https://www.rfc-editor.org/info/rfc8890 In general I find it is an admirable statement of intent on behalf of the Internet Architecture Board (IAB), although it does not go into how its aspirations might be realised. Thus it does not amount to a standard or a policy statement. In the words of the principal author (in an e-mail to myself): <<RFC 8890 was an explanation of the IAB's thinking regarding how the IETF community should engage with other communities that its work affects. There were not concrete follow-on steps, beyond a continuing effort to refine how we engage. This has proven relevant especially in policy-adjacent efforts such as the AI Preferences Working Group.>> For present purposes I suggest that we leave it at that, particularly in light of the ICANN and CPWG work loads for the coming months. However, I do think that there is an overhanging question about how the user community engages with the identification, preparation and governance of the Internet Standards that are the RFCs. Regards Christopher Wilkinson (Posted to CPWG mailing List, 2 September 2025) On 27 Aug 2025, at 18:32, ICANN At-Large Staff via CPWG <cpwg@icann.org <mailto:cpwg@icann.org> > wrote _______________________________________________ CPWG mailing list -- cpwg@icann.org <mailto:cpwg@icann.org> To unsubscribe send an email to cpwg-leave@icann.org <mailto:cpwg-leave@icann.org> _______________________________________________ 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. _______________________________________________ CPWG mailing list -- cpwg@icann.org <mailto:cpwg@icann.org> To unsubscribe send an email to cpwg-leave@icann.org <mailto:cpwg-leave@icann.org> _______________________________________________ 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. _______________________________________________ CPWG mailing list -- cpwg@icann.org <mailto:cpwg@icann.org> To unsubscribe send an email to cpwg-leave@icann.org <mailto:cpwg-leave@icann.org> _______________________________________________ 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.