Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en.

the initial thoughts shared on December 20th are in the attachment there: https://mm.icann.org/pipermail/council/2022-January/025322.html

have I missed the paper with the justification of the amount? (like calculations of the hardware, software, services).?

@Maxim - the ODA is expected to be published in Feb.

is it before the planned discussion with the Board ?

@Marika- will that include the details that Maxim is referencing? Because the numbers are multiples bigger than what ICANN estimated, we need to know the specific details why they’re so high

My understanding is that the ODA will include the details that underpin the high level conclusions that were shared during the 20 Dec call.

[resending for everyone] @Marika- will that include the details that Maxim is referencing? Because the numbers are multiples bigger than what ICANN estimated, we need to know the specific details why they’re so high

@Maxim - in the current schedule, the consultation with the Board would take place before the ODA is published.

In the spirit of transparency, will the ODA also include which entities provided the estimates?

Are we putting the cart before the horse in discussing the "options" before seeing the cost justifications?

I suggest we either have the papers before the consultation with the Board. GNSO can not discuss just PPTX file having no proper justifications (the same for PDF)

@Owen - I don’t know the answer to that question.

+1 Jeff- this conversation seems premature

Right. After all, how do we brainstorm a partial solution without seeing what the costs actually are? How do we do a cost benefit analysis without seeing the actual costs of each "part"

or not knowing exactly what the Board position here- feels like we're extrapolating

@Marika- I think it would be very helpful to know who is providing the estimates. Because there could be potential conflicts, concerns about ability to provide the services, etc.

+1 Jeff

The “paper

The paper is here https://mm.icann.org/pipermail/council/attachments/20220104/8ace70e8/EPDPPhase2-PossibleNextStepsDiscussionPaper-4Jan2022-0001.docx

+1 Kurt

Seems the board needs to show some cards here, even if they don't give a "final answer" at this juncture.

the detailed explanation of the costs should be provided (such as hardware, software and services costs / with explanation of why which particular element is used)

is what required

Note that there was already a public comment period on the phase 2 recommendations prior to Board consideration (see https://www.icann.org/en/public-comment/proceeding/epdp-phase-2-policy-recommendations-for-board-consideration-08-02-2021). It is not clear whether another public comment period is planned at this stage.

Does seem to be a possibility of duplication and/or redundant work if we act without a factual basis.

One take on the 20-Dec call is that Org would prefer that SSAD become just a ticketing system, without accreditation of requestors. I asked Goran what the costs would be for a ticket system only, but he had no answer at the time. Is that cost available now?

+1 Greg. We need to know what the Board is thinking in order to determine whether an alternate course of action is needed. Without that knowledge how do we know that an alternative we develop would be something that the Board would accept? IF we spend time developing an alternate solution and it doesn't meet the Board's expectations, then we will have wasted a lot more time

inflation? :)

this kind of money is enough for a large hoster + registrar to operate for a year

+1 Owen. ICANN ran an RFP, but never disclosed what was received. Did ICANN's estimates actually come from the Bids or not? I thought I heard ICANN say during the presentation that no bidder presented a comprehensive solution, so did it add two or more bids together?

My understanding is that ICANN did combine some bids but I can't point to where that was said.

Yes, we should require transparency in the bids.

There is a constant call for data but we don't have data in this instance.

+1 Lori

+1 Thomas

@Phillipe that is probably a better question for ICANN rather than Thomas, to be fair.

removing features from the complex technical solutions is not that easy (might not be possible to add later without the total overhaul, quite costly)

I would expect ICANN to figure in "reserves" for litigation and/or regulatory activity. We just need to know how much they believe that will cost per year?

For example, did ICANN legal add 30% to the costs to reserve for legal/regulatory expenses?

at least 20% -80% principle of how costs are related to features of the system

so far it looks like a plan to consume the rest of ICANN reserves in 3 years

Why fly blind? We could survey potential users to get sense provided we understand what the fees may be. Cost is a big factor.

Market studies are done all the time. Janis' point is well taken.

in such cases - there are few tables of explanation for groups with different numbers

so the should be few models

hardware + software + services are calculated based on something (base costs, how it is going to be scaled)

@Steve - Or was staff nudging us to drop the whole thing?

+1 Steve

Alex Deacon had suggested that ICANN’s present SalesForce implementation could be used for ticketing of requests and recording responses.

In the most general terms possible, I think you'll find the IPC reluctant to "remove features" for the same reasoning Janis mentioned in his email. Let's understand what Org is thinking vis-à-vis cost.

@Mark, a big question on that would be how easy to build the complex parts of the solution on an off-the-shelf solution or will we need to build again from scratch when we need the complex parts?

we might have GDPR related issue later.. not Sure EU DPAs would like it (huge system) handling lots of personal info, including LEA requests

@Kurt - If that is how ICANN staff feels, then they should come out and say it directly on the record

They should not "beat around the bush." That should be their formal recommendation

then it is Staff opinion

should be formal and from Staff (not via giving hints to GNSO doing so)

