[Internal-cg] Publication of proposal finalization process

[Manal Ismail]

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 at icann.org [mailto:internal-cg-bounces at 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 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.
> 
>   Patrik
> 
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________
Internal-cg mailing list
Internal-cg at icann.org
https://mm.icann.org/mailman/listinfo/internal-cg