[CWG-RFP3] Coordination of Subgroup 3

[Robert Guerra]

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> wrote:
> 
> Hi,
> 
> On Nov 3, 2014, at 7:41 PM, Milton L Mueller <mueller at syr.edu <mailto:mueller at syr.edu>> 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
> https://mm.icann.org/mailman/listinfo/cwg-rfp3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141104/6e0a6cb1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2841 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141104/6e0a6cb1/smime-0001.p7s>