[RSSAC Caucus] Chinese Critical Infrastructure Event

[Fred Baker]

I don't think you're wrong. I do think that the Chinese government wants its hands on a root server. I agree that having three root server operators affiliated with the US Government gives the appearance that the US Government operates one or more root servers; the fact is that it doesn't, and even if it did, they distribute the same IANA-originated data that everyone else does - they are indistinguishable from the others apart from their address. That is largely a matter of "legacy"; all of the root server operators agreed to do so before ICANN existed, and they were in effect "Friends of Jon". That is largely what the evolution work is about - making there be a process for adding or removing an RSO.

There is an issue, however, in giving any government - not just China, and not just the US - "ownership" of an RSO, which is that presumably every government (is that 200?) wants to operate one, and there is no reason to believe that a new operator is willing to operate by the same principles as the existing ones. We have found that at ISC; anyone that is willing to sign our MOU can deploy an F Root Server Instance (https://www.isc.org/f-root/) if there is a technical reason. We have been contacted many times. When we point out that F Root Servers deliver the IANA Root Zone unchanged, applicants have a way of disappearing. That leads me to believe that applicants frequently want to alter the content in some way. For the good of the Global Internet (see https://tools.ietf.org/html/rfc2826), we would want to know that the proposed operator operated on the same principles as the existing operators.

On Jul 24, 2020, at 1:27 AM, Shane Kerr <shane at time-travellers.org> wrote:
> 
> Fred,
> 
> On 23/07/2020 18.45, Fred Baker wrote:
>> As requested by Paul Hoffman, I'm sharing the request that ICANN's Asia-Pacific team sent to the RSSAC, and the slides that I plan to share with that event. I recorded a presentation this morning, and ICANN's Asia team will add Mandarin subtitles to help our Chinese colleagues to follow the presentation. For the record, this presentation derives from the RSSAC Tutorial shared at ICANN meetings the past several years, and the discussion of the evolution work presented to the GAC about a year ago. There is nothing confidential about the information we are sharing, nor should any of it be a surprise. There is, however, some sensitivity around authority; I can, of course, speak to the RSSAC and to ISC's issues. Much of my point in this talk is that important parts are managed by the IANA, are enacted by the ICANN Board, or are deferred to the GWG; in a perfect world, these agencies would speak for themselves, but that would be a difficult dance. So I will identify the action and the actor, and that RSSAC is not authoritative (as in, "if you have detailed questions, you should really talk with them").
> 
> Thanks for sharing this.
> 
> While clearing up misconceptions and getting everyone on the same page regarding terminology is helpful, ultimately I don't think it will resolve the fundamental issue of no root server being run by a Chinese organization.
> 
> I feel that the Chinese government will only be happy after there is a root server operated completely by a Chinese organization (I can be completely wrong about this and am happy to be told otherwise, but years of seeing the same discussion have convinced me that this is the case). This can happen in one of four basic ways:
> 
> 1. China takes over one or more of the existing root servers.
> 
> 2. One or more new root servers is added and China runs at least one.
> 
> 3. A separate set of root servers is created (similar to the Yeti project, but with an ICANN-signed root zone), which China running at least one.
> 
> 4. China runs its own root servers completely independently of ICANN.
> 
> Option #1 seems the hardest to execute politically.
> 
> Option #2 seems the highest risk, give the amount of ossified code out there which assume 13 letters (I have some, definitely).
> 
> Option #3 is probably the lowest risk, since it would leave the current root server system untouched. (I am biased given my involvement with the Yeti project.)
> 
> Option #4 is clearly the least desirable for the Internet as a whole.
> 
> I take the deployment of the New Model as a prerequisite for any real change, and look forward to that progressing. 🙂
> 
> Cheers,
> 
> --
> Shane
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
> 
> _______________________________________________
> 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.