[CWG-Stewardship] on int (was Re: ICANN Board as "regulator" (was: A liaison from the Board to CWG))

[Andrew Sullivan]

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 at anvilwalrusden.com