<div dir="ltr">It's hard to know what you don't know. Which is why I think it makes sense to ask. <div><br></div><div>The NTIA has been doing this job for a long time. It is possible that over the past decade the system has got so good and that the NTIA's focus has been on making sure it has the most minimal job possible that it would barely be noticed if the role was removed.</div><div><br></div><div>It is equally possible that it has built a series of internal guidelines - some may not even be written down - where particular requests are sent through different checks that the other parties are not even aware of (and why should they be?)</div><div><br></div><div>I've not seen any logs of transactions between IANA and the NTIA beyond cumulative statistics. We are told that the NTIA has never turned down an IANA change but is it the case that it has never got back to IANA and asked a clarifying question? Has IANA ever changed a request / got back to the requestor following NTIA feedback? We don't have that information. </div><div><br></div><div>What is the time differential between IANA sending a request and the NTIA approving it? It is minutes? Days? Does it vary? Are there particular requests that take longer? We don't know. What does it do with the requests? We don't know. </div><div><br></div><div>According to SAC067, the Administrator role is "solely with respect to whether or not ICANN has followed established policies and procedures". How does it do that? Does it have a book of rules in house? Does it ever call the requestors directly? What, if anything, is a red flag to the NTIA? </div><div><br></div><div>Does it feel that the role it plays should be retained even when it is no longer the NTIA doing it? If so, why? </div><div><br></div><div>By not even asking the NTIA we are making the best possible assumption about its Administrator role. Making sure we're not missing anything by simply asking would strike me as simple due diligence.</div><div><br></div><div>Of course, you can turn the question around the other way: what reason would we have to *not* ask the NTIA about its role? </div><div><br></div><div><br></div><div><br></div><div>Kieren </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 10:27 AM, Gomes, Chuck <span dir="ltr"><<a href="mailto:cgomes@verisign.com" target="_blank">cgomes@verisign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">What is it that is unknown in terms of what NTIA does? I think it is pretty well laid out in the IANA functions contract and SAC067 and more recently summarized
in the draft proposals for CWG RFP Sections 1 & 2A.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Chuck<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:cwg-rfp3-bounces@icann.org" target="_blank">cwg-rfp3-bounces@icann.org</a> [mailto:<a href="mailto:cwg-rfp3-bounces@icann.org" target="_blank">cwg-rfp3-bounces@icann.org</a>]
<b>On Behalf Of </b>Kieren McCarthy<br>
<b>Sent:</b> Wednesday, November 05, 2014 12:18 PM<br>
<b>To:</b> Milton Mueller<br>
<b>Cc:</b> RFP3<br>
<b>Subject:</b> Re: [CWG-RFP3] Coordination of Subgroup 3<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">So it strikes me that the obvious question is: let's ask the NTIA what it does and ask it if it would have any concerns if the role simply disappeared.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Kieren<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, Nov 4, 2014 at 2:14 PM, Milton Mueller <<a href="mailto:mueller.syr.edu@gmail.com" target="_blank">mueller.syr.edu@gmail.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">I agree with David Conrad here. There is no need for the authorizer step.<br>
<br>
Milton L Mueller<u></u><u></u></p>
<div>
<p class="MsoNormal">Professor, <span style="font-size:13.0pt">Syracuse School of Information Studies</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Nov 4, 2014, at 13:05, David Conrad <<a href="mailto:david.conrad@icann.org" target="_blank">david.conrad@icann.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Robert,<br>
<br>
On Nov 4, 2014, at 3:33 AM, Robert Guerra <<a href="mailto:rguerra@privaterra.org" target="_blank">rguerra@privaterra.org</a>> wrote:<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">- RZF need to be reviewed for technical accuracy<u></u><u></u></p>
<p class="MsoNormal"><br>
For clarification, currently, the IANA Function Operator (IFO) does not have access to the Root Zone File. The Root Zone File is generated by Verisign prior to signing and distributing to the Root Server Operators (I believe -- I do not know the actual processes
used by Verisign for sure, but I can make some educated guesses).<br>
<br>
What the IFO does does see is the specific change request prior to it being submitted to NTIA for authorization. There are a number of technical checks performed by the IFO prior to allowing that change request to proceed. I believe those technical checks
are documented at <a href="https://www.iana.org/help/nameserver-requirements" target="_blank">
https://www.iana.org/help/nameserver-requirements</a> (more generally, <a href="https://www.iana.org/domains/root/help" target="_blank">
https://www.iana.org/domains/root/help</a> might be a useful resource).<br>
<br>
In the past Verisign also performed a set of technical checks (not exactly sure what they were). I suspect, but do not know for certain, they continue to do those checks.<br>
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">- 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.<u></u><u></u></p>
<p class="MsoNormal"><br>
Speaking entirely personally, it isn't clear to me that an authorizer step is actually necessary since in practice, by the time the request gets to the authorizer, the affected parties are aware of the change and they'd have raised concerns if they had any.
However whether an authorizer step is needed is, of course, for the community to decide. <br>
<br>
Regards,<br>
-drc<br>
(ICANN CTO, but speaking for myself only. Really.)<u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Cwg-rfp3 mailing list<br>
<a href="mailto:Cwg-rfp3@icann.org" target="_blank">Cwg-rfp3@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</blockquote></div><br></div>