<html>
<body>
So IANA is effectively the back-end registry (since IANA just implements,
does not set policy) for a very small TLD.<br><br>
My recollection from the GNSO PDP discussions on protecting the writes of
intergovernmental organizations, where the Board used the .int
eligibility rules to temporarily protect some IGOs, was that there was
some unhappiness with those rules. <b>A good place to stay away
from!<br><br>
</b>Alan<br><br>
At 26/02/2015 07:04 PM, Andrew Sullivan wrote:<br>
<blockquote type=cite class=cite cite="">Hi,<br><br>
Replying to several messages at once to reduce list traffic.<br><br>
On Thu, Feb 26, 2015 at 03:29:21PM +0000, Milton L Mueller wrote:<br>
&gt; Hi, Andrew<br>
&gt; Fiona Alexander of NTIA has made a frequent point of telling us that
.int is currently in the IANA contract (C.2.9.4) and a complete proposal
will have to decide what to do with it. <br>
&gt; <br><br>
As I was arguing upthread, it _is_ in the contract, but in a
strictly<br>
limited way: the technical operations only.&nbsp; That's what's in
C.2.9.4.<br>
In that section, all the policy formation is reserved to the
USG:<br><br>
&nbsp;&nbsp;&nbsp; The Contractor shall operate the INT TLD within the
current<br>
&nbsp;&nbsp;&nbsp; registration policies for the TLD. Upon designation of
a successor<br>
&nbsp;&nbsp;&nbsp; registry by the Government, if any, the Contractor
shall cooperate<br>
&nbsp;&nbsp;&nbsp; with NTIA to facilitate the smooth transition of
operation of the<br>
&nbsp;&nbsp;&nbsp; INT TLD. Such cooperation shall, at a minimum, include
timely<br>
&nbsp;&nbsp;&nbsp; transfer to the successor registry of the then-current
top-level<br>
&nbsp;&nbsp;&nbsp; domain registration data. The Contractor shall also
implement<br>
&nbsp;&nbsp;&nbsp; modifications in performance of the IANA functions as
needed upon<br>
&nbsp;&nbsp;&nbsp; mutual agreement of the parties.<br><br>
It seems to me that this WG therefore can nicely side-step this
issue<br>
by noting that IANA is currently the technical operator but not the<br>
policy authority.&nbsp; So as part of the transition, we can state that
the<br>
pre-existing rules remain in effect (no policy changes, and if the
USG<br>
designates a new registry then ICANN will cheerfully help).&nbsp;
Moreover,<br>
if NTIA believes that the policy authority is also part of this<br>
transfer, then ICANN will follow the same policy while consulting
with<br>
existing int registrants to ask them for a new policy authority.&nbsp;
No<br>
alterations in int registration policy will be undertaken without
the<br>
(what?&nbsp; Rough consensus?&nbsp; Majority preference?&nbsp; I don't
care) of all<br>
int registrants.<br><br>
That dodges the problem of getting a complete solution to all the<br>
policy issues for int while respecting the NTIA statements and<br>
direction.&nbsp; Moreover, it kicks this problem down the road a bit
and<br>
thereby allows us not to have to hammer out all the details right
now.<br>
It is consistent with what everyone wants -- ongoing security and<br>
stability -- while yet leaving NTIA an option as to which way we are<br>
to understand the existing agreement.&nbsp; Moreover, it's consistent
with<br>
the multistakeholder approach, and we can even enumerate all the<br>
existing affected stakeholders since the zone is so small.&nbsp; (Even
if<br>
we extended the affected class to all the potential registrants, the<br>
list is still entirely manageable in size.&nbsp; So there is one<br>
potentially fraught question, and that is whether to use the bigger
or<br>
smaller class here.)<br>
<br>
On Thu, Feb 26, 2015 at 06:27:51PM +0100, Olivier MJ Crepin-Leblond
wrote:<br>
&gt; Hello all,<br>
&gt; <br>
&gt; actually the Management of .INT is a high stakes political
game.<br>
&gt; <br>
&gt; The ITU has affirmed for many years that they wish to be managing
.INT<br><br>
I suggest that the above approach neatly avoids us having to debate<br>
whether management of int can pass to ITU without violating any of
the<br>
NTIA's directives on this issue.&nbsp; If the ITU can convince all
the<br>
relevant stakeholders (however defined -- see above), then they can<br>
run it.&nbsp; If not, then not.&nbsp; And maybe they don't want it any
more.<br><br>
<br>
On Thu, Feb 26, 2015 at 03:11:43PM +0100, Jaap Akkerhuis wrote:<br><br>
&gt; Strickling has repeatedly said that some solution should be
presented<br>
&gt; for the .INT situation. What the exact problem needs to be solved
is,<br>
&gt; I don't know but I suspect it has to do with the fact that IANA is
now<br>
&gt; the registry and the underlining policy doesn't has a real home
nor<br>
&gt; versight.<br><br>
I agree, and I'm suggesting that the ambiguity is something we
should<br>
take advantage of in order to reduce the &quot;must do&quot; items before
the<br>
transition.<br><br>
Please note that I'm not suggesting this isn't important or
something<br>
that ought to be left forever or anything like that.&nbsp; I'm just
saying<br>
that, given all the things that we have to achieve in roughly four<br>
months, we had better figure out how to eliminate issues from our
list<br>
whenever it is practical and safe to do so.&nbsp; This is, I submit, such
a<br>
case; so let's take advantage of that.<br><br>
Best regards,<br><br>
A<br><br>
-- <br>
Andrew Sullivan<br>
ajs@anvilwalrusden.com<br><br>
<br>
_______________________________________________<br>
CWG-Stewardship mailing list<br>
CWG-Stewardship@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" eudora="autourl">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a></blockquote>
</body>
</html>