Thank you, Lawrence.  I don't think the Council can vote to approve the process unless the answers to these questions are clear.  This is because of the nature of a 72 hour non-objection provision.  That process doesn't specify the manner of lodging objection by Council or the specific nature of the assignment to the SPIRT, e.g. come up with a solution and implement it with Org and/or come up with an analysis and propose alternatives to Council?  It's quite difficult to apply a procedure that actually involves no discussion at the Council level of the specific issue involved and that discussion is extremely unlikely to happen in a "negative response" 72 hour time frame.  

Regarding the RSP Qualification issue, it appears to be fairly urgent based on what Jeff has said but I have also wondered about the fact that it is not ICANN Org raising the issue and Council does not have the benefit of the ICANN Org viewpoint on this issue.  The proposed new process the SPIRT is asking for essentially puts the SPIRT in the position of raising an issue itself.  In this case, it is apparently the RySG via Jeff Neuman raising the issue.  At the time of Charter drafting,I think we thought that if something like this came up, the RySG would raise it directly itself at Council and then Council could choose to ask the SPIRT to act on it.  The proposed SPIRT alert process may be more efficient in the long run but for us on Council, (1) we have not heard directly from the RySG on this and (2) we have not heard from ICANN Org re the implications for RSP qualification, which is strictly an Org function.

New issues and procedures are always a bit complicated so thank you for your patience and willingness to keep working to refine this proposal!

Anne

Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com


On Sat, May 9, 2026 at 2:18 PM Lawrence O. Olawale-Roberts <lawrence@microboss.org> wrote:
Dear Anne,

Thank you for the clarifying questions, I will attempt to answer them but expect Council leadership and staff to weigh in. 

On the level of objection required to withhold consent, a determination would need to be made by Council leadership in consultation with members. However, one councilor or stakeholder group may be too lean a threshold to stop an issue being referred to SPIRT from the Council. 

I believe an objection by Council leadership on referring an issue to SPIRT, should also get full council concurrence. 

On your second question it is mandatory as Per the SPIRT Charter, “For any Type 3 issue, which is considered a policy change to be referred to the GNSO Council by the SPIRT. This is hard oded in the charter for implementation, In the case of a Type 2 issues where ICANN Org disagrees with the SPIRT’s recommendation, the SPIRT shall come back to confer with the GNSO Council.

Speaking directly to your 2nd question, I believe the intent is for the SPIRT to resolve the issue if it is categorized as Type 2, whilst ICANN Org resolves issues categorized as Type 1 and inform the SPIRT team. All Type 3 issues however fall under the remit of the Council to be resolved. 

LoR

 -----

Image

Image

Lawrence Olawale-Roberts
Global President & Managing Director

Mobile: +234 8070892705, (0)8056 3333 97
Lawrence@microboss.org

Image

Image

…collaboration to enhance communication. 

Image

https://www.microboss.org | 

Image

Image

Image

Image

Image

 

 

This e-mail and any attachments are confidential and may be protected by legal, professional or other privilege. If you are not the intended recipient, you should not store it, copy it, re-transmit it,

use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. The views expressed are those of the sender and his company MicroBoss.

Kindly note that whilst we scan all e-mails for viruses, we cannot guarantee that any e-mail is virus-free.  |  Do consider the environment before printing this email.
From: Anne ICANN <anneicanngnso@gmail.com>
Sent: Saturday, May 9, 2026 3:02 PM
To: Lawrence O. Olawale-Roberts <lawrence@microboss.org>
Cc: GNSO council <council@icann.org>
Subject: Re: [council] GNSO Council Motion for SPIRT Alerts
 
Thanks Lawrence.  Could you please clarify the following:

1.  In the proposed 72 hour non-objection process that has the effect of sending an issue to the SPIRT for deliberation, what level of objection or raising the issue to the Council level for discussion is required?  Is it objection by one Councilor.  Objection by Leadership?  Is this specified in the Motion?

2.  Where in the Motion or in the form advising Council of the issue does it specify that the SPIRT will bring a recommendation back to Council for its consideration?  Or do we intend for the SPIRIT to resolve the issue itself once the Council has given the 72 hour "consent by non-objection" to the SPIRT?  

I apologize if I have missed the above points in the Motion or in the form submitted which summarizes the important RSP qualification issue.  Thanks again for all your hard work.  

Anne

Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com


On Sat, May 9, 2026 at 4:26 AM Lawrence O. Olawale-Roberts via council <council@icann.org> wrote:
Dear Councilors,

 

I submit for your approval and secondment a motion for the GNSO Council Consideration of SPIRT Alert Request process at our meeting for the 21st May, 2026.


Motion: 


On Council's approval of the Consideration Request for SPIRT Alerts in the motion above, the SPIRT would like to be permitted by the GNSO Council to discuss a matter on RSP Applications brought before the SPIRT by the Registry Stakeholder Group through a member.

 

Link to SPIRT Issue Submission Form:


The GNSO Council approval sort aligns with the SPIRT charter and adopted process.


Brief of Issue - RSP APPLICATIONS 


The Registry Service Provider (RSP) Handbook sets out the evaluation process for providers seeking qualification to offer services to new generic top-level domain (gTLD) applicants in the New gTLD Program and currently  mandates prospective RSP's to attest that all Extensible Provisioning Protocol (EPP) extensions they intend to use are registered with IANA in accordance with RFC 7451 and indicate whether they do, or will, refrain from using any EPP extensions that are not registered with IANA pursuant to RFC 7451.


As ICANN agreed to remove the requirement that Registry Operators limit their use to EPP extensions reflected in the IANA registry, the RSP Handbook has not updated to reflect this change and as a result, pre-evaluated RSPs are still required to commit to using only IANA-registered EPP extensions in order to pass evaluation. Thus RSPs must make commitments that their Registry Operators are no longer required to make under the Base Registry Agreement. Accordingly, the RySG requests that SPIRT and ICANN org consider revising the RSP Handbook to align it with the Base Registry Agreement. 

 -----

Image

Image

Lawrence Olawale-Roberts
Global President & Managing Director

Mobile: +234 8070892705, (0)8056 3333 97
Lawrence@microboss.org

Image

Image

…collaboration to enhance communication. 

Image

https://www.microboss.org | 

Image

Image

Image

Image

Image

 

 

This e-mail and any attachments are confidential and may be protected by legal, professional or other privilege. If you are not the intended recipient, you should not store it, copy it, re-transmit it,

use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. The views expressed are those of the sender and his company MicroBoss.

Kindly note that whilst we scan all e-mails for viruses, we cannot guarantee that any e-mail is virus-free.  |  Do consider the environment before printing this email.
_______________________________________________
council mailing list -- council@icann.org
To unsubscribe send an email to council-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.