On Thu, Feb 26, 2015 at 08:43:30PM -0500, Greg Shatan wrote:
I'm completely in favor of eliminating issues from our list. However, our list is not the only one that matters. In the end, it's the NTIA's list that matters
Fully agree. But I think the NTIA is at least as motivated as we are to achieve a successful transition, and if we have a plausible way forward it seems to me they might accept that.
I don't see anything in C.2.9.4 that reserves policy to the USG. It does say that IANA shall operate the INT TLD "within the current registration policies for the TLD".-- but it doesn't say where those policies are set. It certainly doesn't reserve to itself the right to change those policies. In any event, when the IANA Functions Contract goes away, so does C.2.9.4, and any USG limitation on .INT policies goes away with it. This would be a
In my reading, C.2.9.4 says two things. First, it imposes an existing policy on the registry -- the then-existing policy. Second, it says that the USG may designate a successor registry. That is all it says. Contrast this with the language in (say) C.2.9.2.c or C.2.9.2.d, which both talk about various policy frameworks and so on. This difference says to me that C.2.9.2 is delegating policy authority to ICANN within its (ICANN's) processes, and the omission of that grant from C.2.9.4 leads me to believe that the policy delegation is not made for int. Now, I can of course construct the argument the other way, but I'm looking here for plausible arguments for why and how to reduce the number of things we have to do. (I know it probably seems near-mercenary to be so blunt about it, but really I think we must trim wherever we reasonably can, and here is a place we can do it while yet committing to a nice modest way for the future.)
The IANA website does deal with .INT policy in a section called ".INT Policy and Procedures." http://www.iana.org/domains/int/policy This in turn cites to RFC 1591, which merely states that "[T]his domain is for organizations established by international treaties, or international databases." I don't see any indication here, either, that the USG sets policy on .INT
My reading of the agreement is that the USG was specifying what the policies already were. There's no permission to change them. So the USG sets the policy, at least at that point. The alternative interpretation is that someone could update RFC 1591, and change the policy that way. I believe it is possible to update RFC 1591 via the Independent Submissions track (it's a little hard for me to be sure in this case), but I think this would be extremely bad. If we really want to say that the policy mechanics for int lie only in RFC 1591 (which can maybe be updated by anyone), however, that is also a good way to kick this can down the road -- though perhaps a more contentious one :-) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com