[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
On behalf of DENIC, the registry for .de, I submit the following comments on the ccSO Assistance Group's Preliminary Recommendation on Policy-Development Process (PDP): Foremost, and albeit it is understood that the Recommendation does not deal with this issue, it has to be emphasized that the scope of the ccSO needs to be carefully defined and with that, from DENIC's point of view, rather narrowly restricted to the core IANA function. Only after this, it will be possible to finally design any PDP matching the ccSO's scope. Moreover, a once defined PDP must not - different from what the Recommendation's preamble seems to suggest - be subject to modifications by the ICANN Board without any according recommendation by the ccSO itself. Regardless of these more general reservations, DENIC does not agree with some vital points of the Recommendation and would therefore not subscribe to a PDP as currently outlined therein. Most worrisome is the notion to let an Issue Manager steer the whole PDP, even more so since the Recommendation does not reveal who it envisages to fill in this position (even though clause 6. suggests that it will be an ICANN representative, i. e. most probably an ICANN staff member). It is uncomprehensible why such an institution without any legitimation should be given the factual power to define the goal of the PDP (by writing the Issue Report) and highly influence (to say the least) its outcome (by receiving the region's statements, reviewing public comments and writing the Final as well as the Board Report). Furthermore, with regard to the initiation of a PDP, particularly the definition of the necessary majority within the Council appears as somewhat strange: Firstly, there seems to be no quorum outlined; clause 3.b) just speaks of a majority of 50 per cent of the Council members present. Since e-mail-voting allows easy participation of every Council member there is no need to limit the necessary majority to a certain percentage of members being present. Instead it would be reasonable to define the majority in relation to the total number of Council members regardless of how many are present or participate in the ballot. Besides, a 50 per cent majority is clearly insufficient. Secondly, the alternative majority referring to regions is insofar unsatisfactory as it is not defined as a majority of at least three of the five regions. Taking into account the importance of the regions it is actually even highly desirable to make sure that in any case a PDP cannot be initiated against the vote of more than one region. Thirdly, the Recommendation leaves it undefined what a "supermajority" is supposed to be. Regardless of this, the Council must not be able to initiate a PDP with regard to an issue outside the ccSO's scope anyway. Therefore, the PDP should rather lay out a process as to how a dispute on whether a certain issue falls within the ccSO's scope will be resolved. No less important is, at the end of a PDP, the final procedure within the Council and thereafter the ICANN Board (as described in clauses 11. and 13.). Unfortunately, the Recommendation comprises some unsatisfactory elements there as well: Firstly, it is again not being defined what the required "supermajority" should be and it is again not being ensured that no more than one region can be outvoted. Secondly, to prohibit abstentions neither appears to be overly democratic nor does it make much sense because then Council members wishing to abstain will just not participate in the voting. Thirdly, if the necessary majority is not being reached the PDP has obviously come to its end and there is no need to bring the concerned issue to the ICANN board anymore, let alone to have the ICANN Board vote on it. Fourthly, albeit depending on what the ccSO's exact scope will be, there is at least not necessarily a reason recognisable why the ICANN Board should be forced to adopt the recommended policy. Rather the other way around, the ccTLDs need certainty that the ICANN Board will neither adopt nor implement a policy which the ccSO has not recommended or even explicitely rejected. Therefore it needs to be stated clearly that the ICANN Board cannot bypass or outvote a negative decision by the Council nor adopt any policy affecting ccTLDs without an according recommendation by the Council. Besides, it appears as superfluous to state in clause 13.c) that the ICANN Board shall adopt the policy unless more than 50 per cent are against it because if more than 50 per cent are against there is no majority in favour of the policy anyway. Additionally, the procedure between initiation and closure of a PDP as outlined in the Recommendation brings up some important questions: For example it remains unclear who determines whether a representative meets the criteria mentioned in clause 5.b) and whether (and if so, by whom) a representative can be rejected on the grounds of not meeting the criteria. Also, it seems to be uncomprehensible why the Recommendation does not leave it up to the regions to bear the risk that their representatives do not meet the criteria. Additionally, the Recommendation does not outline how the regions select their representatives and what happens if a region fails to meet the ten days deadline. Finally, clause 7.d) which deals with the information that the Task Force should collect and take into account, misses out the potentially most important point: In any case it has to be examined at some point in a PDP's course (or rather even before its initiation) whether or to what extent the policy in question is legally feasible. Regardless of these points of criticism, DENIC welcomes and continues to support the Assistance Group's efforts not only to define a reasonable PDP but also to develop a framework for a ccSO that will meet the ccTLD community's needs. At the same time, DENIC is confident that the Assistance Group, taking into account all comments on its current Recommendation, will finally reach a satisfactory conclusion. Stephan Welzel Attorney-at-Law Head of Legal Department DENIC eG [Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index] |