Notes, Recordings, Transcript CWG IANA #22 19 FEB
Dear all, The notes, recordings and transcripts for the CWG IANA Call #22 on 19 February will be available here: https://community.icann.org/pages/viewpage.action?pageId=52889142 Action Items: Action: members should send reminders to their communities (participants may do so as well). Note extended deadline to 18:00 UTC on Monday 23 February. Reference announcement: <https://www.icann.org/news/announcement-2015-02-06-en> https://www.icann.org/news/announcement-2015-02-06-en Action: Berry will make a full table of all the answers to questions after Monday Action: Staff to look at rotating timezones for the calls (at the very least accommodating members) Action: Bernie to do comprehensive review of documents and to use new terminology (Design Teams) Action: All to propose tightly specified DTs on CWG list and start to build those out with leads Action: Bernie to produce backbone Proposal document Action: Martin/Lise to finalize Principles document within next two weeks Notes 19/2: Chuck Gomes on audio only 1. Opening Remarks * 22nd meeting -- wow! * 2 proposals have been submitted to ICG * Need to make (and be seen to make) progress towards a proposal * Wednesday session at ICANN52 * Thursday session went into more substance * Overall we committed to a refreshed approach * Meetings will be focused on committees of the whole as well as task forces meetings * Measure your participation by joining two meetings per week if possible 2. Processing ICANN52 * Staff has pulled feedback from transcripts. Meant as reference point for the work moving forward. * Link to Google Doc is here: <https://docs.google.com/document/d/1Me5cYBNX5XfMha2Bl4JhMXiPbvEyo8IlSAaflDsK...> https://docs.google.com/document/d/1Me5cYBNX5XfMha2Bl4JhMXiPbvEyo8IlSAaflDsK... * Berry has taken the feedback doc one step further by focusing in on the Q&A session in an attempt to analyze feedback * Feedback will be accepted through the end of the week either via CWG member/participant or through staff (Grace). * Yes, written responses should be added * Yes, reminders should be sent out * Extended deadline to 18:00 UTC on Monday 23 February * Input should be representative of members' organizations where possible (clarification otherwise) * Made the questions available for broad input (including SO/ACs). Views are not required per se, but welcome. Action: members should send reminders to their communities (participants may do so as well). Note extended deadline to 18:00 UTC on Monday 23 February. Reference announcement: <https://www.icann.org/news/announcement-2015-02-06-en> https://www.icann.org/news/announcement-2015-02-06-en Action: Berry will make a full table of all the answers to questions after Monday 3. Work of Client Committee / Legal Advice * Another Client Committee call planned for tomorrow * 6 firms on shortlist but at least one may drop off due to conflict of interest * Will need to discuss how to manage relationships between CWG, CCWG and ICANN * Greg has been participating in the CCWG legal group so that there is coordination and possibly a joint decision on a firm * Conflict of interest rules are standards ethics rules. Examples include a law firm that represents a counterparty to an * ICANN suit. Most law firms have a specialist lawyer who determines conflict for the firm. * Will have advice by F2F, but perhaps not full-fledged report. 4. Work Methods * Objective is to make progress while waiting for legal advice * Task Forces should be small groups of qualified people (relevant expertise + time to commit) * Two options for task force "membership" * a)- allow non-CWG people to join but Task Forces should be lead by CWG participant/members (majority should be CWG) * b)- require joining as participant even though we recognize that they will not participate fully * Suggestion that non CWG submit SOIs for participation * Willing to have calls twice per week (24 respondents -- 20 in favor and 4 against) * 2 calls per week in addition to any Task Force work Action: Staff to look at rotating timezones for the calls (at the very least accommodating members) 5. Task Forces/ Design Teams * Guidelines presented by Bernard Turcotte * These need to be manageable, small groups, that don't absorb all resources into one group. * Use the word Design Team (IETF style) moving forward * Any given DT should be linked to the Proposal so that the relevance to the work is clear * Start with clean slate for proposed DTs * The ability to separate (worst case scenario) is not the sole subject of this proposal Action: Bernie to do comprehensive review of documents and to use new terminology (Design Teams) Action: All to propose tightly specified DTs on CWG list and start to build those out with leads 6. Future Work * Meeting schedule was addressed earlier in the call. * Timeline will be adjusted as we settle into DT work (no more RFP subgroup bars) * F2F dates were arranged around project plan -- 26-27 March 7. CCWG-Accountability * Chairs have coordination call on Friday 8. Review of Action Items Action: members should send reminders to their communities (participants may do so as well). Note extended deadline to 18:00 UTC on Monday 23 February. Reference announcement: <https://www.icann.org/news/announcement-2015-02-06-en> https://www.icann.org/news/announcement-2015-02-06-en Action: Berry will make a full table of all the answers to questions after Monday Action: Staff to look at rotating timezones for the calls (at the very least accommodating members) Action: Bernie to do comprehensive review of documents and to use new terminology (Design Teams) Action: All to propose tightly specified DTs on CWG list and start to build those out with leads Action: Bernie to produce backbone Proposal document Action: Martin/Lise to finalize Principles document within next two weeks 9. AOB * F2F location has not yet been finalized * Avri raises "integrated model" and notes that comments are still open
All, Please note that the deadline to submit responses to the 9 Questions from the CWG Thursday Q&A Session is now 23:59 on 23 Feb 2015. Please send responses to the list and I will incorporate the responses into the master document. Title the subject of the email "Singapore Thursday Q&A Session Input". Thank you. B Berry A. Cobb Internet Corporation for Assigned Names & Numbers 720.839.5735 <mailto:mail@berrycobb.com> mail@berrycobb.com @berrycobb From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Brenda Brewer Sent: Thursday, February 19, 2015 07:04 To: cwg-stewardship@icann.org Subject: [CWG-Stewardship] Notes, Recordings, Transcript CWG IANA #22 19 FEB Dear all, The notes, recordings and transcripts for the CWG IANA Call #22 on 19 February will be available here: https://community.icann.org/pages/viewpage.action?pageId=52889142 Action Items: Action: members should send reminders to their communities (participants may do so as well). Note extended deadline to 18:00 UTC on Monday 23 February. Reference announcement: <https://www.icann.org/news/announcement-2015-02-06-en> https://www.icann.org/news/announcement-2015-02-06-en Action: Berry will make a full table of all the answers to questions after Monday Action: Staff to look at rotating timezones for the calls (at the very least accommodating members) Action: Bernie to do comprehensive review of documents and to use new terminology (Design Teams) Action: All to propose tightly specified DTs on CWG list and start to build those out with leads Action: Bernie to produce backbone Proposal document Action: Martin/Lise to finalize Principles document within next two weeks Notes 19/2: Chuck Gomes on audio only 1. Opening Remarks . 22nd meeting -- wow! . 2 proposals have been submitted to ICG . Need to make (and be seen to make) progress towards a proposal . Wednesday session at ICANN52 . Thursday session went into more substance . Overall we committed to a refreshed approach . Meetings will be focused on committees of the whole as well as task forces meetings . Measure your participation by joining two meetings per week if possible 2. Processing ICANN52 . Staff has pulled feedback from transcripts. Meant as reference point for the work moving forward. . Link to Google Doc is here: <https://docs.google.com/document/d/1Me5cYBNX5XfMha2Bl4JhMXiPbvEyo8IlSAaflDs K25I/edit?usp=sharing> https://docs.google.com/document/d/1Me5cYBNX5XfMha2Bl4JhMXiPbvEyo8IlSAaflDsK 25I/edit?usp=sharing . Berry has taken the feedback doc one step further by focusing in on the Q&A session in an attempt to analyze feedback . Feedback will be accepted through the end of the week either via CWG member/participant or through staff (Grace). . Yes, written responses should be added . Yes, reminders should be sent out . Extended deadline to 18:00 UTC on Monday 23 February . Input should be representative of members' organizations where possible (clarification otherwise) . Made the questions available for broad input (including SO/ACs). Views are not required per se, but welcome. Action: members should send reminders to their communities (participants may do so as well). Note extended deadline to 18:00 UTC on Monday 23 February. Reference announcement: <https://www.icann.org/news/announcement-2015-02-06-en> https://www.icann.org/news/announcement-2015-02-06-en Action: Berry will make a full table of all the answers to questions after Monday 3. Work of Client Committee / Legal Advice . Another Client Committee call planned for tomorrow . 6 firms on shortlist but at least one may drop off due to conflict of interest . Will need to discuss how to manage relationships between CWG, CCWG and ICANN . Greg has been participating in the CCWG legal group so that there is coordination and possibly a joint decision on a firm . Conflict of interest rules are standards ethics rules. Examples include a law firm that represents a counterparty to an . ICANN suit. Most law firms have a specialist lawyer who determines conflict for the firm. . Will have advice by F2F, but perhaps not full-fledged report. 4. Work Methods . Objective is to make progress while waiting for legal advice . Task Forces should be small groups of qualified people (relevant expertise + time to commit) . Two options for task force "membership" . a)- allow non-CWG people to join but Task Forces should be lead by CWG participant/members (majority should be CWG) . b)- require joining as participant even though we recognize that they will not participate fully . Suggestion that non CWG submit SOIs for participation . Willing to have calls twice per week (24 respondents -- 20 in favor and 4 against) . 2 calls per week in addition to any Task Force work Action: Staff to look at rotating timezones for the calls (at the very least accommodating members) 5. Task Forces/ Design Teams . Guidelines presented by Bernard Turcotte . These need to be manageable, small groups, that don't absorb all resources into one group. . Use the word Design Team (IETF style) moving forward . Any given DT should be linked to the Proposal so that the relevance to the work is clear . Start with clean slate for proposed DTs . The ability to separate (worst case scenario) is not the sole subject of this proposal Action: Bernie to do comprehensive review of documents and to use new terminology (Design Teams) Action: All to propose tightly specified DTs on CWG list and start to build those out with leads 6. Future Work . Meeting schedule was addressed earlier in the call. . Timeline will be adjusted as we settle into DT work (no more RFP subgroup bars) . F2F dates were arranged around project plan -- 26-27 March 7. CCWG-Accountability . Chairs have coordination call on Friday 8. Review of Action Items Action: members should send reminders to their communities (participants may do so as well). Note extended deadline to 18:00 UTC on Monday 23 February. Reference announcement: <https://www.icann.org/news/announcement-2015-02-06-en> https://www.icann.org/news/announcement-2015-02-06-en Action: Berry will make a full table of all the answers to questions after Monday Action: Staff to look at rotating timezones for the calls (at the very least accommodating members) Action: Bernie to do comprehensive review of documents and to use new terminology (Design Teams) Action: All to propose tightly specified DTs on CWG list and start to build those out with leads Action: Bernie to produce backbone Proposal document Action: Martin/Lise to finalize Principles document within next two weeks 9. AOB . F2F location has not yet been finalized . Avri raises "integrated model" and notes that comments are still open
Hi Berry, hi all, Nominet, the .uk domain name registry has worked through the nine questions and our views are covered in the attached. (Sorry, no pdf.) I hope this helps, Martin From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Berry Cobb Sent: 19 February 2015 14:52 To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Notes, Recordings, Transcript CWG IANA #22 19 FEB All, Please note that the deadline to submit responses to the 9 Questions from the CWG Thursday Q&A Session is now 23:59 on 23 Feb 2015. Please send responses to the list and I will incorporate the responses into the master document. Title the subject of the email "Singapore Thursday Q&A Session Input". Thank you. B Berry A. Cobb Internet Corporation for Assigned Names & Numbers 720.839.5735 mail@berrycobb.com<mailto:mail@berrycobb.com> @berrycobb
On the SSAC mail list I pointed out this request for input and got a personal reaction. So do note, this is not a a reaction from SSAC as group, just from an individual member of SSAC. Nevertheless, I found int intersting enough to forward. jaap ----
* Do you believe that the transition from the NTIA should happen (Please provide the reasons for your answer)?
Yes, because it is important IANA function oversight is moved from US Government to the communities that do set the policies by which IANA operates.
* Are you comfortable with ICANN as policy-maker also being the IANA operator without the benefit of external oversight?
Impossible to answer as "ICANN" is not specified well enough. I am comfortable with ICANN ccNSO and gNSO being policy makers while the IANA Function at ICANN Corporation is implementing the policy developed by the PDPs.
* Should registries, as the primary customers of the IANA functions, have more of a say as to which transition proposal is acceptable?
The registries are not the primary customers of the IANA functions. The IANA functions include many other things like IP Addresses, Protocol Parameters etc. The balance in who has what say regarding instructions to IANA should be set by the design of the PDPs that control the IANA functions which include ccNSO and gNSO.
* What does functional separation of IANA from ICANN mean to you? (this is not referring to having another operator than ICANN performing the IANA functions but rather the internal separation between ICANN and IANA in the context where ICANN is the IANA operator)
First of all, there are already other organizations providing functions that IANA Function at ICANN could do (RIPE NCC for E.164 numbers for example). Internal separation is only needed in the cases the PDPs do not create clear enough instructions to what IANA is to make. People participating do mix up ICANN decisions (on who can be registry for a specific TLD for example) with IANA actions (to take instructions and otherwise communicate with the registries). So, I view the need for separation collapse into need for the PDPs to: 1. specifically produce instructions for IANA 2. explicitly validate that IANA is following the instructions
* In considering the key factors (such as security and stability, ease of separating the IANA function from ICANN, quality of services, accountability mechanisms etc.) for evaluating the various transition proposals what importance would you give to the ability to separate IANA from ICANN (separability) vs. the other factors?
If the IANA Function of ICANN is not following the instructions then an RFP must be filed for a separate group following those instructions. ICANN have already demonstrated such RFP can be hosted, run and affected for the ICG Secretariat that is now independent and separated from ICANN. Don't forget the financing of IANA and other bodies people ask for.
* Given the IANA functions could be separated from ICANN do you believe it would be important for the community to obtain from ICANN on an annual basis the costs for operating IANA including overhead costs?
The PDP should decide what the rules for IANA should be, and if needed also who should take care of it. As part of that is also of course financing issues. Regarding separation, as long as ICANN is financing, there is no real separation. So, if the PDP want someone else than ICANN to run IANA, then the PDP must also be able to find money for the operation.
* Would it be important to separate out the costs associated with address and protocol functions?
If RIRs or IETF want to move the functions, then of course IETF and RIR have to find financing of the (new) operator for that coordination. ICANN have nothing to do with it. Today ICANN have agreed to finance the IANA Function as long as it is hosted at ICANN. That in turn might be a reason for (for example) RIRs to donate money to ICANN, and for Registry operators of TLDs to do the same.
* Could there be unforeseen impacts relative to selecting a new operator for the IANA functions vs the ICANN policy role (should ICANN determine that there will be another round of new gTLDs, how could it ensure that the new operator would accept this)?
Once again, it is only possible to talk about this if one talk about the role of the PDPs. Not just say "ICANN".
* Are there other transition models which the CWG should be exploring?
It must be much more clear what the role of the PDPs ccNSO and gNSO have to be able to do further evaluation, but in short I think better steps forward include: A. Have the PDPs explicitly be the creators of instructions to IANA, and create interaction between the PDPs and IANA similar to the interaction IETF have. Specifically separate the IANA instructions from the rules for (for example) new TLDs. B. Have GAC be responsible for finding a permanent solution for the .INT TLD based on the existing rules (RFC 1591 minus the international database). C. Have ccNSO resolve the issues with ccTLD delegation/redelegation. D. Have ICANN bylaws or otherwise be changed to ensure the power stays with the PDPs.
Jaap, It is not clear to me that what is meant by PDPs in the following. In my mind PDP = policy development process but the way it is used below sometimes doesn't make sense if I use that definition. Chuck -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Jaap Akkerhuis Sent: Monday, February 23, 2015 9:01 AM To: Berry Cobb; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Singapore Thursday Q&A Session Input On the SSAC mail list I pointed out this request for input and got a personal reaction. So do note, this is not a a reaction from SSAC as group, just from an individual member of SSAC. Nevertheless, I found int intersting enough to forward. jaap ----
* Do you believe that the transition from the NTIA should happen (Please provide the reasons for your answer)?
Yes, because it is important IANA function oversight is moved from US Government to the communities that do set the policies by which IANA operates.
* Are you comfortable with ICANN as policy-maker also being the IANA operator without the benefit of external oversight?
Impossible to answer as "ICANN" is not specified well enough. I am comfortable with ICANN ccNSO and gNSO being policy makers while the IANA Function at ICANN Corporation is implementing the policy developed by the PDPs.
* Should registries, as the primary customers of the IANA functions, have more of a say as to which transition proposal is acceptable?
The registries are not the primary customers of the IANA functions. The IANA functions include many other things like IP Addresses, Protocol Parameters etc. The balance in who has what say regarding instructions to IANA should be set by the design of the PDPs that control the IANA functions which include ccNSO and gNSO.
* What does functional separation of IANA from ICANN mean to you? (this is not referring to having another operator than ICANN performing the IANA functions but rather the internal separation between ICANN and IANA in the context where ICANN is the IANA operator)
First of all, there are already other organizations providing functions that IANA Function at ICANN could do (RIPE NCC for E.164 numbers for example). Internal separation is only needed in the cases the PDPs do not create clear enough instructions to what IANA is to make. People participating do mix up ICANN decisions (on who can be registry for a specific TLD for example) with IANA actions (to take instructions and otherwise communicate with the registries). So, I view the need for separation collapse into need for the PDPs to: 1. specifically produce instructions for IANA 2. explicitly validate that IANA is following the instructions
* In considering the key factors (such as security and stability, ease of separating the IANA function from ICANN, quality of services, accountability mechanisms etc.) for evaluating the various transition proposals what importance would you give to the ability to separate IANA from ICANN (separability) vs. the other factors?
If the IANA Function of ICANN is not following the instructions then an RFP must be filed for a separate group following those instructions. ICANN have already demonstrated such RFP can be hosted, run and affected for the ICG Secretariat that is now independent and separated from ICANN. Don't forget the financing of IANA and other bodies people ask for.
* Given the IANA functions could be separated from ICANN do you believe it would be important for the community to obtain from ICANN on an annual basis the costs for operating IANA including overhead costs?
The PDP should decide what the rules for IANA should be, and if needed also who should take care of it. As part of that is also of course financing issues. Regarding separation, as long as ICANN is financing, there is no real separation. So, if the PDP want someone else than ICANN to run IANA, then the PDP must also be able to find money for the operation.
* Would it be important to separate out the costs associated with address and protocol functions?
If RIRs or IETF want to move the functions, then of course IETF and RIR have to find financing of the (new) operator for that coordination. ICANN have nothing to do with it. Today ICANN have agreed to finance the IANA Function as long as it is hosted at ICANN. That in turn might be a reason for (for example) RIRs to donate money to ICANN, and for Registry operators of TLDs to do the same.
* Could there be unforeseen impacts relative to selecting a new operator for the IANA functions vs the ICANN policy role (should ICANN determine that there will be another round of new gTLDs, how could it ensure that the new operator would accept this)?
Once again, it is only possible to talk about this if one talk about the role of the PDPs. Not just say "ICANN".
* Are there other transition models which the CWG should be exploring?
It must be much more clear what the role of the PDPs ccNSO and gNSO have to be able to do further evaluation, but in short I think better steps forward include: A. Have the PDPs explicitly be the creators of instructions to IANA, and create interaction between the PDPs and IANA similar to the interaction IETF have. Specifically separate the IANA instructions from the rules for (for example) new TLDs. B. Have GAC be responsible for finding a permanent solution for the .INT TLD based on the existing rules (RFC 1591 minus the international database). C. Have ccNSO resolve the issues with ccTLD delegation/redelegation. D. Have ICANN bylaws or otherwise be changed to ensure the power stays with the PDPs. _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
"Gomes, Chuck" writes:
Jaap,
It is not clear to me that what is meant by PDPs in the following. In my mind PDP = policy development process but the way it is used below sometimes doesn't make sense if I use that definition.
As far as I understand "PDP = policy development process" is what is meant. Berry requested in a private mail whether it could be let known whom is the author of this note. It turns out it is actually a collective reaction from a couple of SSAC people and should be earmarked as "informal reaction" from SSAC. Since I wasn't part in creating the mails (I only forwarded it), I suggest that if you want more details, you contact the chair of the SSAC, Patrik Fältström <patrik@frobbit.se>. Regards, jaap
Chuck
-----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Jaap Akkerhuis Sent: Monday, February 23, 2015 9:01 AM To: Berry Cobb; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Singapore Thursday Q&A Session Input
On the SSAC mail list I pointed out this request for input and got a personal reaction. So do note, this is not a a reaction from SSAC as group, just from an individual member of SSAC.
Nevertheless, I found int intersting enough to forward.
jaap
----
* Do you believe that the transition from the NTIA should happen (Please provide the reasons for your answer)?
Yes, because it is important IANA function oversight is moved from US Government to the communities that do set the policies by which IANA operates.
* Are you comfortable with ICANN as policy-maker also being the IANA operator without the benefit of external oversight?
Impossible to answer as "ICANN" is not specified well enough.
I am comfortable with ICANN ccNSO and gNSO being policy makers while the IANA Function at ICANN Corporation is implementing the policy developed by the PDPs.
* Should registries, as the primary customers of the IANA functions, have more of a say as to which transition proposal is acceptable?
The registries are not the primary customers of the IANA functions. The IANA functions include many other things like IP Addresses, Protocol Parameters etc.
The balance in who has what say regarding instructions to IANA should be set by the design of the PDPs that control the IANA functions which include ccNSO and gNSO.
* What does functional separation of IANA from ICANN mean to you? (this is not referring to having another operator than ICANN performing the IANA functions but rather the internal separation between ICANN and IANA in the context where ICANN is the IANA operator)
First of all, there are already other organizations providing functions that IANA Function at ICANN could do (RIPE NCC for E.164 numbers for example).
Internal separation is only needed in the cases the PDPs do not create clear enough instructions to what IANA is to make. People participating do mix up ICANN decisions (on who can be registry for a specific TLD for example) with IANA actions (to take instructions and otherwise communicate with the registries).
So, I view the need for separation collapse into need for the PDPs to:
1. specifically produce instructions for IANA 2. explicitly validate that IANA is following the instructions
* In considering the key factors (such as security and stability, ease of separating the IANA function from ICANN, quality of services, accountability mechanisms etc.) for evaluating the various transition proposals what importance would you give to the ability to separate IANA from ICANN (separability) vs. the other factors?
If the IANA Function of ICANN is not following the instructions then an RFP must be filed for a separate group following those instructions. ICANN have already demonstrated such RFP can be hosted, run and affected for the ICG Secretariat that is now independent and separated from ICANN.
Don't forget the financing of IANA and other bodies people ask for.
* Given the IANA functions could be separated from ICANN do you believe it would be important for the community to obtain from ICANN on an annual basis the costs for operating IANA including overhead costs?
The PDP should decide what the rules for IANA should be, and if needed also who should take care of it. As part of that is also of course financing issues.
Regarding separation, as long as ICANN is financing, there is no real separation.
So, if the PDP want someone else than ICANN to run IANA, then the PDP must also be able to find money for the operation.
* Would it be important to separate out the costs associated with address and protocol functions?
If RIRs or IETF want to move the functions, then of course IETF and RIR have to find financing of the (new) operator for that coordination. ICANN have nothing to do with it.
Today ICANN have agreed to finance the IANA Function as long as it is hosted at ICANN. That in turn might be a reason for (for example) RIRs to donate money to ICANN, and for Registry operators of TLDs to do the same.
* Could there be unforeseen impacts relative to selecting a new operator for the IANA functions vs the ICANN policy role (should ICANN determine that there will be another round of new gTLDs, how could it ensure that the new operator would accept this)?
Once again, it is only possible to talk about this if one talk about the role of the PDPs. Not just say "ICANN".
* Are there other transition models which the CWG should be exploring?
It must be much more clear what the role of the PDPs ccNSO and gNSO have to be able to do further evaluation, but in short I think better steps forward include:
A. Have the PDPs explicitly be the creators of instructions to IANA, and create interaction between the PDPs and IANA similar to the interaction IETF have. Specifically separate the IANA instructions from the rules for (for example) new TLDs.
B. Have GAC be responsible for finding a permanent solution for the .INT TLD based on the existing rules (RFC 1591 minus the international database).
C. Have ccNSO resolve the issues with ccTLD delegation/redelegation.
D. Have ICANN bylaws or otherwise be changed to ensure the power stays with the PDPs.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Jaap, I have updated the PDF to reflect "Informal SSAC Response" instead of your name directly for the Thursday Q&A Session responses. I still await the ccTLD designations. https://community.icann.org/download/attachments/49351404/CWG_Thurs_Session_... Thank you. B Berry A. Cobb Internet Corporation for Assigned Names & Numbers 720.839.5735 mail@berrycobb.com @berrycobb -----Original Message----- From: Jaap Akkerhuis [mailto:jaap@NLnetLabs.nl] Sent: Monday, March 9, 2015 05:55 To: Gomes, Chuck Cc: Berry Cobb; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Singapore Thursday Q&A Session Input "Gomes, Chuck" writes:
Jaap,
It is not clear to me that what is meant by PDPs in the following. In my mind PDP = policy development process but the way it is used below sometimes doesn't make sense if I use that definition.
As far as I understand "PDP = policy development process" is what is meant. Berry requested in a private mail whether it could be let known whom is the author of this note. It turns out it is actually a collective reaction from a couple of SSAC people and should be earmarked as "informal reaction" from SSAC. Since I wasn't part in creating the mails (I only forwarded it), I suggest that if you want more details, you contact the chair of the SSAC, Patrik Fältström <patrik@frobbit.se>. Regards, jaap
Chuck
-----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Jaap Akkerhuis > Sent: Monday, February 23, 2015 9:01 AM > To: Berry Cobb; cwg-stewardship@icann.org > Subject: Re: [CWG-Stewardship] Singapore Thursday Q&A Session Input > > On the SSAC mail list I pointed out this request for input and got a personal reaction. So do note, this is not a a reaction from SSAC as group, just from an individual member of SSAC.
Nevertheless, I found int intersting enough to forward.
jaap
----
* Do you believe that the transition from the NTIA should happen (Please provide the reasons for your answer)?
Yes, because it is important IANA function oversight is moved from US Government to the communities that do set the policies by which IANA operates.
* Are you comfortable with ICANN as policy-maker also being the IANA operator without the benefit of external oversight?
Impossible to answer as "ICANN" is not specified well enough.
I am comfortable with ICANN ccNSO and gNSO being policy makers while the IANA Function at ICANN Corporation is implementing the policy developed by the PDPs.
* Should registries, as the primary customers of the IANA functions, have more of a say as to which transition proposal is acceptable?
The registries are not the primary customers of the IANA functions. The IANA functions include many other things like IP Addresses, Protocol Parameters etc.
The balance in who has what say regarding instructions to IANA should be set by the design of the PDPs that control the IANA functions which include ccNSO and gNSO.
* What does functional separation of IANA from ICANN mean to you? (this is not referring to having another operator than ICANN performing the IANA functions but rather the internal separation between ICANN and IANA in the context where ICANN is the IANA operator)
First of all, there are already other organizations providing functions that IANA Function at ICANN could do (RIPE NCC for E.164 numbers for example).
Internal separation is only needed in the cases the PDPs do not create clear enough instructions to what IANA is to make. People participating do mix up ICANN decisions (on who can be registry for a specific TLD for example) with IANA actions (to take instructions and otherwise communicate with the registries).
So, I view the need for separation collapse into need for the PDPs to:
1. specifically produce instructions for IANA 2. explicitly validate that IANA is following the instructions > > > * In considering the key factors (such as security and stability, ease of separating the IANA function from ICANN, quality of services, accountability mechanisms etc.) for evaluating the various transition proposals what importance would you give to the ability to separate IANA from ICANN (separability) vs. the other factors?
If the IANA Function of ICANN is not following the instructions then an RFP must be filed for a separate group following those instructions. ICANN have already demonstrated such RFP can be hosted, run and affected for the ICG Secretariat that is now independent and separated from ICANN.
Don't forget the financing of IANA and other bodies people ask for.
* Given the IANA functions could be separated from ICANN do you believe it would be important for the community to obtain from ICANN on an annual basis the costs for operating IANA including overhead costs?
The PDP should decide what the rules for IANA should be, and if needed also who should take care of it. As part of that is also of course financing issues.
Regarding separation, as long as ICANN is financing, there is no real separation.
So, if the PDP want someone else than ICANN to run IANA, then the PDP must also be able to find money for the operation.
* Would it be important to separate out the costs associated with > address and protocol functions?
If RIRs or IETF want to move the functions, then of course IETF and RIR have to find financing of the (new) operator for that coordination. ICANN have nothing to do with it.
Today ICANN have agreed to finance the IANA Function as long as it is hosted at ICANN. That in turn might be a reason for (for example) RIRs to donate money to ICANN, and for Registry operators of TLDs to do the same.
* Could there be unforeseen impacts relative to selecting a new operator for the IANA functions vs the ICANN policy role (should ICANN determine that there will be another round of new gTLDs, how could it ensure that the new operator would accept this)?
Once again, it is only possible to talk about this if one talk about the role of the PDPs. Not just say "ICANN".
* Are there other transition models which the CWG should be exploring?
It must be much more clear what the role of the PDPs ccNSO and gNSO have to be able to do further evaluation, but in short I think better steps forward include:
A. Have the PDPs explicitly be the creators of instructions to IANA, and create interaction between the PDPs and IANA similar to the interaction IETF have. Specifically separate the IANA instructions from the rules for (for example) new TLDs.
B. Have GAC be responsible for finding a permanent solution for the .INT TLD based on the existing rules (RFC 1591 minus the international database).
C. Have ccNSO resolve the issues with ccTLD delegation/redelegation.
D. Have ICANN bylaws or otherwise be changed to ensure the power stays with the PDPs.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
participants (5)
-
Berry Cobb -
Brenda Brewer -
Gomes, Chuck -
Jaap Akkerhuis -
Martin Boyle