I think it is very important to understand from the IETF and NTIA whether any of the test bed functionality remains in .int. Many were moved to the repurposed .arpa (Karen Rose will have to remind me what it stands for) - but I do not know if all of them have been moved. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz On 2/26/15, 10:29 AM, "Milton L Mueller" <mueller@syr.edu> wrote:
Hi, Andrew 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.
I personally believe that ICANN and/or IANA should get rid of this function. It's not central to their missions and I'd like to maintain a clean line between the root zone registry and TLD registry operators.
By the same token I think the stakes are pretty low on this one and if we just said "it stays with ICANN" most planets would remain in their orbits.
A better middle ground might be to specify, as part of the transition, that ICANN will come up with a plan to divest itself of it within 2 years.
-----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship- bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Thursday, February 26, 2015 9:30 AM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] ICANN Board as "regulator" (was: A liaison from the Board to CWG)
Hi,
On Thu, Feb 26, 2015 at 01:18:07PM +0000, Lindeberg, Elise wrote:
We can discuss the conditions around ICANNs administration of .int
today, but responding to your comment : "I don't believe ICANN/IANA is in any competition with anyone to operate the int registry, because the USG specifies the operator and, as far as I know, hasn't put the operation out to bid"
- I think it is expected from the community, at least from the GAC side, that the CWG discuss and have thoughts on what we see as the best solution for the .int post transition - that is when US GOV no longer have the possibility to specify/change through a bid.
I am prepared to believe that lots of people think the specification of the operator of int is covered in this transition, but I don't actually see that in any of the materials. The current NTIA-ICANN agreement is for the _operation_ of the int zone, but not for the _policy_ of it. That seems to me to be different from the root zone, where the policies governing the root zone (all the co-ordination and so on) are also vested in ICANN's policy side.
In other words, ICANN is performing the technical functions for int, but not the registry operator function broadly construed. This is rather like (for example) org: PIR is the registry operator, and it contracts to Afilias to perform the technical functions. PIR could pull that technical operations contract and give it to someone else. Contrast this with (say) info, where ICANN has delegated operation of that namespace (including policy) to Afilias.
I am entirely prepared to be wrong about this (I'm often wrong), but if I am then I'd like a pointer to the text that shows it.
I am not, please note, suggesting that int isn't a problem. I'm just noting that it might be a problem that we don't have to solve in order to undertake the transition. Any burden we can shed at this late date is an advantage to us, I suggest.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_cwg-2Dstewardship&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifz m6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=AuQ1rx8D5cYW10nh9k0SGxhr9WPy9cipwSDb MoYmvFw&s=c_5VV9gYVbPZ8bltMitDTfwoNDAhEiUBeghBQyFv3cg&e=
CWG-Stewardship mailing list CWG-Stewardship@icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_ listinfo_cwg-2Dstewardship&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6 X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=AuQ1rx8D5cYW10nh9k0SGxhr9WPy9cipwSDbMoY mvFw&s=c_5VV9gYVbPZ8bltMitDTfwoNDAhEiUBeghBQyFv3cg&e=