FINAL VERSION TO BE SUBMITTED IF RATIFIED
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
SECOND DRAFT SUBMITTED - Uploaded on
Redline version:
| .DOCX | |
Clean version:
| .DOCX | |
|---|---|
For many years, the ALAC has been a supporter of the need to remove barriers that result in silos within ICANN's communities. The ALAC has supported the creation of Cross Community Working Groups (interchangeably referenced as CCWGs or CWGs) for this very reason. Historically, the ALAC has taken part in many such initiatives:
- Cross Community Working Group on Morality and Public Order (Rec 6)
- Cross Community Working Group on Use of Country/Territory Names as TLDs
- Joint SO-AC New gTLD Applicant Support Working Group (JAS-WG)
- Joint DNS Security and Stability Working Group (DSSA-WG)
- Cross Community Working Group on Internet Governance
- Cross Community Working Group on IANA Stewardship Transition
- Cross Community Working Group on ICANN Accountability
Having been a co-chartering Organization of several of these Cross Community Working Groups, the ALAC is well aware of the diverse requirements and the current lack of unity regarding the chartering process and framework by which those groups operate. The Draft Framework of Principles for Cross Community Working Groups is therefore welcomed to increase efficiency in the process of chartering these working groups and to reduce the potential for ambiguity and time lost in finding a consensus on internal processes.
The ALAC must however call attention to a number of important points that warrant further discussions:
1. The finite nature of a CCWG's life cycle
The framework proposes that every CCWG needs a "starting point" and an "end point" defined as the provision of deliverables and subsequent closure of the CCWG with agreement from Chartering Organizations. There are no provisions for processes that are ongoing and therefore do not have an end point.
At present, a CCWG is the only formal vehicle for a process officially linking SOs and ACs together to work towards formally actionable goals, with regards to both the Board and the Chartering Organizationsthemselves. Removing the potential for an ongoing nature of a CCWG, the focus on an end point, final report and implementation phase removes the flexibility towards any CCWG that has ongoing work, such as the current CCWG on Internet Governance.
Should the final recommendations of the CCWG remain that every CCWG needs to have an end point and be closed after a Final Report is produced, the ALAC makes the following recommendation: CCWG Principles should recommend an appropriate vehicle to be created and defined to cater to a working group that requires ongoing efforts as well as SO/AC official chartering; as such, this type of Cross Community effort would be enabled to regularly make formal recommendations to its chartering SOs & ACs instead of a final set of deliverables, which would only apply to CCWGs with finite life cycles.
At present, several apparently less formal structures exist:
- Cross Community Working Party: The Cross Community Working Party on ICANN's Corporate and Social Responsibility to Respect Human Rights (CCWP-HR) uses this type of structure. It does not require chartering by any SO/AC and serves as a good platform for discussion, but the nature of its relationship with SOs/ACs is undefined. For example, the CCWP-HR is supported by the GNSO.
- Cross Community Committee: The Cross Community Committee on Accessibility uses this type of structure, but the nature of its relationship with SOs/ACs is also undefined.
- Other Review Groups, like the Geographic Regions Working Group, and IDN Variant TLD Issues Project, etc. The nature of relationship with SOs & ACs in undefined as they are related directly to an ICANN-wide process that is often Board or Staff driven (in the case of an implementation project).
In the above cases where the structure is not chartered by SOs and ACs, how each structure makes formal recommendations to SOs, ACs and/or the ICANN Board is not specifically defined. The ALAC therefore recommends either that the requirement for an end point for CCWGs be dropped or that the CCWG-Principles make recommendations for an alternative vehicle that will operate along the same formality and rules as a CCWG but without an end point.
2. Chartering Organizations’ decisions on a CCWG’s output
The proposed framework mentions several variations of the same concept regarding the use of the recommendations made by a CCWG:
"Only after these decisions by the Chartering Organizations have been made can further steps (e.g. implementation, submission of recommendations, providing input into other processes, etc.) be taken if proposed." (P.3)
"Unless the CCWG’s Charter provides otherwise, further steps (e.g. implementation, submission of recommendations, providing input into other processes, etc.), if proposed, can be taken only after adoption of the outputs by the Chartering Organizations or the ICANN Board, as appropriate." (P.11)
The ALAC is concerned that both of these paragraphs point to the need for all Chartering Organizations to decide on recommendations of a CCWG before being able to make use of the CCWG's recommendations. This requirement for a decision from all Chartering Organizations allows a single SO/AC to potentially block/delay the implementation of the CCWG recommendations.
The ALAC recommends that the text be modified to allow each Chartering Organization to decide on the use of the outputs of the CCWG as it so desires. A CCWG should be a tool to promote better communication amongst ICANN's SOs and AC and to stimulate a faster track to achieve results than by working in silos. The framework for CCWGs should therefore not introduce barriers to SOs and ACs using the outputs of the CCWG as they see fit, depending on circumstances. As an example, the Joint SO-AC New gTLD Applicant Support Working Group (JAS-WG) needed a very fast turnaround for recommendations to reach the ICANN Board in time for the implementation of an applicant support program in the first application round of new gTLDs. On this occasion, not all Chartering Organizations were able to adopt the outputs in time. So the outputs were presented to the Board prior to adoption by all SO/ACs. Specifically prohibiting such flexibility would have stopped the JAS-WG deliverables from reaching the Board in time and would have delayed the whole new gTLD roll-out process.
In order to allow this flexibility, depending on circumstances, the ALAC proposes to scrap this requirement and specify that any submission of recommendations as a follow-up by any of the Chartering SO/ACs needs to be clear about the level of support (or not) from each Chartering Organizations. Alternatively, one could re-word the requirement by allowing exceptions due to "exceptional circumstances".
Several paragraphs in the document therefore need to be amended.
3. Additional points
Page 2:
Additionally, before initiating a CCWG, the following critical points need to be considered:
(...)
“3. Consider if the participating organizations are able to collectively adopt the consensus output of the CCWG.“
The ALAC requests clarification on this sentence. How can SOs and ACs collectively adopt a consensus output of the CCWG when the work of the CCWG has not yet started? Is this really saying that prior to chartering, the AC/SO must decide if they will approve the outcomes?
The ALAC also suggests that prior to chartering a CCWG, AC/SOs should be able to request that staff create a background paper (roughly equivalent to a GNSO PDP Issue Report).
Page 8, Section #6 provides an explicit set of volunteer roles, with guidelines as to what commitment, skills or qualities these roles might demand. It should be made clear that the description of volunteer roles is given solely as an example.
Page 11 Section #3.1 sub-section #2: In current CWG Stewardship & CCWG Accountability, both Cross Community Working Groups are continuing their work after their Final Report has been approved by all Chartering SOs and ACs. The closure of a working group should therefore not be compulsory upon submission of its final report. The ALAC therefore recommends that this recommendation be scrapped as it currently stands.
Questions
• Should there be a requirement that all CCWG recommendations must be considered by the ICANN Board, if minimum requirements are met (similar to the GNSO Policy Development Process?
No, except in the case that CCWG deliverables require ICANN Board action. In other words, it should not be required unless Board action is required. The ALAC believes that CCWG policy output carries at least the same weight as GNSO Policy Development Process output.
• Should more formalized Operating Procedures be developed for CCWGs?
No, not at this point.
The use of CCWGs is evolving and the processes by which CCWGs operate should be allowed to evolve organically. This is a very broad question. The ALAC believes that in the long term, some formalisation and optimisation of procedures may be needed, without restricting flexibility that is needed in the broad range of circumstances that would necessitate the creation of a CCWG.
• Should additional mechanisms be developed to deal with situations in which Chartering Organizations may disagree or want to discontinue their engagement?
The current process, as described in the proposal is that if there is a disagreement between Organization, it is mandatory to come back to the CCWG and resolve it. The ALAC disagrees with this. The CCWG should be able to, as the CCWG-Accountability almost did, forward a report to the Board even without full support or non-objection.
If a Chartering Organization decides to withdraw, they should be allowed to withdraw.
• Should there be a mechanism to close a CCWG if it is clear that it will not be possible to produce a final report or that circumstances have overtaken the need for a CCWG? (See Section 3.3.4 and 3.4.2 above)
For a CCWG that has a finite life-cycle and the ultimate objective to produce final deliverables, yes, there should be a mechanism in place if its final report cannot be produced, if circumstances have overtaken the need for an output from the CCWG and especially when Chartering Organizations withdraw. This is invalid for CCWG that do not have an end point, as the production of a final report is not possible.
• For implementation and post-implementation of the CCWG output, what should be the role of the CCWG? Should the Charter template be expanded to include these details? How would the process be initiated?
The Charter template should include options for the Implementation of CCWG output. These options should be provided as potential avenues that the CCWG might wish to pursue for implementation, depending on circumstances. The options could include that the members of the CCWG automatically become members of the Implementation Team, with the provision that ultimately, whether members of the CCWG are part of the Implementation Team or not will be defined by the specific needs of each CCWG.
• As the appointment mechanism for members varies across SO/ACs, how can CCWG leadership and support staff be kept informed of appointments and changes?
The current method of appointment by SOs and ACs is the formal notification of the appointment by the SO/AC Chair or support staff to the CCWG co-Chairs or support staff. This, as well as removal or replacement of members, should be documented.
• Are uniform Statements of Interest, or something similar, beneficial to the CCWG process? (See section 3.2.7 above)
The ALAC believes that uniform Statement of Interest, with a set minimum information requirements would be very beneficial to the CCWG. The Statement of Interest should include who the participant’s employer is and whether they are paid to take part in the CCWG by anyone else than their employer.
• Should specific requirements be listed for the appointment of members?
Appointed members should be required to explicitly agree to the ICANN expected standards of behavior. Beyond this, any further requirements should be set by the Charter or the appointing SOs and ACs.
• Who launches a call for volunteers/participants?
There should be flexibility in how the call should be sent out. If the Charter Drafting Team believes that a particular method is required, it can specify it.
FIRST DRAFT SUBMITTED (Obsoleted by second draft) - Uploaded on
For many years, the ALAC has been a supporter of the need to remove barriers that result in silos within ICANN's communities. The creation of Cross Community Working Groups (interchangeably referenced as CCWGs or CWGs) has been supported by the ALAC for this very reason. Historically, the ALAC has taken part in many such initiatives:
- Cross Community Working Group on Morality and Public Order (Rec 6)
- Cross Community Working Group on Use of Country/Territory Names as TLDs
- Joint SO-AC New gTLD Applicant Support Working Group (JAS-WG)
- Joint DNS Security and Stability Working Group (DSSA-WG)
- Cross Community Working Group on Internet Governance
- Cross Community Working Group on IANA Stewardship Transition
- Cross Community Working Group on ICANN Accountability
Having been a co-chartering organisation of several of these Cross Community Working Groups, the ALAC is well aware of the diversity of requirements and the current lack of unity regarding the chartering process and framework by which those groups operate. The Draft Framework of Principles for Cross Community Working Groups is therefore welcome to increase efficiency in the process of chartering these working groups and to reduce the potential for ambiguity and time lost in finding a consensus on internal processes.
The ALAC must however point out a number of important points which it believes should be discussed further:
1. The finite nature of a CCWG's life cycle: the framework proposes that every CCWG needs a "starting point" and an "end point" defined as the provision of deliverables and subsequent closure of the CCWG with agreement from Chartering Organisations. There are no provisions for processes that are ongoing that therefore do not have an end point.
At present, the only formal vehicle for a process officially linking SOs and ACs together to work towards formally actionable goals, both with regards to the Board but with regards to the chartering organisations themselves, is a CCWG. Removing the potential for an ongoing nature of a CCWG, thus focussing on an end point, final report and implementation phase removes flexibility towards any CCWG that is ongoing, such as, for example, the current CCWG on Internet Governance.
Should the final recommendations of the CCWG remain that every CCWG needs to have an end point and for a CCWG to be closed after a Final Report is produced, the ALAC recommends that the CCWG on CCWG to make recommendations as to what vehicle it recommends should be created and defined to cater for a working group that requires such an ongoing requirement whilst also requiring SO/AC official chartering so as to provide it with the ability to regularly make formal recommendations to its chartering SOs & ACs.
At present, several apparently less formal structures exist:
- Cross Community Working Party: this type of structure is used by the Cross Community Working Party on ICANN's Corporate and Social Responsibility to Respect Human Rights (CCWP-HR). This type of structure does not require chartering by any SO/AC. It serves as a good platform for discussion, but the nature of its relationship with SOs/ACs is undefined. For example, the CCWP-HR is supported by the GNSO.
- Cross Community Committee: this type of structure is used by the Cross Community Committee on Accessibility, but the nature of its relationship with SOs/ACs is also undefined.
- Other Review Groups, like the Geographic Regions Working Group; IDN Variant TLD Issues Project; etc. The nature of relationship with SOs & ACs in undefined as they are related directly to an ICANN-wide process that is often Board or Staff driven (in the case of an implementation project).
How each structure makes formal recommendations to SOs, ACs and/or the ICANN Board is not specifically defined in cases where the structure is not chartered by SOs and ACs. The ALAC therefore recommends either that the requirement for an end point for CCWGs be dropped or that the CCWG-Principles make recommendations for an alternative vehicle that will operate along the same formality and rules as a CCWG but without an end point.
2. The proposed framework mentions several variations of the same concept regarding the use of the recommendations made by a CCWG:
"Only after these decisions by the Chartering Organizations have been made can further steps (e.g. implementation, submission of recommendations, providing input into other processes, etc.) be taken if proposed." (P.3)
"Unless the CCWG’s Charter provides otherwise, further steps (e.g. implementation, submission of recommendations, providing input into other processes, etc.), if proposed, can be taken only after adoption of the outputs by the Chartering Organizations or the ICANN Board, as appropriate." (P.11)
The ALAC is concerned that both of these paragraphs point to the need for all Chartering Organisations to decide on recommendations of a CCWG before being able to make use of the CCWG's recommendations. This requirement for a decision from all chartering organisations allows the blocking/delaying of the implementation of the CCWG recommendations by a single SO/AC.
The ALAC recommends that the text be modified to allow each Chartering Organisation to decide on the use of the outputs of the CCWG as it so desires. A CCWG should be a tool to promote better communication amongst ICANN's SOs and AC and to stimulate a faster track to achieve results than by working in silos. The framework for CCWGs should therefore not introduce barriers to SOs and ACs using the outputs of the CCWG as they see fit, depending on circumstances. As an example, the Joint SO-AC New gTLD Applicant Support Working Group (JAS-WG) needed a very fast turnaround for recommendations to reach the ICANN Board in time for the implementation of an applicant support program in the first round of gTLDs. On this occasion, not all Chartering organisations were able to adopt the outputs in time. So the outputs were presented to the Board prior to adoption by all SO/ACs. Specifically prohibiting such flexibility would have stopped the JAS-WG deliverables from reaching the Board in time and would have delayed the whole new gTLD roll-out process.
In order to allow this flexibility depending on circumstances, the ALAC proposes to scrap this requirement and specifying that any submission of recommendations as a follow-up by any of the Chartering SO/ACs needs to be clear of the level of support (or not) from each of the Chartering Organisations. Alternatively, one could re-word the requirement by allowing exceptions due to "exceptional circumstances".
Several paragraphs in the document therefore need to be amended.
Page 2:
Additionally, before initiating a CCWG, the following critical points need to be considered:
(...)
“3. Consider if the participating organizations are able to collectively adopt the consensus output of the CCWG.“
The ALAC requests clarification on this sentence. How can SOs and ACs collectively adopt a consensus output of the CCWG when the work of the CCWG has not yet started? Is this really saying that prior to chartering, the AC/SO must decide if they will approve the outcomes?
The ALAC also suggests that prior to chartering a CCWG, AC/SOs should be able to request that staff create a background paper (roughly equivalent to a GNSO PDP Issue Report).
Page 8, Section #6 provides an explicit set of volunteer roles, with guidelines as to what commitment, skills or qualities these roles might demand. It should be made clear that the description of volunteer roles is given solely as an example.
Page 11 Section #3.1 sub-section #2 : In current CWG Stewardship & CCWG Accountability, both Cross Community Working Groups are continuing their work after their Final Report has been approved by all Chartering SOs and ACs. The closure of a working group should therefore not be compulsory upon submission of its report. The ALAC therefore recommends that this recommendation be scrapped as it currently stands.
Questions
• Should there be a requirement that all CCWG recommendations must be
considered by the ICANN Board, if minimum requirements are met (similar to
the GNSO Policy Development Process?
No, except in the case that CCWG deliverables require ICANN Board action. In other words, it should not be required unless Board action is required. The ALAC believes that CCWG policy output carries at least the same weight as GNSO Policy Development Process output.
• Should more formalized Operating Procedures be developed for CCWGs?
No, not at this point.
The use of CCWGs is evolving and the processes by which CCWGs operate should be allowed to evolve organically. This is a very broad question. The ALAC believes that in the long term, some formalisation and optimisation of procedures may be needed, without restricting flexibility that is needed in the broad range of circumstances that would necessitate the creation of a CCWG.
• Should additional mechanisms be developed to deal with situations in which
Chartering Organizations may disagree or want to discontinue their
engagement?
The current process, as described in the proposal is that if there is a disagreement between organisations, it is mandatory to come back to the CCWG and resolve it. The ALAC disagrees with this. The CCWG should be able to, as the CCWG-Accountability almost did, forward a report to the Board even without full support or non-objection.
If a Chartering Organisation decides to withdraw, they should be allowed to withdraw.
• Should there be a mechanism to close a CCWG if it is clear that it will not be
possible to produce a final report or that circumstances have overtaken the need
for a CCWG? (See Section 3.3.4 and 3.4.2 above)
Yes there should be a mechanism in place especially when Chartering Organisations withdraw. There is no need to keep CCWG running if opinions in the CCWG are such that no consensus would be found or the CCWG's output would be obsolete. There should be a mechanism to close the CCWG down.
• For implementation and post-implementation of the CCWG output, what should
be the role of the CCWG? Should the Charter template be expanded to include
these details? How would the process be initiated?
The Charter template should include options for the Implementation of CCWG output. These options should be provided as potential avenues that the CCWG might wish to pursue for implementation, depending on circumstances. The options could include that the members of the CCWG automatically become members of the Implementation Team.
• As the appointment mechanism for members varies across SO/ACs, how can
CCWG leadership and support staff be kept informed of appointments and
changes?
The current method of appointment by SOs and ACs is the formal notification of the appointment by the SO/AC Chair or support staff to the CCWG co-Chairs or support staff. This, as well as removal or replacement of members, should be documented.
• Are uniform Statements of Interest, or something similar, beneficial to the CCWG
process? (See section 3.2.7 above)
The ALAC believes that uniform Statement of Interest, with set minimum information requirements would be very beneficial to the CCWG. The Statement of Interest should include who the participant’s employer is and whether they are paid to be take part in the CCWG by anyone else than their employer.
• Should specific requirements be listed for the appointment of members?
Appointed members should be required to explicitly agree to the ICANN expected standards of behaviour. Beyond this, any further requirements should be set by the Charter or the appointing SOs and ACs.
• Who launches a call for volunteers/participants?
There should be flexibility in how the call should be sent out. If the Charter Drafting Team believes that a particular method is required, it can specify it.
