<div dir="ltr">Dear all, <div><br></div><div>Keith usefully points in his mail below to the mention in RFC 1591 of the idea of an IDNB:<br><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><i><span style="font-family:arial,sans-serif;font-size:12.4999990463257px">RFC1591 calls for an appeals mechanism through its statement:</span></i></div></div><div><div><i><span style="font-family:arial,sans-serif;font-size:12.4999990463257px">"The Internet DNS Names Review Board (IDNB), a committee established by the IANA, will act as a review panel for cases in which the parties can not reach agreement among themselves. The IDNB's decisions will be binding."</span></i></div></div><div><div><i><br style="font-family:arial,sans-serif;font-size:12.4999990463257px"></i></div></div><div><div><i><span style="font-family:arial,sans-serif;font-size:12.4999990463257px">This very critical process of natural justice would be an important step requiring addressing in the transition for many ccTLDs.</span></i></div></div></blockquote><div><div><span style="font-family:arial,sans-serif;font-size:12.4999990463257px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.4999990463257px">As far as I know, this IDNB has never been set up, right? Is there any useful history behind this that old timers can shed light on? Or was it just not done because the need id not arise? </span></div><div><span style="font-family:arial,sans-serif;font-size:12.4999990463257px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.4999990463257px">I separated this on a new thread, as this might be a concept to explore further, as Keith suggests. It has the additional benefit of being already enshrined in the 1591 "Bible". </span></div><div><span style="font-family:arial,sans-serif;font-size:12.4999990463257px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.4999990463257px">Thoughts? </span></div><div><span style="font-family:arial,sans-serif;font-size:12.4999990463257px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.4999990463257px">B.</span></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><table width="600" border="0" cellspacing="3" cellpadding="0" style="font-family:Arial,Helvetica,sans-serif;font-size:13px;line-height:1em;color:rgb(38,38,38)"><tbody><tr><td colspan="3" height="5"></td></tr><tr style="font-size:13px;color:rgb(176,173,176)"><td colspan="3">"<em>Le plus beau métier des hommes, c'est d'unir les hommes</em>", Antoine de Saint Exupéry<br>("<em>There is no greater mission for humans than uniting humans</em>")</td></tr><tr><td colspan="3" height="10"></td></tr><tr><td colspan="3"><span style="color:rgb(0,138,204);text-transform:uppercase">BERTRAND DE LA CHAPELLE</span></td></tr><tr><td colspan="3">Internet & Jurisdiction Project | Director</td></tr><tr><td colspan="3"><br></td></tr><tr><td colspan="3" height="5"></td></tr></tbody></table></div></div></div>
<br><div class="gmail_quote">On Thu, Nov 27, 2014 at 11:52 AM, Keith Davidson <span dir="ltr"><<a href="mailto:keith@internetnz.net.nz" target="_blank">keith@internetnz.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
The current IANA contract contains clause C.2.9.2.c, which states:<br>
"Delegation and Redelegation of a Country Code Top Level Domain (ccTLD)<br>
<br>
The Contractor shall apply existing policy frameworks In processing requests related to the delegation and redelegation of a ccTLD, such as RFC 1591 Domain Name System Structure and Delegation, the Governmental Advisory Committee (GAC) Principles And Guidelines For The Delegation And Administration Of Country Code Top Level Domains, and any further clarification of these policies by interested and affected parties as enumerated in Section C.1.3<br>
<br>
If a policy framework does not exist to cover a specific instance, the Contractor will consult with the interested and affected parties, as enumerated in Section C.1.3; relevant public authorities; and governments on any recommendation that is not within or consistent with an existing policy framework. In making its recommendations, the Contractor shall also take into account the relevant national frameworks and applicable laws of the jurisdiction that the TLD registry serves. The Contractor shall submit its recommendations to the COR via a Delegation and Redelegation Report."<br>
<br>
Clearly the transition proposal needs to address the issues raised within the above clause. The Framework of Interpretation (FOI) serves to address some of those issues, such as defining what constitutes "significantly interested parties" etc.<br>
<br>
The status of the FOI is that the ccNSO Council have given interim approval for the Framework and are awaiting the GAC providing its support, with a view to final adoption by both the ccNSO and GAC at ICANN Singapore, so that both constituencies might then submit the FOI to the ICANN Board as binding advice for ICANN to follow.<br>
<br>
So this is not tracking simultaneously with the timeline for the IANA transition proposal.<br>
<br>
Also, there are several issues raised by the work of the FOI Working Group (and its predecessor, the Delegations Redelegations Working Group (DRDWG) that have not yet been addressed at all yet. An example is the "Retirement" of a ccTLD. ICANN has previously made decisions on retirements of ccTLDs (where a two letter code has been removed from the ISO 3166 lits, perhaps where a country has split into two new countries). There is no current actual policy for such retirements (or reference to the concept of Retirement within RFC1591 or the GAC Principles (which incidentally are the only two documents perceived to be policies and guidelines for delegations and redelegations by the ccTLD community.<br>
<br>
And very importantly, on delegation and redelegation issues, currently the ICANN board is the final authority for decisions, with no appeals mechanism. And again, the existing IANA contract prohibits IANA from creating policy on the fly, through clause c.8.2 which states:<br>
"C.8.2 This contract does not authorize the Contractor to make material changes in the policies and procedures developed by the relevant entities associated with the performance of the IANA functions. The Contractor shall not change or implement the established methods associated with the performance of the IANA functions without prior approval of the CO."<br>
<br>
RFC1591 calls for an appeals mechanism through its statement:<br>
"The Internet DNS Names Review Board (IDNB), a committee established by the IANA, will act as a review panel for cases in which the parties can not reach agreement among themselves. The IDNB's decisions will be binding."<br>
<br>
This very critical process of natural justice would be an important step requiring addressing in the transition for many ccTLDs.<br>
<br>
Also worth noting relating to all the above is clause c.8.3 in the existing IANA contract which states:<br>
"C.8.3 The performance of the functions under this contract, including the development of recommendations in connection with Section C.2.9.2, shall not be, in any manner, predicated or conditioned on the existence or entry into any contract, agreement or negotiation between the Contractor and any party requesting such changes or any other third-party. Compliance with this Section must be consistent with C.2.9.2d."<br>
<br>
And to Chuck Gomes point earlier, I assume none of the above is applicable to any gTLD, as it appears to me that gTLDs selected a different path for its policies and contracts since the inception of ICANN, whereas the ccTLD community have consistently only agreed to the applicability of RFC 1591. In fact some ccTLDs who were delegated prior to 1994 when RFC1591 claim that they are not even committed to the requirements of RFC1591 and have their own understanding of their own arrangements with the ccTLD and Jon Postel...<br>
<br>
I hope this helps to clarify, rather than muddy the waters - but it seems to me that there has not been a lot of clarity around these issues in the discussions to date.<br>
<br>
Cheers<br>
<br>
Keith Davidson<span class=""><br>
<br>
<br></span><div class="HOEnZb"><div class="h5"><br>
</div></div></blockquote></div><br></div></div></div>