[Internal-cg] Publication of proposal finalization process

Patrik Fältström paf at frobbit.se
Sat Dec 20 07:53:08 UTC 2014

> 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20141220/8b704854/signature.asc>

More information about the Internal-cg mailing list