(cc:s trimmed, since I don't think I have permission to post to all those places and anyway I don't know why it'd be relevant.) On Fri, Jan 08, 2016 at 10:16:03AM +0100, Dr Eberhard W Lisse wrote:
As the chair of the TechWg I am really wondering what we are talking about here.
We are talking about the different _kinds_ of "capacity building", and comparing and contrasting with content censorship, because of a remark someone (I forget who) made up-thread. The point is to understand the consequence of a limited mission and to understand whether the text we have before us conforms with our intuitions about what the mission actually is. (I normally hate arguments from intuitions, but that's what we're doing here so we might as well know it.)
So outreach would also be content censorship, perhaps?
I don't think that is even suggested by anything I wrote, but apparently I was not plain enough. Let me try to be clearer:
Smaller TLDs (cc and g) need all the help they can get, and it most definitively is within mission.
Well, first, is _any_ help within mission? Should ICANN (for instance) help small TLDs develop human resources policy? Should ICANN help small TLDs understand office leasing requirements? How about tax rules in the TLD's jurisdiction? Should ICANN give direct funding to small TLDs that are in financial trouble? Or every (small? define "small"?) TLD? At the very least, I think reasonable people could disagree about any of those cases. Perhaps you could say where you'd draw the line. But second, it seems self-evident to me (and not contrary to the text we have) that building technical capacity to perform the technical function of a TLD registry is indeed good to do, and something that ICANN can contribute to "ensure the stable and secure operation of the Internet's unique identifier systems as described below." I think the board's comments suggest they worry that the (elided) description in the CCWG draft 3 is too restrictive and wouldn't allow the sort of capacity building that (you and I agree) is currently correctly done as (say) part of Tech Day. What do you think the draft 3 mission text entails? Do you think the board is right to be worried? I shoudl say that this works for controls on delegations as well. For instance, the ICANN policy that restricts registration of (say) red-cross.TLD or [a-z][a-z].TLD is in fact an imposition of rules from one zone (the root zone) into another delegated zone (the TLD). The operator of TLD is not ICANN, and it makes its own policies, yet ICANN imposes some of those policies as a condition of delegating TLD. One might argue that one wishes history had gone differently, but this is the regime we have and it appears to be one we can mostly live with. What would be overreach, however, is for ICANN to try to impose such restrictions all the way down the tree. Indeed, we already have lots of things that are not consistent with ICANN policies for the DNS, but that are used regularly in other parts of the DNS. IDNs that do not use IDNA are quite common in lots of places. Domain names with spaces in them are used for DNS-based service discovery. "Underscore labels" (a label starting with _) are used as the technical mechanism to identify SRV records and for various anti-spam measures like DKIM and DMARC. These sorts of policies should not be heritable, and I think we want mission text that makes this clear. I believe the board's suggestion would be a step backwards in this area (as I indicated yesterday). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com