[Internal-cg] Proposal finalization process v4

Adiel Akplogan adiel at afrinic.net
Wed Dec 10 10:37:45 UTC 2014


Thank you Alissa,

Further comments inline:

On Dec 10, 2014, at 03:19 AM, Alissa Cooper <alissa at cooperw.in> wrote:

> I have consolidated the comments and edits from Milton, Adiel, Joe, and Russ in the attached v4 <https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization%20process>. I accepted changes on all the text where no one had commented for easier reading. I also inserted a few comments/edits of my own the proposed changes, which I repeat below.
> 
> Step 1a, bullet 3: Milton suggested using "Whether the proposal obtained consensus” instead of “How the proposal obtained consensus.” 
> I am fine with “whether.” I would also be fine with “Whether and how.”  In the RFP, we ask the communities to explain “the steps that were taken to develop the proposal and to determine consensus.” I would consider a list of those steps to be the “how.”

“Whether and How" will work for me.

> Step 1b: Adiel suggested adding a bullet about timeliness. 
> I do not think this is actionable and so should not be included. If we get a proposal after the target deadline, I do not believe we are in a position to do anything other than start conducting the assessment in step 1. Of course, if we get a proposal many weeks/months after the target deadline, it will create some chaos for all of the steps afterward, but I don’t really see a lot of value in specifying how we will handle every possible case of that sort that could arise depending on the exact timing and sequence of the arrival of the component proposals.

I think we need to have a clear statement of what we do about late submission. This is important as we have set a deadline for application and as you mentioned above some may submit theirs few hour after closure and some other may do days after. We need to be clear or give an indication to the community how we will handle that. Our process has to be irreproachable.

> Step 2: Adiel questioned whether the statement that the ICG’s role “is not to draft a single transition proposal” is accurate.
> I believe it is accurate, in the sense that we are not “drafting” or writing anything of our own. I added the words “of its own” to the end of that phrase to try to make this more clear.

Thank, i’m fine with the adding of “of it own” to clarify. Because I believe that our purpose is to come up with a single proposal that is a consolidated version of all the various proposal submitted.

> Step 2: Adiel questioned the use of the word “unifying.”
> I agree that “unifying” and “uniform” are confusing. I believe our task is one of assembly. Our goal is to end up with one document, but not to massage the text of the component proposals to achieve “unity.” I have replaced the word “unified” in this section with the word “single” to make this clear. 

Thanks that make it clearer. We may want to discuss this a bit further during the conf call today.

> Step 2a: Joe inserted “possibly conflicting” as a qualifier for “overlaps”
> I don’t understand what a conflicting overlap is, and I think the proposals need to have a coherent story about all overlaps. So I disagree with this addition. 

No comment.

> Step 2b: Joe asked whether we need to cross-reference the ICANN accountability work.
> I think this is already covered by the fact that we are already asking “Do the proposals together include appropriate and properly supported independent accountability mechanisms for running the IANA function?”

I think he is referring to ICANN (as IANA function contractor) own accountability? 

> Step 2c: There has been list discussion between Joe and Russ about testing.
> I suggested some text as a middle ground approach. In the RFP we do ask the communities to describe any testing they do. I’m not quite sure how the test results could conflict with each other or otherwise be problematic in combination, but I’m happy to check for that when we’re assembling the single proposal.
> 
> Step 5: I have made the latest changes suggested on the list by Milton, which I think address everyone’s concerns.

I have made a suggestion about this in the previous version which suggested to remove the sentence “which will either endorse the report, or it will express concerns that will already have been shared with the ICG through the various opportunities for public comment and dialogue”, and make the sentence read “The ICANN Board may send an accompanying letter to NTIA with it own assessment of the proposal if any.”

In this version I will suggest to move the step (d) before (c) and for the current (c) I will suggest the following text:

“The ICANN Board will send the final proposal to NTIA without making any changes within 14 days of receiving the proposal from the ICG. Any accompanying letter and ICANN own assessment of the proposal will [shall] be posted publicly.

While we don’t want to say what ICANN should do, I think we need recognise that they can make their own assessment of the final proposal (even if step (d) provides room for clearing any issue). We want that final assessment (which may not be part of the accompanying letter) to be published. 

Thanks.

- a.

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


More information about the Internal-cg mailing list