[RSS GWG] Thoughts on costs

Thu Jan 14 17:47:39 UTC 2021

Hi Everyone:

Sorry to be making an intervention so close to the meeting. I wanted to share some thoughts in writing prior to that meeting. 

Where Ted has heard concerns, "that we don't have a cost model that will make sense to folks,” I take that as meaning we have a communications issue rather than that the proposal does not make sense. The proposal might be tweaked, but, more importantly, it should be explained in a way that makes sense to folks.

I think our discussions have led us to a point where we think that time is of the essence in getting the finance part of the program started and it is better to start the flow of some funding while the PRS (and ICANN) iterates and improves the program over time. We also think that imposition of controls would be ineffective and obviate RSOs’ diversity and autonomy.  

I don’t think that approach is off but it requires some careful explanation. The previously-drafted memo that accompanied the PRS document was an attempt at this but re-reading it, I don’t think it meets the need. (I feel comfortable saying this because I wrote a good bit of it.) So I have taken another whack at it. I have attached a word version and also pasted it below. There is nothing in this doc that contradicts Geoff’s earlier email; I agree with what he has stated in it.

I hope you find this helpful. 

Kurt

RSO Funding

Current Situation and Recent Developments:

Owing in large part to the diversity and autonomy of its Root Server Operators, the Root Server System has operated essentially flawlessly since its inception, supporting the growth and benefits derived from the DNS and World Wide Web. As loads and security requirements have increased, so have RSO costs.

The RSSAC convened a working group to recommend RSS governance mechanisms and, as part of its findings, indicated that some of the 12 RSOs require financial assistance in order to maintain competent operations in accordance with their individual operating model. The RSS-GWG was formed to consider and determine how best to implement the recommendations specified in RSSAC-037.

Recommendation:

The Public Root Services, an ICANN subsidiary, will make available a financial grant to each of the RSOs who are parties to a contractual agreement with the PRS. The same grant amount shall be made available to each of the RSOs. The acceptance of the grant monies is at each of the RSO's discretion.

The grant offer and acceptance of the grant shall be public information. An RSO's acceptance of the grant entails the RSO to no additional commitments in terms of obligations to the PRS other than a requirement to enable the PRS to meet its fiduciary reporting requirements by reporting on how the grant monies have been put to use to support the efforts of the RSO in meeting their obligations and service requirements. In the interests of transparency and accountability, these reports shall be public information.

Rationale for this Recommendation:

While this initial approach is light on details and controls, it is thought to be the best way to start this program because:

1.     RSSAC-037 and other sources have made it clear that this financial issue has existed for some time among some of the RSOs and that issue should be addressed in the near term. This might avoid some RSOs from having to develop alternative sources of revenue or alter operations in way that denigrates the RSS.

2.     Not all RSOs will ask for a grant and the grants are only supposed to supplement RSO resources, and not fully fund any RSO’s operation. So, as a first approximation, it is thought that a grant system within ICANN means can address the most significant parts of the funding issue.

3.      ICANN can, in specifying the first years’ grants, select an amount of funding to be made available that falls within its financial capability and is also close to an amount suggested by those with broad RSS experience. It is expected the first year’s grant total will be approximately [[[$X]]].

4.     ICANN will take necessary steps to fulfill its Bylaw-mandated fiduciary obligations, i.e., to ensure the grants awarded are spent on their intended use.

5.     Tying grants to RSO financial transparency, requiring detailed justification, specifying operational metrics (other than meeting individually derived SLAs), or attaining specific efficiencies would denigrate the autonomy and diversity of the RSOs – a basic principle supporting the robustness of the RSS.

6.     In addition to the point just above, controls put in place in an attempt justify individual grants or specify how they are used would certainly be “off” in the first instance and materially decrease the program efficacy and timeliness. The RSS-GWG considered programs based on need or performance metrics such as “cost per resolution,” and found them to be unworkable, at least in the opening years. It is better to start with a lightly controlled program and then institute controls as their meaningfulness and need become apparent.  

7.     ICANN, through its PRS, will iterate the program year-over-year to improve its effectiveness and economy. In the meantime, starting a grant program as recommended in an effort to address the financial issues faced by some RSOs.

