[Internal-cg] Publication of proposal finalization process
alissa at cooperw.in
Mon Dec 22 18:14:03 UTC 2014
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.
On Dec 19, 2014, at 11:53 PM, Patrik Fältström <paf at frobbit.se> wrote:
>> On 20 dec 2014, at 00:27, Alissa Cooper <alissa at 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.
More information about the Internal-cg