As a new member, I will share my current understanding in an attempt to establish a baseline for discussion (, and inviting correction and/or clarification of my understanding):
Now that the structure of the GNSO has changed into a bicameral organization, there are only 7 votes where there was once more than 20 votes.
The PDP process is well-defined. What should be required to halt or delay the process, or to block a PDP?
Another comment, submitting on Ron's behalf from collected input:
Because this is routine on the front-end, it ought to be harder to forestall a PDP as it rolls through the process. A higher voting threshold makes sense in this instance. However, in some cases, new information surfaces (afterall, some PDPs take 18-to-24 months to ripen; the world can change a lot). That said, even a motion to stop a PDP because of new information ought to have to meet that higher threshold.
Maybe just to clarify, a voting threshold to stop (terminate) a PDP is already part of the revised GNSO PDP as adopted by the ICANN Board last December ("The GNSO Council may terminate a PDP prior to the publication of a Final Report only for significant cause, upon a motion that passes with a Supermajority Vote in favour of termination. The following are illustrative examples of possible reasons for a premature termination of a PDP: 1. Deadlock . The PDP Team is hopelessly deadlocked and unable to identify recommendations or statements that have either the strong support or a consensus of its members despite significant time and resources being dedicated to the PDP; 2. Changing Circumstances. Events have occurred since the initiation of the PDP that have rendered the PDP moot or no longer necessary; or 3. Lack of Community Volunteers . Despite several calls for participation, the work of the PDP Team is significantly impaired and unable to effectively conclude its deliberations due to lack of volunteer participation.")
This specific item relates to delaying a PDP after it has been initiated, a situation which recently occurred in the context of the 'thick' Whois PDP (see also staff memo posted at the top of this page for further details).
The threshold for terminating and initiating a PDP are as follows:
Terminate a PDP: Once initiated, and prior to the publication of a Final Report, the GNSO Council may terminate a PDP only for significant cause, upon a motion that passes with a GNSO Supermajority Vote in favor of termination.
Initiate a Policy Development Process ("PDP") Within Scope (as described in Annex A): requires an affirmative vote of more than one-third (1/3) of each House or more than two-thirds (2/3) of one House.
As outlined in the staff memo, we would recommend that the same voting threshold is applied as for terminating a PDP as if you would apply the same voting threshold for initiating a PDP as for delaying one, you could have 34% votes to start a PDP and then a different 34% could immediately move to suspend it. Similarly if you apply a simple majority vote: 40% want a PDP and 60% are against a PDP, then the 40% could start one, but then the 60% could immediately suspend the PDP indefinitely. In our view this seems to directly contravene the spirit of the PDP (ensure that consideration of an issue cannot be blocked if there is a certain level of support – the importance of which was also confirmed by the PDP-WT in its deliberations). Even though there is no provision or voting threshold specified for "suspending" a PDP, the effect of suspending a PDP indefinitely can effectively be the same as terminating a PDP, hence it makes sense in our view to adopt the same voting threshold as required for terminating a PDP (supermajority vote).
This seems to make sense, Marika. What I don't understand is the difference between the act of suspension and indefinite suspension. Also, are there standard definitions for "suspend" and "terminate" in relation to PDPs?
I think the difference between suspension and indefinite suspension calls for a different threshold than cancellaton. Perhaps a suspension for a specific amount of time should be classed as similar to "Amendment to an Approved PDP Team Charter" > half of each house.
In a sense a suspension is an amendment to the timeline of a charter, so this may just be a wording/interpetation issue and may not require a new rule.
I agree that there is a difference. Is there a precedent for this elsewhere in ICANN? I also agree that a new rule should be avoided if it's possible to accomplish the desired result without it.
I agree that there is a difference. Is there a precedent for this elsewhere in ICANN? I also agree that a new rule should be avoided if it is possible to accomplish the desired result without it.
Not sure the g-council has ever used it, but the Amendment to an Approved PDP Team Charter is already part of the process and defined in the PDP Manual page 58 Annex 2 section 8 of the GNSO Operating Rules ...:
Once approved, modification of any PDP Charter is discouraged, absent special circumstances. Approved charters may be modified or amended by a simple majority vote of each House.
The GNSO Operating Rules ... in section 8, page 57 on defining charters includes:
The elements of the Charter should include, at a minimum, the following elements as specified in the GNSO Working Group Guidelines: Working Group Identification; Mission, Purpose and Deliverables; Formation, Staffing and Organization, and; Rules of Engagement.
On Page 50 GNSO Operating Rules ... Annex 1 it states that the following should be included in a charter:
6.2.2.3 Deliverables and Timeframes
A Charter is expected to include some, if not all, of the following elements: potential outcomes and/or expected deliverables, key milestones, and a target timeline - all of which can, if necessary, be further refined by the WG at its onset in conjunction with the CO. Although the identification of specific work tasks, outcomes, and deadlines might be perceived as constraining the WG in its activities, it is also intended to provide guidance to the WG and prevent unintentional scope creep. It should be emphasized that the WG can always ask the CO to reconsider any of the deliverables or renegotiate deadlines identified by providing its rationale.
In certain WGs, such as a Policy Development Process, the milestones and timeline might be prescribed by the ICANN Bylaws. In other situations, sufficient thought should be given to key milestones, realistic timelines, and ways to inform and consult the ICANN Community (such as public comment periods). It should be noted that any changes to milestone dates incorporated in the charter will need to be cleared with the CO.
A delay is really a renegotiation in the deadline and thus a modification/ammendment of the charter for the PDP.
So I think the issue is already covered and doesn't even need a language change or a stretched interpretation
I recommend that perhaps we have nothing to change.
There are two issues that the SCI may consider with regard to the proposed solution:
In the case that triggered this issue, no charter had been adopted yet. The PDP was initiated by the GNSO Council, but subsequently the next step in the PDP, the formation of a DT to develop a Charter, was delayed until end of November.
The modification of a WG Charter requires a simple majority vote, which could result in the same scenario as outlined in the staff paper: 'if you apply a simple majority vote: 40% want a PDP and 60% are against a PDP, then the 40% could start one, but then the 60% could immediately suspend the PDP indefinitely. In our view this seems to directly contravene the spirit of the PDP (ensure that consideration of an issue cannot be blocked if there is a certain level of support – the importance of which was also confirmed by the PDP-WT in its deliberations). Even though there is no provision or voting threshold specified for "suspending" a PDP, the effect of suspending a PDP indefinitely can effectively be the same as terminating a PDP, hence it makes sense in our view to adopt the same voting threshold as required for terminating a PDP (supermajority vote).'
A possible alternative solution could be to update the section on the termination of a PDP in the PDP Manual as follows (see added language in bold):
The GNSO Council may terminate or delay a PDP prior to the publication of a Final Report only for significant cause, upon a motion that passes with a Supermajority Vote in favour of termination or delay. The following are illustrative examples of possible reasons for a premature termination or delay of a PDP:
1. Deadlock. The PDP Team is hopelessly deadlocked and unable to identify recommendations or statements that have either the strong support or a consensus of its members despite significant time and resources being dedicated to the PDP;
2. Changing Circumstances. Events have occurred since the initiation of the PDP that have rendered the PDP moot, or no longer necessary, or warranting a delay; or
3. Lack of Community Volunteers. Despite several calls for participation, the work of the PDP Team is significantly impaired and unable to effectively conclude its deliberations due to lack of volunteer participation.
I think the proposal is overkill in the case of a normal delay. The problem being that it does not distinguish between an indefinite day and a bounded delay. I think that what you are defining as an indefinite delay is a termination under another name and should not be called a delay. Whereas a bounded delay is something that should be done as a normal charter change.
If we support the change as defined above, even a delay of several months because of regular process slippage would require a supermajority, and if someone was against the PDP, they could demand it work to pre-established schedule or call itself deadlocked. In this case the new rule becomes yet another vector for gaming. All new rules will open new gaming paths.
In this case one of the things we wanted out of the new PDP policy was the ability to have a reasonable timeline and to be able to correct that timeline as needed. Requiring supermajority for delay make that less likely and makes it gameable.
On the other had, if we are really worried about gaming, as we always are at ICANN, we would need to make several changes to the PDP, and produce volumes of text. E.g. if I wanted to destroy a PDP that was not to my liking and we recommend a changed process for delay it, I could still work for an amendment to the charter that would make the work impossible or would cancel an offending work item with just a majority vote. Do we want to make everything in the g-council require a supermajority? Is that one of the penalties of this silly bifurcated g-council architecture we have - that all decisions that might be 'gameable' require supermajority? I think we rather have to trust to the g-council members and their SGs to make it work.
Directly answering the question of delaying a PDP before a charter, the Council is also ressponble for setting the timeline for the DT that creates the charter.
Upon initiation of the PDP, a group formed at the direction of Council should be convened to draft the charter for the PDP Team. The Council should indicate the timeframe within which a draft PDP Charter is expected to be presented to the Chair of the GNSO Council. Such a timeframe should be realistic, but at the same time ensure that this task is completed as soon as possible and does not unnecessarily delay the formation of a Working Group. The elements of the Charter should include, at a minimum, the following elements as specified in the GNSO Working Group Guidelines: Working Group Identification; Mission, Purpose and Deliverables; Formation, Staffing and Organization, and; Rules of Engagement.
The Council should consider whether to approve the proposed PDP Charter at the Council meeting following the Chair’s receipt of the proposed PDP Charter; provided that the proposed PDP Charter is received at least eight (8) calendar days prior to the GNSO Council meeting. If the proposed PDP Charter is forwarded to the GNSO Council Chair within the eight (8) calendar days immediately preceding the next GNSO Council meeting, the Council should endeavour to consider the proposed PDP Charter at the meeting after the next GNSO Council meeting.
The same voting thresholds that apply to the initiation of the PDP also apply to the approval of the proposed PDP Charter. Specifically, the proposed PDP Charter is to be approved with an affirmative vote of vote of more than one-third (1/3) of the Council members of each House or more than two-thirds (2/3) vote of one House in favour of approval of a Charter for a PDP within scope; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a GNSO Supermajority Vote as set forth in Article X, Section 3, paragraph 9(c) in favour of approving the PDP Team Charter is specified to approve the PDP Charter.
Once approved, modification of any PDP Charter is discouraged, absent special circumstances. Approved charters may be modified or amended by a simple majority vote of each House.
In exigent circumstances, upon approval of the initiation of the PDP, the GNSO Council may direct certain work to be performed prior to the approval of the PDP Charter.
If we want to make the process bullet proof we will probably need to rework this section as well. Something I am not in favor of.
We need to be careful about creating a new rule every time something happens that one of the SGs, Constituency or Staff are not happy with. We need look at the rules and decide if they are adequate in most cases and need to let the g-council find its own processes and ways of living within the rules. We should recommend new rules only when there is consensus that a rule is broken or missing. In this case we have rules that cover the case, some may prefer changing it to a higher threshold, but one hard case does not mean that the rule is broken or missing.
13 Comments
Angie Graves
As a new member, I will share my current understanding in an attempt to establish a baseline for discussion (, and inviting correction and/or clarification of my understanding):
Now that the structure of the GNSO has changed into a bicameral organization, there are only 7 votes where there was once more than 20 votes.
The PDP process is well-defined. What should be required to halt or delay the process, or to block a PDP?
Angie Graves
Another comment, submitting on Ron's behalf from collected input:
Because this is routine on the front-end, it ought to be harder to forestall a PDP as it rolls through the process. A higher voting threshold makes sense in this instance. However, in some cases, new information surfaces (afterall, some PDPs take 18-to-24 months to ripen; the world can change a lot). That said, even a motion to stop a PDP because of new information ought to have to meet that higher threshold.
Marika Konings
Maybe just to clarify, a voting threshold to stop (terminate) a PDP is already part of the revised GNSO PDP as adopted by the ICANN Board last December ("The GNSO Council may terminate a PDP prior to the publication of a Final Report only for significant cause, upon a motion that passes with a Supermajority Vote in favour of termination. The following are illustrative examples of possible reasons for a premature termination of a PDP: 1. Deadlock . The PDP Team is hopelessly deadlocked and unable to identify recommendations or statements that have either the strong support or a consensus of its members despite significant time and resources being dedicated to the PDP; 2. Changing Circumstances. Events have occurred since the initiation of the PDP that have rendered the PDP moot or no longer necessary; or 3. Lack of Community Volunteers . Despite several calls for participation, the work of the PDP Team is significantly impaired and unable to effectively conclude its deliberations due to lack of volunteer participation.")
This specific item relates to delaying a PDP after it has been initiated, a situation which recently occurred in the context of the 'thick' Whois PDP (see also staff memo posted at the top of this page for further details).
Angie Graves
Thank you for the clarification, Marika. These details are helpful, as is the staff memo you posted earlier.
Avri Doria
I think we have two 'easy' choices:
Can't remember at the moment if these are the same, if they are, we have one 'easy' choice.
Marika Konings
The threshold for terminating and initiating a PDP are as follows:
As outlined in the staff memo, we would recommend that the same voting threshold is applied as for terminating a PDP as if you would apply the same voting threshold for initiating a PDP as for delaying one, you could have 34% votes to start a PDP and then a different 34% could immediately move to suspend it. Similarly if you apply a simple majority vote: 40% want a PDP and 60% are against a PDP, then the 40% could start one, but then the 60% could immediately suspend the PDP indefinitely. In our view this seems to directly contravene the spirit of the PDP (ensure that consideration of an issue cannot be blocked if there is a certain level of support – the importance of which was also confirmed by the PDP-WT in its deliberations). Even though there is no provision or voting threshold specified for "suspending" a PDP, the effect of suspending a PDP indefinitely can effectively be the same as terminating a PDP, hence it makes sense in our view to adopt the same voting threshold as required for terminating a PDP (supermajority vote).
Angie Graves
This seems to make sense, Marika. What I don't understand is the difference between the act of suspension and indefinite suspension. Also, are there standard definitions for "suspend" and "terminate" in relation to PDPs?
Avri Doria
I think the difference between suspension and indefinite suspension calls for a different threshold than cancellaton. Perhaps a suspension for a specific amount of time should be classed as similar to "Amendment to an Approved PDP Team Charter" > half of each house.
In a sense a suspension is an amendment to the timeline of a charter, so this may just be a wording/interpetation issue and may not require a new rule.
Angie Graves
I agree that there is a difference. Is there a precedent for this elsewhere in ICANN? I also agree that a new rule should be avoided if it's possible to accomplish the desired result without it.
Angie Graves
I agree that there is a difference. Is there a precedent for this elsewhere in ICANN? I also agree that a new rule should be avoided if it is possible to accomplish the desired result without it.
Avri Doria
Not sure the g-council has ever used it, but the Amendment to an Approved PDP Team Charter is already part of the process and defined in the PDP Manual page 58 Annex 2 section 8 of the GNSO Operating Rules ...:
Once approved, modification of any PDP Charter is discouraged, absent special circumstances. Approved charters may be modified or amended by a simple majority vote of each House.
The GNSO Operating Rules ... in section 8, page 57 on defining charters includes:
The elements of the Charter should include, at a minimum, the following elements as specified in the GNSO Working Group Guidelines: Working Group Identification; Mission, Purpose and Deliverables; Formation, Staffing and Organization, and; Rules of Engagement.
On Page 50 GNSO Operating Rules ... Annex 1 it states that the following should be included in a charter:
6.2.2.3 Deliverables and Timeframes
A Charter is expected to include some, if not all, of the following elements: potential outcomes and/or expected deliverables, key milestones, and a target timeline - all of which can, if necessary, be further refined by the WG at its onset in conjunction with the CO. Although the identification of specific work tasks, outcomes, and deadlines might be perceived as constraining the WG in its activities, it is also intended to provide guidance to the WG and prevent unintentional scope creep. It should be emphasized that the WG can always ask the CO to reconsider any of the deliverables or renegotiate deadlines identified by providing its rationale.
In certain WGs, such as a Policy Development Process, the milestones and timeline might be prescribed by the ICANN Bylaws. In other situations, sufficient thought should be given to key milestones, realistic timelines, and ways to inform and consult the ICANN Community (such as public comment periods). It should be noted that any changes to milestone dates incorporated in the charter will need to be cleared with the CO.
A delay is really a renegotiation in the deadline and thus a modification/ammendment of the charter for the PDP.
So I think the issue is already covered and doesn't even need a language change or a stretched interpretation
I recommend that perhaps we have nothing to change.
Marika Konings
There are two issues that the SCI may consider with regard to the proposed solution:
A possible alternative solution could be to update the section on the termination of a PDP in the PDP Manual as follows (see added language in bold):
The GNSO Council may terminate or delay a PDP prior to the publication of a Final Report only for significant cause, upon a motion that passes with a Supermajority Vote in favour of termination or delay. The following are illustrative examples of possible reasons for a premature termination or delay of a PDP:
1. Deadlock. The PDP Team is hopelessly deadlocked and unable to identify recommendations or statements that have either the strong support or a consensus of its members despite significant time and resources being dedicated to the PDP;
2. Changing Circumstances. Events have occurred since the initiation of the PDP that have rendered the PDP moot,
orno longer necessary, or warranting a delay; or3. Lack of Community Volunteers. Despite several calls for participation, the work of the PDP Team is significantly impaired and unable to effectively conclude its deliberations due to lack of volunteer participation.
Avri Doria
I think the proposal is overkill in the case of a normal delay. The problem being that it does not distinguish between an indefinite day and a bounded delay. I think that what you are defining as an indefinite delay is a termination under another name and should not be called a delay. Whereas a bounded delay is something that should be done as a normal charter change.
If we support the change as defined above, even a delay of several months because of regular process slippage would require a supermajority, and if someone was against the PDP, they could demand it work to pre-established schedule or call itself deadlocked. In this case the new rule becomes yet another vector for gaming. All new rules will open new gaming paths.
In this case one of the things we wanted out of the new PDP policy was the ability to have a reasonable timeline and to be able to correct that timeline as needed. Requiring supermajority for delay make that less likely and makes it gameable.
On the other had, if we are really worried about gaming, as we always are at ICANN, we would need to make several changes to the PDP, and produce volumes of text. E.g. if I wanted to destroy a PDP that was not to my liking and we recommend a changed process for delay it, I could still work for an amendment to the charter that would make the work impossible or would cancel an offending work item with just a majority vote. Do we want to make everything in the g-council require a supermajority? Is that one of the penalties of this silly bifurcated g-council architecture we have - that all decisions that might be 'gameable' require supermajority? I think we rather have to trust to the g-council members and their SGs to make it work.
Directly answering the question of delaying a PDP before a charter, the Council is also ressponble for setting the timeline for the DT that creates the charter.
Upon initiation of the PDP, a group formed at the direction of Council should be convened to draft the charter for the PDP Team. The Council should indicate the timeframe within which a draft PDP Charter is expected to be presented to the Chair of the GNSO Council. Such a timeframe should be realistic, but at the same time ensure that this task is completed as soon as possible and does not unnecessarily delay the formation of a Working Group. The elements of the Charter should include, at a minimum, the following elements as specified in the GNSO Working Group Guidelines: Working Group Identification; Mission, Purpose and Deliverables; Formation, Staffing and Organization, and; Rules of Engagement.
The Council should consider whether to approve the proposed PDP Charter at the Council meeting following the Chair’s receipt of the proposed PDP Charter; provided that the proposed PDP Charter is received at least eight (8) calendar days prior to the GNSO Council meeting. If the proposed PDP Charter is forwarded to the GNSO Council Chair within the eight (8) calendar days immediately preceding the next GNSO Council meeting, the Council should endeavour to consider the proposed PDP Charter at the meeting after the next GNSO Council meeting.
The same voting thresholds that apply to the initiation of the PDP also apply to the approval of the proposed PDP Charter. Specifically, the proposed PDP Charter is to be approved with an affirmative vote of vote of more than one-third (1/3) of the Council members of each House or more than two-thirds (2/3) vote of one House in favour of approval of a Charter for a PDP within scope; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a GNSO Supermajority Vote as set forth in Article X, Section 3, paragraph 9(c) in favour of approving the PDP Team Charter is specified to approve the PDP Charter.
Once approved, modification of any PDP Charter is discouraged, absent special circumstances. Approved charters may be modified or amended by a simple majority vote of each House.
In exigent circumstances, upon approval of the initiation of the PDP, the GNSO Council may direct certain work to be performed prior to the approval of the PDP Charter.
If we want to make the process bullet proof we will probably need to rework this section as well. Something I am not in favor of.
We need to be careful about creating a new rule every time something happens that one of the SGs, Constituency or Staff are not happy with. We need look at the rules and decide if they are adequate in most cases and need to let the g-council find its own processes and ways of living within the rules. We should recommend new rules only when there is consensus that a rule is broken or missing. In this case we have rules that cover the case, some may prefer changing it to a higher threshold, but one hard case does not mean that the rule is broken or missing.