Re: [CWG-Stewardship] Comments on IANA Transition Flow Chart
Thanks, Donna. I've updated the flow chart (see attached) in relation to your comments on pages 1, 2 and 4 which I believe are minor changes and in line what was discussed in Frankfurt (on page 4, I changed 'prepare' to 'post' as I think that aligns with the intent of your comment?). In relation to your comments on page 5, those sound like details that may be better suited for the actual written proposal and not necessarily the flow chart? I've posted those comments here below so that it may be easier for others to review and comment. Best regards, Marika Page 5 - Entering into Contract (Transition) - Comments from Donna Austin: * Can we confirm that what we mean by commence the contracting process includes the development of a contract or agreement to replace the existing arrangement between ICANN and NTIA. We should be explicit. * I'd like to see a step in here that has the Review Team review the current contract IANA Functions contract as a starting point -- commencing community consultations seems unguided. From: Donna Austin <Donna.Austin@ariservices.com<mailto:Donna.Austin@ariservices.com>> Date: Thursday 20 November 2014 17:37 To: "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: [CWG-Stewardship] Comments on IANA Transition Flow Chart All I have a few comments on the IANA Transition Flow Chart that I've attached here for consideration. Thanks, Donna [Description: Description: Description: ARI Logo]DONNA AUSTIN Policy and Industry Affairs Manager ARI REGISTRY SERVICES Melbourne|Los Angeles P +1 310 890 9655 P +61 3 9866 3710 E donna.austin@ariservices.com<mailto:donna.austin@ariservices.com> W www.ariservices.com<http://www.ariservices.com/> Follow us on Twitter<https://twitter.com/ARIservices> The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: Donna Austin Sent: Thursday, 20 November 2014 5:31 PM To: Marika Konings (marika.konings@icann.org<mailto:marika.konings@icann.org>) Cc: Bernard Turcotte (turcotte.bernard@gmail.com<mailto:turcotte.bernard@gmail.com>); Bart Boswinkel (bart.boswinkel@icann.org<mailto:bart.boswinkel@icann.org>) Subject: Marika I've made some comments on the attached. Let me know if you can't access the comments. Thanks Donna
One small update to the version I just sent around, I've added the word 'DRAFT' to the heading of each page to make it even clearer that these are drafts that are under review / discussion by the CWG. Best regards, Marika From: Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>> Date: Friday 21 November 2014 18:02 To: Donna Austin <Donna.Austin@ariservices.com<mailto:Donna.Austin@ariservices.com>>, "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: Re: [CWG-Stewardship] Comments on IANA Transition Flow Chart Thanks, Donna. I've updated the flow chart (see attached) in relation to your comments on pages 1, 2 and 4 which I believe are minor changes and in line what was discussed in Frankfurt (on page 4, I changed 'prepare' to 'post' as I think that aligns with the intent of your comment?). In relation to your comments on page 5, those sound like details that may be better suited for the actual written proposal and not necessarily the flow chart? I've posted those comments here below so that it may be easier for others to review and comment. Best regards, Marika Page 5 - Entering into Contract (Transition) - Comments from Donna Austin: * Can we confirm that what we mean by commence the contracting process includes the development of a contract or agreement to replace the existing arrangement between ICANN and NTIA. We should be explicit. * I'd like to see a step in here that has the Review Team review the current contract IANA Functions contract as a starting point -- commencing community consultations seems unguided. From: Donna Austin <Donna.Austin@ariservices.com<mailto:Donna.Austin@ariservices.com>> Date: Thursday 20 November 2014 17:37 To: "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: [CWG-Stewardship] Comments on IANA Transition Flow Chart All I have a few comments on the IANA Transition Flow Chart that I've attached here for consideration. Thanks, Donna [Description: Description: Description: ARI Logo]DONNA AUSTIN Policy and Industry Affairs Manager ARI REGISTRY SERVICES Melbourne|Los Angeles P +1 310 890 9655 P +61 3 9866 3710 E donna.austin@ariservices.com<mailto:donna.austin@ariservices.com> W www.ariservices.com<http://www.ariservices.com/> Follow us on Twitter<https://twitter.com/ARIservices> The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: Donna Austin Sent: Thursday, 20 November 2014 5:31 PM To: Marika Konings (marika.konings@icann.org<mailto:marika.konings@icann.org>) Cc: Bernard Turcotte (turcotte.bernard@gmail.com<mailto:turcotte.bernard@gmail.com>); Bart Boswinkel (bart.boswinkel@icann.org<mailto:bart.boswinkel@icann.org>) Subject: Marika I've made some comments on the attached. Let me know if you can't access the comments. Thanks Donna
Here's characteristics of the Standing Committee in the first table: "Small STANDING Committee consisting of IANA Customers Responsible for operational review and transactional performance review". What is the definition of IANA Customers? Does it mean Direct IANA Naming Customers or is it broader than that? Here's the function shown in the second table for the Standing Committee: "Operational review, transactional performance review and developing SLAs". What are the definitions of 'operational' and 'transactional'? Is 'transactional' a subset of 'operational'? In the Operational Review flowchart for the Standing Committee, what is the difference between 'Post reports / information for public information' and 'Review information received, publish results'? Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Marika Konings Sent: Friday, November 21, 2014 1:04 PM To: Marika Konings; Donna Austin; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Comments on IANA Transition Flow Chart One small update to the version I just sent around, I've added the word 'DRAFT' to the heading of each page to make it even clearer that these are drafts that are under review / discussion by the CWG. Best regards, Marika From: Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>> Date: Friday 21 November 2014 18:02 To: Donna Austin <Donna.Austin@ariservices.com<mailto:Donna.Austin@ariservices.com>>, "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: Re: [CWG-Stewardship] Comments on IANA Transition Flow Chart Thanks, Donna. I've updated the flow chart (see attached) in relation to your comments on pages 1, 2 and 4 which I believe are minor changes and in line what was discussed in Frankfurt (on page 4, I changed 'prepare' to 'post' as I think that aligns with the intent of your comment?). In relation to your comments on page 5, those sound like details that may be better suited for the actual written proposal and not necessarily the flow chart? I've posted those comments here below so that it may be easier for others to review and comment. Best regards, Marika Page 5 - Entering into Contract (Transition) - Comments from Donna Austin: * Can we confirm that what we mean by commence the contracting process includes the development of a contract or agreement to replace the existing arrangement between ICANN and NTIA. We should be explicit. * I'd like to see a step in here that has the Review Team review the current contract IANA Functions contract as a starting point -- commencing community consultations seems unguided. From: Donna Austin <Donna.Austin@ariservices.com<mailto:Donna.Austin@ariservices.com>> Date: Thursday 20 November 2014 17:37 To: "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: [CWG-Stewardship] Comments on IANA Transition Flow Chart All I have a few comments on the IANA Transition Flow Chart that I've attached here for consideration. Thanks, Donna [Description: Description: Description: ARI Logo]DONNA AUSTIN Policy and Industry Affairs Manager ARI REGISTRY SERVICES Melbourne|Los Angeles P +1 310 890 9655 P +61 3 9866 3710 E donna.austin@ariservices.com<mailto:donna.austin@ariservices.com> W www.ariservices.com<http://www.ariservices.com/> Follow us on Twitter<https://twitter.com/ARIservices> The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: Donna Austin Sent: Thursday, 20 November 2014 5:31 PM To: Marika Konings (marika.konings@icann.org<mailto:marika.konings@icann.org>) Cc: Bernard Turcotte (turcotte.bernard@gmail.com<mailto:turcotte.bernard@gmail.com>); Bart Boswinkel (bart.boswinkel@icann.org<mailto:bart.boswinkel@icann.org>) Subject: Marika I've made some comments on the attached. Let me know if you can't access the comments. Thanks Donna
Hello all, As someone who was not at the Frankfurt meeting I am trying to make sense of this 'flow chart.' As far as I can tell, this is a proposal - a response to RFP section 3 - in the simplified form of a 'flow chart.' This does provide an overall view of what is being proposed with visual simplicity, but leaves unanswered many critical questions that would have to be dealt with before we can bring it back to our communities for evaluation and assessment of its acceptability. Here are my questions: 1, Who or what is the IANA contracting entity? Is it inside ICANN or outside of ICANN? (Hint: it had better be outside if this idea is to conform to the principles of separability and accountability.) How is it governed? 2. Who is the "periodic review team"? Is it inside ICANN or outside of ICANN? How is it formed? Why is it different from the contracting authority; i.e., what is its legal or organizational relationship to the contracting authority? 3. I understand 'performance review' to be a fairly narrow assessment of how well the IANA performs its specified technical functions. If so, why is there a distinction between a "customer standing committee" and the "periodic review team"? While I can understand why, e.g., a civil society advocate might be extremely interested in whether IANA is not implementing policies that were passed, or implementing policies that were not accepted (these are accountability issues, not performance issues). But I do not understand what role a digital rights advocate or an intellectual property lawyer would play, say, in assessing the accuracy and security of a TLD operator's root zone file modifications or interactions with the IANA. 4. Accountability and true separability (both of which are recognized principles of this group) requires a periodic renewal of the contract in which there is no "presumption of renewal" and a willingness to entertain other providers of the functions. Periodicity minimizes the friction associated with reviews and with moving the contract by clarifying expectations well in advance. Periodicity is NOT inimical to continuity or to long-term investment by a well-behaved provider that satisfies its customers. The flow chart seems to contain a much weaker - and to me, unacceptable - concept of a "periodic review team" which is merely there to advise the incumbent contractor on how to improve service, just as the current ATRT merely advises ICANN on how to improve. Let me flag this as a deal-breaking issue for me and, I think, many others. If you want consensus this will have to be significantly changed. 5. Happy to see a binding, independent appeals process in there. But could someone tell me more detail what kind of appeals pertaining to policy implementation you had in mind? Hopefully this would not be a way for people who did not get what they wanted from the policy process to circumvent agreed policy by going after IANA implementation, but would instead be an avenue for people to challenge unauthorized or incorrect IANA implementations? I have other questions, but these are the big ones. Let me add that based on what I have heard from various stakeholders who were in Frankfurt, that while progress was made many key people were absent, there was little feeling of consensus on key ideas and that we are still talking more about details than an acceptable approach to the whole solution. Therefore, a lot of discussion and modification of the proposal/'flow chart' will have to take place on this list. --MM
In-line comments On Sat, Nov 22, 2014 at 10:55 PM, Milton L Mueller <mueller@syr.edu> wrote:
1, Who or what is the IANA contracting entity? Is it inside ICANN or outside of ICANN? (Hint: it had better be outside if this idea is to conform to the principles of separability and accountability.) How is it governed?
The contracting entity will be a separate legal entity outside ICANN.
2. Who is the “periodic review team”? Is it inside ICANN or outside of ICANN? How is it formed? Why is it different from the contracting authority; i.e., what is its legal or organizational relationship to the contracting authority?
The objective is to keep the new contracting entity as boring/unattractive as possible in order to avoid the creation of a new entity having the same growth dynamics as ICANN. The only purpose of the contracting entity is to hold the contract. The actual substantive determination for anything related to the contract will be delegated to the 'periodic review team'. The periodic review team is being envisioned as something that is free floating. It is supposed to be neither in ICANN nor in the new contracting entity. The new contracting entity will be delegating the contracting function to the periodic review team through its bylaws and the contract terms and conditions.
3. I understand ‘performance review’ to be a fairly narrow assessment of how well the IANA performs its specified technical functions. If so, why is there a distinction between a “customer standing committee” and the “periodic review team”? While I can understand why, e.g., a civil society advocate might be extremely interested in whether IANA is not implementing policies that were passed, or implementing policies that were not accepted (these are accountability issues, not performance issues). But I do not understand what role a digital rights advocate or an intellectual property lawyer would play, say, in assessing the accuracy and security of a TLD operator’s root zone file modifications or interactions with the IANA.
Note that the 'periodic review team' is also responsible for the contracting functions in addition to overall/higher-level performance review of IANA. I hope you at least agree that the contracting function (issuing a new contract, terminating an existing contract etc) will require a multi-stakeholder composition. The periodic review team is not supposed to be responsible for day-to-day review which is of a operational/technical nature.
4. Accountability and true separability (both of which are recognized principles of this group) requires a periodic renewal of the contract in which there is no “presumption of renewal” and a willingness to entertain other providers of the functions. Periodicity minimizes the friction associated with reviews and with moving the contract by clarifying expectations well in advance. Periodicity is NOT inimical to continuity or to long-term investment by a well-behaved provider that satisfies its customers. The flow chart seems to contain a much weaker – and to me, unacceptable – concept of a “periodic review team” which is merely there to advise the incumbent contractor on how to improve service, just as the current ATRT merely advises ICANN on how to improve. Let me flag this as a deal-breaking issue for me and, I think, many others. If you want consensus this will have to be significantly changed.
'Period review team' can not only review, but also pull the plug on the contract in response to the review. As of now, the decision of determining the nature of the contract has been left to the 'periodic review team'. They will later determine the duration of the contract, whether there will be a presumption of renewal etc. There was also a concerted effort at the Frankfurt meeting to have the term "RFP" removed from the flow chart for explaining the contracting process. While I quite like the rest of the proposal, I agree with you that this aspect needs to be changed significantly in line with what you are suggesting. There needs to be (i) a limited term for the contract; (ii) an open beauty contest; and (iii) no presumption of renewal. If determining the nature of the contract is left entirely to the periodic review team, then I fear that this team might give the contract to ICANN in perpetuity given that the periodic review team is essentially derived from ICANN structures (SO/AC). I see a conflict of interest in this.
Milton (& CWG members and participants), Apologies for the relatively slow turnaround on responding to your questions which do seek to create a better sense of the meeting for all who were not present or unable to participate in full. Lise & I have now talked and would like to assist with some thoughts relating to the points / questions and have included input in-line below. I trust that you will find these useful and hope that the time taken to respond will not mean the input is too out of synch with other related discussions. Thanks, Jonathan and Lise From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 22 November 2014 17:26 To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Comments on IANA Transition Flow Chart Hello all, As someone who was not at the Frankfurt meeting I am trying to make sense of this 'flow chart.' As far as I can tell, this is a proposal - a response to RFP section 3 - in the simplified form of a 'flow chart.' This does provide an overall view of what is being proposed with visual simplicity, but leaves unanswered many critical questions that would have to be dealt with before we can bring it back to our communities for evaluation and assessment of its acceptability. Here are my questions: 1, Who or what is the IANA contracting entity? Is it inside ICANN or outside of ICANN? (Hint: it had better be outside if this idea is to conform to the principles of separability and accountability.) How is it governed? An independent incorporated entity (i.e., outside of ICANN). Its only purpose is to enter into the contract with ICANN. It will be governed by the multistakeholder community, (including but not limited to the ICANN multistakeholder community); details are TBD. It is expected that this entity would have no staff. 2. Who is the "periodic review team"? Is it inside ICANN or outside of ICANN? How is it formed? Why is it different from the contracting authority; i.e., what is its legal or organizational relationship to the contracting authority? The review team is a formal group arising from the multistakeholder community that will be selected to oversee these processes, serve as a "path of escalation" for the customer standing committee, and give instructions to the contracting entity. How members from this group are to be selected is TBD for the moment but the objectives are (1) that it be adequately representative of the communities and (2) these are not paid positions. It is likely that existing ICANN structures would be used to organize the review team and the customer committee, with safeguards to ensure their independence. 3. I understand 'performance review' to be a fairly narrow assessment of how well the IANA performs its specified technical functions. If so, why is there a distinction between a "customer standing committee" and the "periodic review team"? While I can understand why, e.g., a civil society advocate might be extremely interested in whether IANA is not implementing policies that were passed, or implementing policies that were not accepted (these are accountability issues, not performance issues). But I do not understand what role a digital rights advocate or an intellectual property lawyer would play, say, in assessing the accuracy and security of a TLD operator's root zone file modifications or interactions with the IANA. The customer standing committee is expected to be mostly made up of a limited number of registry representatives, potentially with liaisons from other stakeholder groups. The work of the customer committee is expected to be mostly accepting and reviewing IANA reports on performance, ensuring they are as requested, identifying any performance issues, assessing if they are significant or not and escalating significant issues to the review team. Also, producing an annual analysis of IANA performance for the public and the review team. Again no paid positions and everything this committee does should be completely open and transparent (essentially administrative mechanics). 4. Accountability and true separability (both of which are recognized principles of this group) requires a periodic renewal of the contract in which there is no "presumption of renewal" and a willingness to entertain other providers of the functions. Periodicity minimizes the friction associated with reviews and with moving the contract by clarifying expectations well in advance. Periodicity is NOT inimical to continuity or to long-term investment by a well-behaved provider that satisfies its customers. The flow chart seems to contain a much weaker - and to me, unacceptable - concept of a "periodic review team" which is merely there to advise the incumbent contractor on how to improve service, just as the current ATRT merely advises ICANN on how to improve. Let me flag this as a deal-breaking issue for me and, I think, many others. If you want consensus this will have to be significantly changed. Because the "flow chart" focused on groups to perform certain functions, it did not set out particular detail on the contract post-transition. The review team is not an alternative to a contract of limited duration. The sense of the room seemed to be "don't fix it if it ain't broke'. In that context, it should be noted that the current contract is for a limited duration and thus it is anticipated that the next one will be as well. That being said, there are no provisions currently envisioned which block the periodic review team from deciding whatever it thinks is best at the end of the initial term of the first post-transition agreement. 5. Happy to see a binding, independent appeals process in there. But could someone tell me more detail what kind of appeals pertaining to policy implementation you had in mind? Hopefully this would not be a way for people who did not get what they wanted from the policy process to circumvent agreed policy by going after IANA implementation, but would instead be an avenue for people to challenge unauthorized or incorrect IANA implementations? The details are to be determined. Your second sentence accurately summarizes the "sense of the room" on the scope (and limitation of scope) for appeals. I have other questions, but these are the big ones. Let me add that based on what I have heard from various stakeholders who were in Frankfurt, that while progress was made many key people were absent, there was little feeling of consensus on key ideas and that we are still talking more about details than an acceptable approach to the whole solution. Therefore, a lot of discussion and modification of the proposal/'flow chart' will have to take place on this list. We would not characterise the meeting or participation, or the outcome, in those terms. We can provide the information on participation in person and from remote locations if desired. We would say that significant progress was made toward a holistic solution, that both participation and representation were broad and strong, and that there was a sense of convergence from much of the group on key ideas. That in no way minimises the significant amount of work still to be done, including work on developing consensus. It should be emphasised that no one has signed off on anything except a concept to get an initial version of a proposal completed for approval by the CWG, which needs to be published on 1 December. It is further expected that this solution framework will not be extremely detailed, but will be enough for serious consideration, due to time and an expectation that the results of our consultation could have a significant impact on the workings of the proposal. --MM
Hi all, To follow up on our Chairs' note about attendance at the F2F meeting, here are some statistics: * All but one of the 19 members participated in the meeting either in person or remotely (Fouad Bajwa did not participate, but he had Alan Greenberg representing him in person an an alternate) * 40 participants joined the meeting which is our average attendance per regular meeting as well * Of the 40 participants, 12 attended in person Also, I've updated the attendance log for the full CWG meetings: https://community.icann.org/x/ET3xAg. Best, Grace From: Jonathan Robinson <jrobinson@afilias.info> Organization: Afilias Reply-To: Jonathan Robinson <jrobinson@afilias.info> Date: Tuesday, November 25, 2014 12:24 PM To: 'Milton L Mueller' <mueller@syr.edu>, "cwg-stewardship@icann.org" <cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Comments on IANA Transition Flow Chart Milton (& CWG members and participants), Apologies for the relatively slow turnaround on responding to your questions which do seek to create a better sense of the meeting for all who were not present or unable to participate in full. Lise & I have now talked and would like to assist with some thoughts relating to the points / questions and have included input in-line below. I trust that you will find these useful and hope that the time taken to respond will not mean the input is too out of synch with other related discussions. Thanks, Jonathan and Lise From: Milton L Mueller [mailto:mueller@syr.edu] Sent: 22 November 2014 17:26 To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Comments on IANA Transition Flow Chart Hello all, As someone who was not at the Frankfurt meeting I am trying to make sense of this flow chart.¹ As far as I can tell, this is a proposal a response to RFP section 3 in the simplified form of a flow chart.¹ This does provide an overall view of what is being proposed with visual simplicity, but leaves unanswered many critical questions that would have to be dealt with before we can bring it back to our communities for evaluation and assessment of its acceptability. Here are my questions: 1, Who or what is the IANA contracting entity? Is it inside ICANN or outside of ICANN? (Hint: it had better be outside if this idea is to conform to the principles of separability and accountability.) How is it governed? An independent incorporated entity (i.e., outside of ICANN). Its only purpose is to enter into the contract with ICANN. It will be governed by the multistakeholder community, (including but not limited to the ICANN multistakeholder community); details are TBD. It is expected that this entity would have no staff. 2. Who is the ³periodic review team²? Is it inside ICANN or outside of ICANN? How is it formed? Why is it different from the contracting authority; i.e., what is its legal or organizational relationship to the contracting authority? The review team is a formal group arising from the multistakeholder community that will be selected to oversee these processes, serve as a "path of escalation" for the customer standing committee, and give instructions to the contracting entity. How members from this group are to be selected is TBD for the moment but the objectives are (1) that it be adequately representative of the communities and (2) these are not paid positions. It is likely that existing ICANN structures would be used to organize the review team and the customer committee, with safeguards to ensure their independence. 3. I understand performance review¹ to be a fairly narrow assessment of how well the IANA performs its specified technical functions. If so, why is there a distinction between a ³customer standing committee² and the ³periodic review team²? While I can understand why, e.g., a civil society advocate might be extremely interested in whether IANA is not implementing policies that were passed, or implementing policies that were not accepted (these are accountability issues, not performance issues). But I do not understand what role a digital rights advocate or an intellectual property lawyer would play, say, in assessing the accuracy and security of a TLD operator¹s root zone file modifications or interactions with the IANA. The customer standing committee is expected to be mostly made up of a limited number of registry representatives, potentially with liaisons from other stakeholder groups. The work of the customer committee is expected to be mostly accepting and reviewing IANA reports on performance, ensuring they are as requested, identifying any performance issues, assessing if they are significant or not and escalating significant issues to the review team. Also, producing an annual analysis of IANA performance for the public and the review team. Again no paid positions and everything this committee does should be completely open and transparent (essentially administrative mechanics). 4. Accountability and true separability (both of which are recognized principles of this group) requires a periodic renewal of the contract in which there is no ³presumption of renewal² and a willingness to entertain other providers of the functions. Periodicity minimizes the friction associated with reviews and with moving the contract by clarifying expectations well in advance. Periodicity is NOT inimical to continuity or to long-term investment by a well-behaved provider that satisfies its customers. The flow chart seems to contain a much weaker and to me, unacceptable concept of a ³periodic review team² which is merely there to advise the incumbent contractor on how to improve service, just as the current ATRT merely advises ICANN on how to improve. Let me flag this as a deal-breaking issue for me and, I think, many others. If you want consensus this will have to be significantly changed. Because the "flow chart" focused on groups to perform certain functions, it did not set out particular detail on the contract post-transition. The review team is not an alternative to a contract of limited duration. The sense of the room seemed to be "don't fix it if it ain't broke'. In that context, it should be noted that the current contract is for a limited duration and thus it is anticipated that the next one will be as well. That being said, there are no provisions currently envisioned which block the periodic review team from deciding whatever it thinks is best at the end of the initial term of the first post-transition agreement. 5. Happy to see a binding, independent appeals process in there. But could someone tell me more detail what kind of appeals pertaining to policy implementation you had in mind? Hopefully this would not be a way for people who did not get what they wanted from the policy process to circumvent agreed policy by going after IANA implementation, but would instead be an avenue for people to challenge unauthorized or incorrect IANA implementations? The details are to be determined. Your second sentence accurately summarizes the "sense of the room" on the scope (and limitation of scope) for appeals. I have other questions, but these are the big ones. Let me add that based on what I have heard from various stakeholders who were in Frankfurt, that while progress was made many key people were absent, there was little feeling of consensus on key ideas and that we are still talking more about details than an acceptable approach to the whole solution. Therefore, a lot of discussion and modification of the proposal/¹flow chart¹ will have to take place on this list. We would not characterise the meeting or participation, or the outcome, in those terms. We can provide the information on participation in person and from remote locations if desired. We would say that significant progress was made toward a holistic solution, that both participation and representation were broad and strong, and that there was a sense of convergence from much of the group on key ideas. That in no way minimises the significant amount of work still to be done, including work on developing consensus. It should be emphasised that no one has signed off on anything except a concept to get an initial version of a proposal completed for approval by the CWG, which needs to be published on 1 December. It is further expected that this solution framework will not be extremely detailed, but will be enough for serious consideration, due to time and an expectation that the results of our consultation could have a significant impact on the workings of the proposal. --MM
participants (6)
-
Gomes, Chuck -
Grace Abuhamad -
Guru Acharya -
Jonathan Robinson -
Marika Konings -
Milton L Mueller