[CWG-RFP3] Coordination of Subgroup 3

Tue Nov 4 16:50:08 UTC 2014

On David Conrad’s point about the need for authorization introducing latency issues, etc., - valid point.  On the other hand, if we were to recommend doing away with that step, how do we ensure that an incumbent operator has appropriate notice and an opportunity to contest revocation/redelegation/transfers?

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 at neustar.biz<mailto:becky.burr at neustar.biz> / www.neustar.biz

From: Greg Shatan <gregshatanipc at gmail.com<mailto:gregshatanipc at gmail.com>>
Date: Tuesday, November 4, 2014 at 9:11 AM
To: Robert Guerra <rguerra at privaterra.org<mailto:rguerra at privaterra.org>>
Cc: RFP3 <cwg-rfp3 at icann.org<mailto:cwg-rfp3 at icann.org>>
Subject: Re: [CWG-RFP3] Coordination of Subgroup 3

Milton,

I was not falling prey to anything; I am taking into account the division of work email circulated by our Co-Chair with regard to our subgroup, specifically Item "B" (see below).  In our subgroup, we need to account for transitioning this aspect of NTIA's role, even if a possible post-transition option is abolishing that element of the NTIA's role.  Since this is part of our assigned task, I think it is important to keep it in mind as an Objective.

Greg

---------- Forwarded message ----------
From: Lise Fuhr <lise.fuhr at difo.dk<mailto:lise.fuhr at difo.dk>>
Date: Thu, Oct 30, 2014 at 3:12 PM
Subject: [CWG-Stewardship] Work break down RFPIII
To: cwg-stewardship at icann.org<mailto:cwg-stewardship at icann.org>

Dear All,

The objective is to finalize the work breakdown structure at our next meeting.

An issue arose at our meeting today:
·         Breaking up CWG-RFP3 into 3A and 3B as presented:

A. Contract Manager for the IANA Functions contractor
B. Root Zone Management.

Although there were some objections on the list prior to the call there were none voiced during the call and I concluded that we should keep this separation at least until our next meeting. The main reason for this is that the SSAC68 report identifies two very distinct functions performed by the NTIA in IANA Functions oversight and accountability and this group is in charge of identifying how to best transition both.
If you have any comments please post these to the list prior to our next meeting on November 4.
Thank You
Best regards.
Lise

_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship at icann.org<mailto:CWG-Stewardship at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-stewardship<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Dstewardship&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=1neaAuBbYr8wN6tDq4uJTOIR6c2psQy5xx96cFoOHIo&s=d_xl3ZTAbhFtLGMi4mNxty2bSpfFzquRmgRIaVIN-xI&e=>

On Tue, Nov 4, 2014 at 8:33 AM, Robert Guerra <rguerra at privaterra.org<mailto:rguerra at privaterra.org>> wrote:
David,

You and Milton raise some important points, that being:

- RZF need to be reviewed for technical accuracy
- An authorizer process step exists now . In a post NTIA solution, something similar is needed.  There is a need to evaluate if a single or multiple authorizers are needed as well as cost that might entail.

robert

On Nov 4, 2014, at 3:45 AM, David Conrad <david.conrad at icann.org<mailto:david.conrad at icann.org>> wrote:

Hi,

On Nov 3, 2014, at 7:41 PM, Milton L Mueller <mueller at syr.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__mailto-3Amueller-40syr.edu&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=1neaAuBbYr8wN6tDq4uJTOIR6c2psQy5xx96cFoOHIo&s=zskmfP9dPD5PK8veRgSxv5LPL-E20-wDVGxtgkAd1SI&e=>> wrote:
You may be falling prey to a common misconception – the idea that NTIA authority over RZF actually ensured the technical accuracy of RZ file changes. It didn’t. The Commerce Department staff member who reviewed the changes was not a DNS expert.

True.

NTIA was there to make sure that the RZF changes were _authorized_ and it did that primarily to ensure antitrust immunity to Verisign.

Hadn't heard that one before (not saying it isn't true, just that I hadn't heard it).

My understanding is that by the terms of (I believe) amendment 11 of the (now) NTIA/Verisign cooperative agreement, Verisign is not permitted to modify the root zone without explicit permission by NTIA. NTIA authorizes those changes by verifying ICANN has followed documented policy/conformance to the IANA Functions contract in processing root zone change requests. It is probably worth noting NTIA has never not authorized a change.

Ergo, I don’t think you need a “final check” of any and every RZ change, so much as you need serious recourse if someone makes an unauthorized change. I think we can trust the registries to tell us if the changes are inaccurate.

Indeed.  Speaking as someone charged with implementation, it turns out that the authorization requirement adds a non-trivial amount of complexity, fragility, and latency to the root zone management system.  Given, by definition, all changes to the root zone are public and any missteps would generate a vast array of negative repercussions, the community may wish to consider whether the complexity, fragility, and latency costs outweigh the benefits.

Further, if the community does decide they wish to keep the authorization function, a number of questions quickly arise: exactly what does the community want to replace the authorization performed by NTIA with?  Does the community want a single authorizer or multiple authorizers?  If multiple, how many?  What exactly would those authorizers authorize? How would they be chosen? Would they expect to be paid for the authorization service? Etc.

Regards,
-drc
(ICANN CTO, but speaking only for myself. Really.)
_______________________________________________
Cwg-rfp3 mailing list
Cwg-rfp3 at icann.org<mailto:Cwg-rfp3 at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-rfp3<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Drfp3&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=1neaAuBbYr8wN6tDq4uJTOIR6c2psQy5xx96cFoOHIo&s=oskxyKnnH_JGwHr6GYcA-vUV2N0T7OETibZ8NmksR3k&e=>

_______________________________________________
Cwg-rfp3 mailing list
Cwg-rfp3 at icann.org<mailto:Cwg-rfp3 at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-rfp3<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Drfp3&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=1neaAuBbYr8wN6tDq4uJTOIR6c2psQy5xx96cFoOHIo&s=oskxyKnnH_JGwHr6GYcA-vUV2N0T7OETibZ8NmksR3k&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141104/7b56eb75/attachment-0001.html>