[RSS GWG] Thoughts on costs

[Geoff Huston]

Hi Ted,


> On 8 Jan 2021, at 10:18 am, Ted Hardie <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