Well said, Kurt. Particularly the inextricable nature of the recommendations.

+1 Kurt

spending many years to have agreed idea and then to scrap it just because the presentation with couple of lines of text with numbers... does not seem right

Org seems to want Council to amend/scale-back its recommendations, before the Board reacts to the recommendations. Fair question, but we are not likely to agree upon a new recommendation, even if Org gave us lots more information about costs of components.

@Steve - that is very typical of ICANN over the years.

The GNSO has asked the Board for its recommendations and we are entitled to get those recommendations, right?

it seems to be the job of the ODP

As a reminder, the ODP was requested by the Board to help inform its deliberations, including whether the recommendations are in the best interests of the ICANN community or ICANN.

we can not do the homework for the ODP

Also as a reminder, the ODP “will assess the potential risks, anticipated costs, resource requirements, timelines, dependencies, interaction with the Global Public Interest Framework that is currently being piloted, and other matters related to implementation of the SSAD-related recommendations (1-18)”

I think that is key Marika… the ODP is a support, the underlying GNSO process has not changed…we continue to await the board’s deliberations and in truth should we not be awaiting that.

@Marika - and the Council asked for a Cost Benefit analysis, right?

To Jeff’s question, the resolution included the following: “ Noting some of the questions surrounding the financial sustainability of SSAD and some of the concerns expressed within the different minority statements, the GNSO Council requests a consultation with the ICANN Board as part of the delivery of the GNSO Council Recommendations Reportto the ICANN Board to discuss these issues, including whether a further cost-benefit analysis should be conducted before the ICANN Board considers all SSAD-related recommendations for adoption.”

@Marika - the Council asked for a cost-benefit analysis and from that, the ODP was born. Your (accurate) description of the ODP reinforces the idea that the Board should react to the ODP prior to Council action

the question should be returned to ODP with the request to properly do the detailed assessment

Agreeing with all the comments above, I think it's wise to allow the board for a modicum of "wiggle room" but they need to tell Council what they're thinking and deliver the ODA before Council can act.

At this point procedurally, there is nothing for the Council to do. Yes, in theory the Council can act, but why would it do anything without complete information?

Hi, Alan. Will ALAC be doing a comment to board on EPDP Phase 2A? It’s due 13-Jan.

a lot of agreement in this meeting from all SGs- New Year New Council!

@Jeff, that's perhaps a better way to put my exact thoughts. Thanks, especially at 2am :-)

We know that the ODA is not published yet, but isn't there some middle ground - namely - just getting more information about the cost estimates, the details of the bids that were received, etc. I am not sure why everything needs to be given to us all at once

@ Jeff - I would just wait for the ODA and get the information at one time

+1 Kurt

i would wait too- getting information piecemeal will just muddy the waters

Whoever (whomever?) is writing the ODA is also the same person that would write an interim data release. Every release requires legal review, etc. I think it would slow the process.

It is fine to get everything at once, but then we should not be expected to take any actions prior to that complete information dump, right?

correct- no action from us until we get it

I honestly don't see how we can, Jeff. Otherwise we're hypothesising on an unknown, which doesn't seem like a great use of time/resources to me.

But also taking what Kurt stated earlier, if we do entertain a partial solution, would we not need to refer that to the ePDP Phase 2A working group as opposed to the Council deciding what to do?

having a conversation solely just to have a check box filled might not be reasonable

If that happens I think the EPDP experts are the best placed - they're the ones who know all the background & reasoning for getting to where we are. Efficiency..

I think the Council needs to analyze the ODA, but any reaction to it (especially if the Council wants to consider a partial solution) should be for the jurisdiction of the Working Group.

Thanks everyone!

In order for it to be a Consensus Policy, it would have to go through the formal PDP / ePDP (I believe)

Approved GNSO Council policies may be modified or amended by the GNSO Council at any time prior to the final approval by the ICANN Board as follows:1. The PDP Team is reconvened or, if disbanded, reformed, and should be consulted with regards to the proposed amendments or modifications;2. The proposed amendments or modifications are posted for public comment for not less than thirty(30) days;3. The GNSO Council approves of such amendments or modifications with a Supermajority Vote of both Houses in favour.

This is from section 16 Amendments or Modifications of Approved Policies

I think modifying the recommmendations after the board rejects them is what is not so clear

@Marika - right - that is complicated and can be lengthy and without payback

@Marika is that from the Bylaws or GNSO procesures?

procedures?

GNSO PDP Manual

@Marika - not sure that qualified for Consensus Policies....

I think that procedure has been used once before in the context of IGO recs (I think Thomas was leading that effort at that time)?

@Jeff - why not? It has been used before. Note those recs would go back to the ICANN Board for consideration.

Good day/night thanks all

You are right, Marika.

I still don't see how we can suggest modifications before we have the facts as to why we need modifications.

Thanks all! Good discussion. Bye.

@Thomas - but is that good enough for Capital "C" Consensus Policies for the Agreements

Thank you all

Marie: d’accord

Thank you all

Thanks

thanks all