> On Jan 7, 2021, at 7:47 PM, Ted Hardie <ted.ietf at gmail.com> wrote:
> 
> Geoff,
> 
> Thanks for this thoughtful reply.   I think this item deserves further discussion at our upcoming meeting, and I hope we can come to consensus then on what, if any, course of action we should take for this.
> 
> In advance of that, my personal opinion focuses on three of your points.  The first is this:
> 
> "it is _not_ the intent of this function to completely and totally fund the root service function operated by each root service operator, or any related variant of this “total cost of operation” approach."
> 
> I think that's an important principle and entirely inline with our input documents.  
> 
> The second point you make that I'd like to highlight is this:
> 
> One way to answer this is to contemplate the range of scenarios were this funding support NOT provided. Some root service operators may find their position untenable. They may elect to sell the root service to another entity, or pass it back to the PRS. The service would over time migrate to those entities who have a desire and a capacity to pay, which would most likely include national entities and the very largest of the existing industry actors. It is difficult to reconcile objectives of diversity, autonomy and independence of the root of the DNS within such an evolving framework that over time passes this function to the very largest of the private sector entities in the Internet together with a number of national agencies from a select small group of countries.
> 
> This analysis seems to me entirely correct.  I think we need to make sure that our documents reflect this, because the natural desire to cut costs will tempt people down this road.  Economies of scale can beget consolidation very easily, but with it comes an increase in fragility for the overall system, along with some other undesirable side effects.
> 
> Lastly:
> 
> the data to be gathered would necessarily involve discussions with the business managers of the various root service operators about the scope of the financial commitments in running the root service, the level of financial support and the financial risks. What we want to understand, to put it bluntly, is how much money is involved in total to keep the financial wolf from the door for each of the RSOs, limited to the context of their RSO operations alone.
> 
> As helpful as this data might be to the exercise of financial scoping, it is also obvious that this is highly sensitive financial data, and the RSS GWG should definitely not be privy to the individual details of any RSO.
> It makes sense to me to use an intermediary to conduct confidential discussions with each of the business managers of the RSOs and produce a report that provides general data about the scale of financial assistance in total that would sustain the independence, autonomy and resilience of the RSOs collectively.
> 
> I agree with this, but I want to add a small additional point.  This looks, at first glance, like the work that the PRS will take on during its distribution cycles--gathering confidential data and using it to work out what additional financial assistance will be needed to sustain or improve the root server system along the guidelines set out by the SAPF.  What's different at the moment is that we don't have the contractual relationships that the PRS will have and so we don't have the detailed description of the root service that the SAPF will set out.  That means any report will necessarily be vaguer than the eventual work product of the PRS.  
> 
> As a result, I support us gathering the data, but using it with a strong caution that it cannot be taken as a constraint.  It's useful for establishing an order of magnitude and addressing the need for that data in analysing our output.  It is not useful as a bound, whether upper or lower.  
> 
> Thanks again for putting your thoughts on this forward,
> 
> Ted 
> 
> 
> 
> On Thu, Jan 7, 2021 at 4:58 PM Geoff Huston <gih at apnic.net <mailto:gih at apnic.net>> wrote:
> Hi Ted,
> 
> 
> > On 8 Jan 2021, at 10:18 am, Ted Hardie <ted.ietf at gmail.com <mailto:ted.ietf at gmail.com>> wrote:
> > 
> > I've gotten some off-list feedback on our work, raising concerns that we don't have a cost model that will make sense to folks who are trying to review the proposal.  In particular, there is a concern about the potential size of the grants.  As it stands now, the reader who doesn't already know what RSO costs look like can't tell even what order of magnitude these grants might be.
> > 
> > Up to now, I think we've said that this really is the business of the PRS to manage, not the RSS-GWG.   They will hold the agreements and build the relationships with the RSOs.  That's not the core of what we're doing here.  Still, there is a real concern that without an order of magnitude to think about that some folks will not be able to assess the proposal.
> > 
> > What do folks think about how to address that?
> 
> I can appreciate the validity of such a concern. Is the total annual sum envisaged within the scope of this support of the root server system in the order of hundreds of millions of dollars? Or on the scale of a few thousand dollars? Or somewhere in between these two extremities? I was hoping myself that we, the RSS GWG, did not have to answer this question in the scope of the RSSGWG effort. I had hoped that we were going to define the framework and the roles of the various parts of the framework and let this framework then operate the machinery and determine the answer to these many many related issues. But its somewhat of a chicken and egg issue, as without even some rough notion of what we are talking about in terms of financial commitments its going to be very challenging for the community and the Board of ICANN in particular to figure out whether to accept the RSS GWG recommendations in the first place. So, your observation that an order of magnitude of scoping here seems like a good idea.
> 
> One possible approach to answering this question is to apply first principles, work out some abstract model of the unit cost of answering queries to the root zone, multiply the unit cost by the query volume and you get some notion of the total cost of the Root Server System to operate.
> 
> But aside from many practical issues with generating a realistic unit cost model of this service, that's not the really the question to be answered. As far as I am aware from reading RSSAC037 it is _not_ the intent of this function function to completely and totally fund the root service function operated by each root service operator, or any related variant of this “total cost of operation” approach. We should acknowledge that the root service is already operating and notionally being funded by various communities in the current operational environment and there is no intent to supplant this with ICANN-derived funds. (The reasons relate to the issue of operational autonomy, diversity, reslience and mutual independence for the root service).
> 
> Another approach is that the intent of the funding function we are contemplating deviates from RSSAC037 in that it would take the current performance metrics as a baseline and assume that these activities will continue to be funded from existing sources, and funding from ICANN would be directed towards supporting root service operators in the circumstances of changes to the service and performance for the root service. i.e. the funding would fund “improvements” to the root service in some general manner. Again, I don't personally subscribe to this potential role for funding. I think changes to the root service should be technically driven to align with technical capability and community expectation and adoption of any changes to the parameters to the root service should be largely driven by needs, and while this is not completely divorced from cost, it should not be driven predominately by cost.
> 
> So what are we talking about with funding? 
> 
> As RSSAC0037 points out there are root service operators who consider themselves to be financially self sufficient and would opt out of any such funding support program, and by corollary there are root service operators who are not so positioned. So it would appear that the need for funding is a business management case, and the intent is to ensure that the financial position of the root service operators, as a direct consequence of operating a root service, is not one that presents serious business risks to the operator. Why is this a consideration? One way to answer this is to contemplate the range of scenarios were this funding support NOT provided. Some root service operators may find their position untenable. They may elect to sell the root service to another entity, or pass it back to the PRS. The service would over time migrate to those entities who have a desire and a capacity to pay, which would most likely include national entities and the very largest of the existing industry actors. It is difficult to reconcile objectives of diversity, autonomy and independence of the root of the DNS within such an evolving framework that over time passes this function to the very largest of the private sector entities in the Internet together with a number of national agencies from a select small group of countries.
> 
> The corollary is that if the task of trying to set an order of magnitude to the costs involved in meeting such an objective of business support for those operators, then the data to be gathered would necessarily involve discussions with the business managers of the various root service operators about the scope of the financial commitments in running the root service, the level of financial support and the financial risks. What we want to understand, to put it bluntly, is how much money is involved in total to keep the financial wolf from the door for each of the RSOs, limited to the context of their RSO operations alone.
> 
> As helpful as this data might be to the exercise of financial scoping, it is also obvious that this is highly sensitive financial data, and the RSS GWG should definitely not be privy to the individual details of any RSO. It makes sense to me to use an intermediary to conduct confidential discussions with each of the business managers of the RSOs and produce a report that provides general data about the scale of financial assistance in total that would sustain the independence, autonomy and resilience of the RSOs collectively. Such a report would provide some necessarsy scale data that would help to understand the likely scope of the financial undertakings which ultimately would be of material assistance to the Board of ICANN when they come to consider the recommendations of this Working Group.
> 
> I suspect it would be prudent to engage the chair of the RSSAC if we chose to go down this path, to ensure that any entity we might engage to undertake this study is both credible and trustable in terms of the financial data that they may be exposed to when undertaking data collection.
> 
> I also suspect that this will be helpful to this working group as well, in order to understand the likely viability of the measures that we will propose in our report.
> 
> cheers,
> 
>   Geoff
> 
> 
> 
> _______________________________________________
> RSSGWG mailing list
> RSSGWG at icann.org
> https://mm.icann.org/mailman/listinfo/rssgwg
> 
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/rssgwg/attachments/20210114/b71da637/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RSO Funding Explanation.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 15754 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/rssgwg/attachments/20210114/b71da637/RSOFundingExplanation.docx>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/rssgwg/attachments/20210114/b71da637/attachment-0001.html>