Publication of proposal finalization process
I think we are about ready to publish the proposal finalization process. The latest version is attached and in Dropbox, in both clean and edited form: https://www.dropbox.com/s/g6pgc9ma19fnwf7/proposal-finalization-process-v5-c... https://www.dropbox.com/s/zz9idw25dlqllyu/proposal-finalization-process-v5.d... I did a little bit of editorial work to enumerate the sections and subsections more clearly. Please reply to this email by 20:00 UTC on December 22 if you support publishing this document or if you have any further comments/edits. Thanks, Alissa
Many thanks Alissa .. I don't have comments on the proposal finalization process (PFP) itself and I support publishing the document.. Yet I have to say that it is not a straight forward task to cross-check it with the posted timeline .. The steps are not one-to-one in both documents .. Yet this is not a big deal, as ultimately due dates and deliverables seem to be consistent .. But I would like to highlight the following: 1. Step 4 of the timeline, I believe gives more weight to the testing than what was discussed and reflected in step II.C. of the PFP 2. Step 7 of the timeline, mentions that "the ICG formally submits the final proposal to NTIA." , which is contrary to what was agreed and reflected in Step V.A. of the PFP: "The ICG will post the final proposal on its public web site and transmit it to the ICANN Board." 3. Step 8 of the timeline starts with "The NTIA reviews and accepts the response." .. I think we should not be speaking on behalf of the NTIA and pre-empt its acceptance of the proposal .. I don't suggest to make any changes to the PFP but suggest to review and post a fine-tuned version of our timeline, focusing mainly on the structure and language of the document in relation to the PFP .. Appreciate your thoughts? Kind Regards --Manal -----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: Wednesday, December 17, 2014 12:09 AM To: ICG Subject: [Internal-cg] Publication of proposal finalization process I think we are about ready to publish the proposal finalization process. The latest version is attached and in Dropbox, in both clean and edited form: https://www.dropbox.com/s/g6pgc9ma19fnwf7/proposal-finalization-process- v5-clean.docx?dl=0 https://www.dropbox.com/s/zz9idw25dlqllyu/proposal-finalization-process- v5.docx?dl=0 I did a little bit of editorial work to enumerate the sections and subsections more clearly. Please reply to this email by 20:00 UTC on December 22 if you support publishing this document or if you have any further comments/edits. Thanks, Alissa
Manal: I think our timing related to our review of the proposals can be approximate at best, as we will be impacted by the status and nature of the proposal. But I agree that the timeline should better demonstrate a linkage to the process in relation to those approximate time frames. Best- Joe On 12/17/2014 5:10 AM, Manal Ismail wrote:
Many thanks Alissa ..
I don't have comments on the proposal finalization process (PFP) itself and I support publishing the document..
Yet I have to say that it is not a straight forward task to cross-check it with the posted timeline ..
The steps are not one-to-one in both documents .. Yet this is not a big deal, as ultimately due dates and deliverables seem to be consistent ..
But I would like to highlight the following:
1. Step 4 of the timeline, I believe gives more weight to the testing than what was discussed and reflected in step II.C. of the PFP
2. Step 7 of the timeline, mentions that "the ICG formally submits the final proposal to NTIA." , which is contrary to what was agreed and reflected in Step V.A. of the PFP: "The ICG will post the final proposal on its public web site and transmit it to the ICANN Board."
3. Step 8 of the timeline starts with "The NTIA reviews and accepts the response." .. I think we should not be speaking on behalf of the NTIA and pre-empt its acceptance of the proposal ..
I don't suggest to make any changes to the PFP but suggest to review and post a fine-tuned version of our timeline, focusing mainly on the structure and language of the document in relation to the PFP ..
Appreciate your thoughts?
Kind Regards --Manal
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: Wednesday, December 17, 2014 12:09 AM To: ICG Subject: [Internal-cg] Publication of proposal finalization process
I think we are about ready to publish the proposal finalization process. The latest version is attached and in Dropbox, in both clean and edited form:
https://www.dropbox.com/s/g6pgc9ma19fnwf7/proposal-finalization-process- v5-clean.docx?dl=0 https://www.dropbox.com/s/zz9idw25dlqllyu/proposal-finalization-process- v5.docx?dl=0
I did a little bit of editorial work to enumerate the sections and subsections more clearly.
Please reply to this email by 20:00 UTC on December 22 if you support publishing this document or if you have any further comments/edits.
Thanks, Alissa
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Manal you are a treasure, thanks for taking the time to synchronize our timeline with the PFP. It seems like you have accurately identified various places in which our understanding of the process has changed since the development of the timeline. All of the suggestions you make should be accepted and incorporated into a revised timeline, in my view. --MM
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg- bounces@icann.org] On Behalf Of Manal Ismail Sent: Wednesday, December 17, 2014 5:11 AM To: Alissa Cooper; ICG Subject: Re: [Internal-cg] Publication of proposal finalization process
Many thanks Alissa ..
I don't have comments on the proposal finalization process (PFP) itself and I support publishing the document..
Yet I have to say that it is not a straight forward task to cross-check it with the posted timeline ..
The steps are not one-to-one in both documents .. Yet this is not a big deal, as ultimately due dates and deliverables seem to be consistent ..
But I would like to highlight the following:
1. Step 4 of the timeline, I believe gives more weight to the testing than what was discussed and reflected in step II.C. of the PFP
2. Step 7 of the timeline, mentions that "the ICG formally submits the final proposal to NTIA." , which is contrary to what was agreed and reflected in Step V.A. of the PFP: "The ICG will post the final proposal on its public web site and transmit it to the ICANN Board."
3. Step 8 of the timeline starts with "The NTIA reviews and accepts the response." .. I think we should not be speaking on behalf of the NTIA and pre-empt its acceptance of the proposal ..
I don't suggest to make any changes to the PFP but suggest to review and post a fine-tuned version of our timeline, focusing mainly on the structure and language of the document in relation to the PFP ..
Appreciate your thoughts?
Kind Regards --Manal
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: Wednesday, December 17, 2014 12:09 AM To: ICG Subject: [Internal-cg] Publication of proposal finalization process
I think we are about ready to publish the proposal finalization process. The latest version is attached and in Dropbox, in both clean and edited form:
https://www.dropbox.com/s/g6pgc9ma19fnwf7/proposal-finalization- process- v5-clean.docx?dl=0 https://www.dropbox.com/s/zz9idw25dlqllyu/proposal-finalization-process- v5.docx?dl=0
I did a little bit of editorial work to enumerate the sections and subsections more clearly.
Please reply to this email by 20:00 UTC on December 22 if you support publishing this document or if you have any further comments/edits.
Thanks, Alissa
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Thanks, Manal. Indeed ever since the inaccuracy in step 7 was pointed out I have been thinking that we needed to revise the timeline. I think it would make sense to update the timeline language and publish it together with the proposal finalization process. I’ve attached an edited timeline <https://www.dropbox.com/s/n5pzeikw5fju9k8/TimelineDiscussion-v7-alc.docx?dl=...> that addresses your points 2 and 3 below and makes some editorial fixes. I’m not sure that I agree about your point 1 — or perhaps I just don’t know how to address it. I think the March-July time frame is when communities should be testing their arrangements, if they feel specific testing is warranted. Do you have a suggested edit for Step 4? Do others have comments on this? Could we try to wrap up the timeline document at the same time as the proposal finalization process (i.e., Monday) since the edits are minimal and at least the one I’ve proposed for step 7 takes language directly from the proposal finalization process? Thanks, Alissa On Dec 17, 2014, at 2:10 AM, Manal Ismail <manal@tra.gov.eg> wrote:
Many thanks Alissa ..
I don't have comments on the proposal finalization process (PFP) itself and I support publishing the document..
Yet I have to say that it is not a straight forward task to cross-check it with the posted timeline ..
The steps are not one-to-one in both documents .. Yet this is not a big deal, as ultimately due dates and deliverables seem to be consistent ..
But I would like to highlight the following:
1. Step 4 of the timeline, I believe gives more weight to the testing than what was discussed and reflected in step II.C. of the PFP
2. Step 7 of the timeline, mentions that "the ICG formally submits the final proposal to NTIA." , which is contrary to what was agreed and reflected in Step V.A. of the PFP: "The ICG will post the final proposal on its public web site and transmit it to the ICANN Board."
3. Step 8 of the timeline starts with "The NTIA reviews and accepts the response." .. I think we should not be speaking on behalf of the NTIA and pre-empt its acceptance of the proposal ..
I don't suggest to make any changes to the PFP but suggest to review and post a fine-tuned version of our timeline, focusing mainly on the structure and language of the document in relation to the PFP ..
Appreciate your thoughts?
Kind Regards --Manal
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: Wednesday, December 17, 2014 12:09 AM To: ICG Subject: [Internal-cg] Publication of proposal finalization process
I think we are about ready to publish the proposal finalization process. The latest version is attached and in Dropbox, in both clean and edited form:
https://www.dropbox.com/s/g6pgc9ma19fnwf7/proposal-finalization-process- v5-clean.docx?dl=0 https://www.dropbox.com/s/zz9idw25dlqllyu/proposal-finalization-process- v5.docx?dl=0
I did a little bit of editorial work to enumerate the sections and subsections more clearly.
Please reply to this email by 20:00 UTC on December 22 if you support publishing this document or if you have any further comments/edits.
Thanks, Alissa
Thanks Joseph and Milton for your responses and Alissa for also addressing my last 2 comments .. I agree to all your edits (I guess it was a wrong email attachment but I checked Dropbox).. I also agree to publishing the updated timeline together with the proposal finalization process .. I think ultimately we should also make sure the FAQ links to the updated version .. Regarding the testing, I have to admit that I'm a bit unclear now on what we're trying to convey/request .. A yes/no/optional answers to the below may help .. - Are we requesting tests/stress tests to be carried out for all submitted proposals? - Are we requesting documentation of such tests, how they were carried out and their results? - Are we requesting that those tests be put in action and continue to be effective till July and beyond? - Will we be re-checking on the results of those tests again in July? I think what confuses me is that we've agreed to delete this from the PFP: "Consideration of how the proposal documented the stress tests or scenario analysis that they were subjected to and whether those results when considered in combination create any possible concerns", because, and I stand to be corrected, that this was not explicitly requested from the operational communities, which, to me, seems to be a bit conflicting with what we're asking for in step 4 of the timeline .. Hope I was able to clarify my point and happy to be convinced that there is no issue here and that both documents are in synch :) .. Kind Regards --Manal -----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Thursday, December 18, 2014 4:12 AM To: Manal Ismail Cc: ICG Subject: Re: [Internal-cg] Publication of proposal finalization process Thanks, Manal. Indeed ever since the inaccuracy in step 7 was pointed out I have been thinking that we needed to revise the timeline. I think it would make sense to update the timeline language and publish it together with the proposal finalization process. I've attached an edited timeline <https://www.dropbox.com/s/n5pzeikw5fju9k8/TimelineDiscussion-v7-alc.doc x?dl=0> that addresses your points 2 and 3 below and makes some editorial fixes. I'm not sure that I agree about your point 1 - or perhaps I just don't know how to address it. I think the March-July time frame is when communities should be testing their arrangements, if they feel specific testing is warranted. Do you have a suggested edit for Step 4? Do others have comments on this? Could we try to wrap up the timeline document at the same time as the proposal finalization process (i.e., Monday) since the edits are minimal and at least the one I've proposed for step 7 takes language directly from the proposal finalization process? Thanks, Alissa
Hi Manal, From my perspective it is up to the operational communities to decide whether and how to test their proposals. The only requirement we have put forth is in Section IV of the RFP: "Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements.” The timeline simply shows when testing is likely to take place, if the communities decide to undertake it (step 4). If they do undertake it, I think it is incumbent upon us to verify that test results show the system to be working (step 7). That is, we don’t want the unified proposal to reflect an operational arrangement that we know has glitches. But if tests were not conducted for a particular arrangement, we will not have anything to confirm. I think this flexibility is important because some communities may not propose any operational changes at all, in which case there really will be nothing to “test.” Alissa On Dec 18, 2014, at 1:19 AM, Manal Ismail <manal@tra.gov.eg> wrote:
Thanks Joseph and Milton for your responses and Alissa for also addressing my last 2 comments .. I agree to all your edits (I guess it was a wrong email attachment but I checked Dropbox).. I also agree to publishing the updated timeline together with the proposal finalization process .. I think ultimately we should also make sure the FAQ links to the updated version ..
Regarding the testing, I have to admit that I'm a bit unclear now on what we're trying to convey/request .. A yes/no/optional answers to the below may help ..
- Are we requesting tests/stress tests to be carried out for all submitted proposals? - Are we requesting documentation of such tests, how they were carried out and their results? - Are we requesting that those tests be put in action and continue to be effective till July and beyond? - Will we be re-checking on the results of those tests again in July?
I think what confuses me is that we've agreed to delete this from the PFP: "Consideration of how the proposal documented the stress tests or scenario analysis that they were subjected to and whether those results when considered in combination create any possible concerns", because, and I stand to be corrected, that this was not explicitly requested from the operational communities, which, to me, seems to be a bit conflicting with what we're asking for in step 4 of the timeline ..
Hope I was able to clarify my point and happy to be convinced that there is no issue here and that both documents are in synch :) ..
Kind Regards --Manal
-----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Thursday, December 18, 2014 4:12 AM To: Manal Ismail Cc: ICG Subject: Re: [Internal-cg] Publication of proposal finalization process
Thanks, Manal. Indeed ever since the inaccuracy in step 7 was pointed out I have been thinking that we needed to revise the timeline. I think it would make sense to update the timeline language and publish it together with the proposal finalization process.
I've attached an edited timeline <https://www.dropbox.com/s/n5pzeikw5fju9k8/TimelineDiscussion-v7-alc.doc x?dl=0> that addresses your points 2 and 3 below and makes some editorial fixes. I'm not sure that I agree about your point 1 - or perhaps I just don't know how to address it. I think the March-July time frame is when communities should be testing their arrangements, if they feel specific testing is warranted. Do you have a suggested edit for Step 4?
Do others have comments on this? Could we try to wrap up the timeline document at the same time as the proposal finalization process (i.e., Monday) since the edits are minimal and at least the one I've proposed for step 7 takes language directly from the proposal finalization process?
Thanks, Alissa
On 20 dec 2014, at 00:27, Alissa Cooper <alissa@cooperw.in> wrote:
I think this flexibility is important because some communities may not propose any operational changes at all, in which case there really will be nothing to “test.”
Well, while I agree the flexibility is important I do not agree nothing has to be tested if nothing is changed. Something is changing, the contract between ICANN and NTIA is not extended. And there are a few things in that contract that might have impact on operation even if the mechanisms do not change. And I think personally that should be tested. But, once again, that is up to the communities to decide. SSAC have in SAC-069 <https://www.icann.org/en/system/files/files/sac-069-en.pdf> a number of recommendations on "things to keep eyes on". For example Recommendation 3:
Recommendation 3: Each of the communities should investigate and clarify the process for handling the possibility of governmental sanctions and restrictions (e.g., the protocol for obtaining OFAC2 licenses where U.S. sanctions might interfere with the ability to execute proper instructions to IANA) following the stewardship transition.
For that to be possible to evaluate, SSAC also wrote recommendation 7:
Recommendation 7: NTIA should clarify the processes and legal framework associated with the role of the Root Zone Maintainer after transition.
For the names community, I think this Recommendation from SSAC is important to have a look at, this as SSAC see a difference between "the policy" developed by the policy developing processes and "the rules" that ICANN as the organisation produce, and then finally "the instructions" IANA function at ICANN create, implement and follow. In the case of IETF, IETF do indeed write explicit instructions to the IANA function operator while it is not as explicit for other communities:
Recommendation 2b: Each of the communities should review and (if necessary) enhance its policy development process to ensure that all of the instructions that it provides to the IANA Functions Operator are clear and implementable.
But once again, all of this is up to the communities to decide. Patrik
Alissa, Patrik, Mohammed I did ask you some question about the scope and conditions of famous " Stress Test " that everybod talks about these days Regards Kavouss 2014-12-20 8:53 GMT+01:00 Patrik Fältström <paf@frobbit.se>:
On 20 dec 2014, at 00:27, Alissa Cooper <alissa@cooperw.in> wrote:
I think this flexibility is important because some communities may not propose any operational changes at all, in which case there really will be nothing to “test.”
Well, while I agree the flexibility is important I do not agree nothing has to be tested if nothing is changed. Something is changing, the contract between ICANN and NTIA is not extended. And there are a few things in that contract that might have impact on operation even if the mechanisms do not change. And I think personally that should be tested. But, once again, that is up to the communities to decide.
SSAC have in SAC-069 < https://www.icann.org/en/system/files/files/sac-069-en.pdf> a number of recommendations on "things to keep eyes on".
For example Recommendation 3:
Recommendation 3: Each of the communities should investigate and clarify the process for handling the possibility of governmental sanctions and restrictions (e.g., the protocol for obtaining OFAC2 licenses where U.S. sanctions might interfere with the ability to execute proper instructions to IANA) following the stewardship transition.
For that to be possible to evaluate, SSAC also wrote recommendation 7:
Recommendation 7: NTIA should clarify the processes and legal framework associated with the role of the Root Zone Maintainer after transition.
For the names community, I think this Recommendation from SSAC is important to have a look at, this as SSAC see a difference between "the policy" developed by the policy developing processes and "the rules" that ICANN as the organisation produce, and then finally "the instructions" IANA function at ICANN create, implement and follow. In the case of IETF, IETF do indeed write explicit instructions to the IANA function operator while it is not as explicit for other communities:
Recommendation 2b: Each of the communities should review and (if necessary) enhance its policy development process to ensure that all of the instructions that it provides to the IANA Functions Operator are clear and implementable.
But once again, all of this is up to the communities to decide.
Patrik
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
I agree with Patrik's observations. Sent from my iPad
On Dec 20, 2014, at 2:53 AM, Patrik Fältström <paf@frobbit.se> wrote:
On 20 dec 2014, at 00:27, Alissa Cooper <alissa@cooperw.in> wrote:
I think this flexibility is important because some communities may not propose any operational changes at all, in which case there really will be nothing to “test.”
Well, while I agree the flexibility is important I do not agree nothing has to be tested if nothing is changed. Something is changing, the contract between ICANN and NTIA is not extended. And there are a few things in that contract that might have impact on operation even if the mechanisms do not change. And I think personally that should be tested. But, once again, that is up to the communities to decide.
SSAC have in SAC-069 <https://www.icann.org/en/system/files/files/sac-069-en.pdf> a number of recommendations on "things to keep eyes on".
For example Recommendation 3:
Recommendation 3: Each of the communities should investigate and clarify the process for handling the possibility of governmental sanctions and restrictions (e.g., the protocol for obtaining OFAC2 licenses where U.S. sanctions might interfere with the ability to execute proper instructions to IANA) following the stewardship transition.
For that to be possible to evaluate, SSAC also wrote recommendation 7:
Recommendation 7: NTIA should clarify the processes and legal framework associated with the role of the Root Zone Maintainer after transition.
For the names community, I think this Recommendation from SSAC is important to have a look at, this as SSAC see a difference between "the policy" developed by the policy developing processes and "the rules" that ICANN as the organisation produce, and then finally "the instructions" IANA function at ICANN create, implement and follow. In the case of IETF, IETF do indeed write explicit instructions to the IANA function operator while it is not as explicit for other communities:
Recommendation 2b: Each of the communities should review and (if necessary) enhance its policy development process to ensure that all of the instructions that it provides to the IANA Functions Operator are clear and implementable.
But once again, all of this is up to the communities to decide.
Patrik
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Many thanks Alissa for the clarification and thanks Joseph and Patrick for sharing your views .. I agree to flexibility .. I also see Patrik's point and agree that ultimately it's up to each and every community to decide .. In fact my question was whether the language in the different documents (charter, timeline & proposal finalization process) provide the same degree of flexibility (I felt the timeline is more firm about testing and not only requires it but also requires it to continue running till July) .. But I take your below clarification as all 3 docs are more or less in synch and have nothing in conflict .. So maybe it's misinterpretation from my side .. Thanks again .. I'm fine with posting both docs .. Kind Regards --Manal -----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Joseph Alhadeff Sent: Saturday, December 20, 2014 1:27 PM To: Patrik Fältström Cc: ICG Subject: Re: [Internal-cg] Publication of proposal finalization process I agree with Patrik's observations. Sent from my iPad
On Dec 20, 2014, at 2:53 AM, Patrik Fältström <paf@frobbit.se> wrote:
On 20 dec 2014, at 00:27, Alissa Cooper <alissa@cooperw.in> wrote:
I think this flexibility is important because some communities may not propose any operational changes at all, in which case there really will be nothing to “test.”
Well, while I agree the flexibility is important I do not agree nothing has to be tested if nothing is changed. Something is changing, the contract between ICANN and NTIA is not extended. And there are a few things in that contract that might have impact on operation even if the mechanisms do not change. And I think personally that should be tested. But, once again, that is up to the communities to decide.
SSAC have in SAC-069 <https://www.icann.org/en/system/files/files/sac-069-en.pdf> a number of recommendations on "things to keep eyes on".
For example Recommendation 3:
Recommendation 3: Each of the communities should investigate and clarify the process for handling the possibility of governmental sanctions and restrictions (e.g., the protocol for obtaining OFAC2 licenses where U.S. sanctions might interfere with the ability to execute proper instructions to IANA) following the stewardship transition.
For that to be possible to evaluate, SSAC also wrote recommendation 7:
Recommendation 7: NTIA should clarify the processes and legal framework associated with the role of the Root Zone Maintainer after transition.
For the names community, I think this Recommendation from SSAC is important to have a look at, this as SSAC see a difference between "the policy" developed by the policy developing processes and "the rules" that ICANN as the organisation produce, and then finally "the instructions" IANA function at ICANN create, implement and follow. In the case of IETF, IETF do indeed write explicit instructions to the IANA function operator while it is not as explicit for other communities:
Recommendation 2b: Each of the communities should review and (if necessary) enhance its policy development process to ensure that all of the instructions that it provides to the IANA Functions Operator are clear and implementable.
But once again, all of this is up to the communities to decide.
Patrik
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Thanks, Patrick. You raise good points and your mail also highlights the multiple different meanings that the term “testing” has taken on in the context of the transition. One sense in which I’ve seen the word used, and in which you use it below, is in the vein of “think about potential scenarios that may arise post-transition and ensure that the expected process for handling them is well understood and well documented.” This is also the sense in which I’ve seen the phrase “stress testing” used, although I have not been following all of the stress testing discussions. To my ear this sense of the word “testing” really just equates to having a complete transition proposal that accounts for eventualities and covers the scenarios of concern to the communities, but doesn’t require setting up any sort of experimental testbed or trialing a new arrangement before the transition occurs. I’m not even sure how this could be accomplished for some “tests,” for example the one you explain below about countries under sanction. It’s not as if the community could ask a country under sanction to request a change to the root zone in spring of 2015 just for the sake of “testing” a proposed post-transition process related to handling requests from countries under sanction. The other sense in which I’ve seen “testing” be used is the operational sense. That is, if the communities propose changes to how registry administration is actually handled, which parties perform which operational tasks, who has access to the back-end IANA databases, etc., then those new or different processes should be tested to ensure that they are stable prior to transition. This is the sense in which I believe the word “testing” has been in used in our RFP and timeline. For example, step 4 in the timeline says: "Undertake a test plan and demonstrate that the system can run as proposed. Keep it running in this manner. Until NTIA approves the final response, the NTIA must approve DNS Root Zone updates, perhaps in parallel to the proposed process for these updates.” I think there is a clear implication there that the “testing” referred to in the timeline is of an operational sort. Alissa On Dec 19, 2014, at 11:53 PM, Patrik Fältström <paf@frobbit.se> wrote:
On 20 dec 2014, at 00:27, Alissa Cooper <alissa@cooperw.in> wrote:
I think this flexibility is important because some communities may not propose any operational changes at all, in which case there really will be nothing to “test.”
Well, while I agree the flexibility is important I do not agree nothing has to be tested if nothing is changed. Something is changing, the contract between ICANN and NTIA is not extended. And there are a few things in that contract that might have impact on operation even if the mechanisms do not change. And I think personally that should be tested. But, once again, that is up to the communities to decide.
SSAC have in SAC-069 <https://www.icann.org/en/system/files/files/sac-069-en.pdf> a number of recommendations on "things to keep eyes on".
For example Recommendation 3:
Recommendation 3: Each of the communities should investigate and clarify the process for handling the possibility of governmental sanctions and restrictions (e.g., the protocol for obtaining OFAC2 licenses where U.S. sanctions might interfere with the ability to execute proper instructions to IANA) following the stewardship transition.
For that to be possible to evaluate, SSAC also wrote recommendation 7:
Recommendation 7: NTIA should clarify the processes and legal framework associated with the role of the Root Zone Maintainer after transition.
For the names community, I think this Recommendation from SSAC is important to have a look at, this as SSAC see a difference between "the policy" developed by the policy developing processes and "the rules" that ICANN as the organisation produce, and then finally "the instructions" IANA function at ICANN create, implement and follow. In the case of IETF, IETF do indeed write explicit instructions to the IANA function operator while it is not as explicit for other communities:
Recommendation 2b: Each of the communities should review and (if necessary) enhance its policy development process to ensure that all of the instructions that it provides to the IANA Functions Operator are clear and implementable.
But once again, all of this is up to the communities to decide.
Patrik
Resending with correct attachment. On Dec 17, 2014, at 6:12 PM, Alissa Cooper <alissa@cooperw.in> wrote:
Thanks, Manal. Indeed ever since the inaccuracy in step 7 was pointed out I have been thinking that we needed to revise the timeline. I think it would make sense to update the timeline language and publish it together with the proposal finalization process.
I’ve attached an edited timeline <https://www.dropbox.com/s/n5pzeikw5fju9k8/TimelineDiscussion-v7-alc.docx?dl=...> that addresses your points 2 and 3 below and makes some editorial fixes. I’m not sure that I agree about your point 1 — or perhaps I just don’t know how to address it. I think the March-July time frame is when communities should be testing their arrangements, if they feel specific testing is warranted. Do you have a suggested edit for Step 4?
Do others have comments on this? Could we try to wrap up the timeline document at the same time as the proposal finalization process (i.e., Monday) since the edits are minimal and at least the one I’ve proposed for step 7 takes language directly from the proposal finalization process?
Thanks, Alissa
<TimelineDiscussion-v7.docx> On Dec 17, 2014, at 2:10 AM, Manal Ismail <manal@tra.gov.eg> wrote:
Many thanks Alissa ..
I don't have comments on the proposal finalization process (PFP) itself and I support publishing the document..
Yet I have to say that it is not a straight forward task to cross-check it with the posted timeline ..
The steps are not one-to-one in both documents .. Yet this is not a big deal, as ultimately due dates and deliverables seem to be consistent ..
But I would like to highlight the following:
1. Step 4 of the timeline, I believe gives more weight to the testing than what was discussed and reflected in step II.C. of the PFP
2. Step 7 of the timeline, mentions that "the ICG formally submits the final proposal to NTIA." , which is contrary to what was agreed and reflected in Step V.A. of the PFP: "The ICG will post the final proposal on its public web site and transmit it to the ICANN Board."
3. Step 8 of the timeline starts with "The NTIA reviews and accepts the response." .. I think we should not be speaking on behalf of the NTIA and pre-empt its acceptance of the proposal ..
I don't suggest to make any changes to the PFP but suggest to review and post a fine-tuned version of our timeline, focusing mainly on the structure and language of the document in relation to the PFP ..
Appreciate your thoughts?
Kind Regards --Manal
-----Original Message----- From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: Wednesday, December 17, 2014 12:09 AM To: ICG Subject: [Internal-cg] Publication of proposal finalization process
I think we are about ready to publish the proposal finalization process. The latest version is attached and in Dropbox, in both clean and edited form:
https://www.dropbox.com/s/g6pgc9ma19fnwf7/proposal-finalization-process- v5-clean.docx?dl=0 https://www.dropbox.com/s/zz9idw25dlqllyu/proposal-finalization-process- v5.docx?dl=0
I did a little bit of editorial work to enumerate the sections and subsections more clearly.
Please reply to this email by 20:00 UTC on December 22 if you support publishing this document or if you have any further comments/edits.
Thanks, Alissa
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Thanks to those who sent final comments on the proposal finalization process. I will ask Alice to get it posted to the web site. Since the holidays are upon us I think we should wait until 7 January 2015 at 20:00 UTC to post the updated timeline document, in case anyone has further suggestions. We can post an announcement about both documents at that time. Best, Alissa On Dec 16, 2014, at 2:09 PM, Alissa Cooper <alissa@cooperw.in> wrote:
I think we are about ready to publish the proposal finalization process. The latest version is attached and in Dropbox, in both clean and edited form:
https://www.dropbox.com/s/g6pgc9ma19fnwf7/proposal-finalization-process-v5-c... https://www.dropbox.com/s/zz9idw25dlqllyu/proposal-finalization-process-v5.d...
I did a little bit of editorial work to enumerate the sections and subsections more clearly.
Please reply to this email by 20:00 UTC on December 22 if you support publishing this document or if you have any further comments/edits.
Thanks, Alissa
<proposal-finalization-process-v5.docx><proposal-finalization-process-v5-clean.docx>_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Just a reminder that the updated timeline document will be posted on 7 January — if you have any further comments, please send them as soon as possible. Thanks, Alissa Begin forwarded message:
From: Alissa Cooper <alissa@cooperw.in> Subject: Re: [Internal-cg] Publication of proposal finalization process Date: December 22, 2014 at 2:44:09 PM PST To: ICG <internal-cg@icann.org>
Thanks to those who sent final comments on the proposal finalization process. I will ask Alice to get it posted to the web site.
Since the holidays are upon us I think we should wait until 7 January 2015 at 20:00 UTC to post the updated timeline document, in case anyone has further suggestions. We can post an announcement about both documents at that time.
Best, Alissa
On Dec 16, 2014, at 2:09 PM, Alissa Cooper <alissa@cooperw.in> wrote:
I think we are about ready to publish the proposal finalization process. The latest version is attached and in Dropbox, in both clean and edited form:
https://www.dropbox.com/s/g6pgc9ma19fnwf7/proposal-finalization-process-v5-c... https://www.dropbox.com/s/zz9idw25dlqllyu/proposal-finalization-process-v5.d...
I did a little bit of editorial work to enumerate the sections and subsections more clearly.
Please reply to this email by 20:00 UTC on December 22 if you support publishing this document or if you have any further comments/edits.
Thanks, Alissa
<proposal-finalization-process-v5.docx><proposal-finalization-process-v5-clean.docx>_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
participants (6)
-
Alissa Cooper -
joseph alhadeff -
Kavouss Arasteh -
Manal Ismail -
Milton L Mueller -
Patrik Fältström