[CWG-RFP3] IDNB (was: Re: Brief comments after Frankfurt)

[Bertrand de La Chapelle]

Dear all,

Keith usefully points in his mail below to the mention in RFC 1591 of the
idea of an IDNB:

*RFC1591 calls for an appeals mechanism through its statement:*
*"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."*

*This very critical process of natural justice would be an important step
requiring addressing in the transition for many ccTLDs.*


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?

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".

Thoughts?

B.

"*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de
Saint Exupéry
("*There is no greater mission for humans than uniting humans*")BERTRAND DE
LA CHAPELLEInternet & Jurisdiction Project | Director

On Thu, Nov 27, 2014 at 11:52 AM, Keith Davidson <keith at internetnz.net.nz>
wrote:

> Hi all,
>
> The current IANA contract contains clause C.2.9.2.c, which states:
> "Delegation and Redelegation of a Country Code Top Level Domain (ccTLD)
>
> 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
>
> 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."
>
> 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.
>
> 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.
>
> So this is not tracking simultaneously with the timeline for the IANA
> transition proposal.
>
> 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.
>
> 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:
> "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."
>
> RFC1591 calls for an appeals mechanism through its statement:
> "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."
>
> This very critical process of natural justice would be an important step
> requiring addressing in the transition for many ccTLDs.
>
> Also worth noting relating to all the above is clause c.8.3 in the
> existing IANA contract which states:
> "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."
>
> 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...
>
> 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.
>
> Cheers
>
> Keith Davidson
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141127/9c8a86b5/attachment.html>