[Internal-cg] Strawman proposal finalization process
joseph alhadeff
joseph.alhadeff at oracle.com
Wed Oct 8 10:28:40 UTC 2014
Alissa:
I might change the order of these to follow the time process.
Start with open nature of process etc. I would also add a component of
whether statements/assertions in the proposal are properly
documented/supported. This goes to sufficiency as well as completeness.
Finally might we encourage communities to submit process descriptions to
evaluate openness and inclusion in design as developed? If we wait to
determine that process as designed was not inclusive until next year
that RFP has little chance of timely consideration. After the process
design is agreed to be open and inclusive the issue of whether it was
conducted as promised in design is part of the evaluation and that will
be known by whether there were complaint related to it...
Best-
Joe
On 10/7/2014 8:35 PM, Alissa Cooper wrote:
> I have posted an updated version of the proposal finalization process,
> attached and in Dropbox, that accommodates comments from Manal and Milton.
>
> I pulled the discussion questions and answers out of the document (and
> this short thread) and put them below, with some responses from me.
>
> Let's continue discussion on the list and at the f2f meeting.
>
> Thanks,
> Alissa
>
>
> == Question A ==
> Is the list in step 1 complete? What else belongs here?
>
> == Question B ==
> How should we handle step 1 procedurally? Should we delegate step 1 to
> one ICG member or a small group for each proposal, to conduct the
> analysis and report back to the group to review (as we've done with
> documents, secretariat, etc.)?
>
> Manal: I believe all ICG members should be equally involved in all
> proposals. It is important to have a holistic view. It also avoids
> any gaps in the overall outcome. Yet it is good to have a lead who
> holds the pen, ensures continuous progress, compile all comments and
> remarks made by ICG members and make sure they are accurately
> reflected (or resolved if conflicting/contradicting). So basically
> I'm in favour of one team and a different lead for each proposal.
>
> Alissa: I like the approach suggested by Manal.
>
> == Question C ==
> Is the list in step 2 complete? What else belongs here?
>
> == Question D ==
> Should we do this analysis pair-wise, as soon as we have two proposals
> that have passed step 1? Or should we wait until we have proposals for
> numbers, names, and protocol parameters that have passed step 1 before
> starting the analysis in step 2?
>
> Manal: I think if 2 are ready we should proceed with analyzing them,
> and as soon as we have the third ready we should repeat the analysis
> (hopefully quicker) in light of the three proposals and not depend on
> the results of the analysis of the first 2. Things may look different
> when we see the holistic view.
>
> Alissa: I agree with Manal. My only question is if it starts to look
> like one component is lagging far behind the others -- should we put
> the combination of the first two out for public comment (step 3)
> before receiving the third?
>
> == Question E ==
> How should we handle step 2 procedurally? Should we delegate step 2 to
> one ICG member or a small group to conduct the analysis and report
> back to the group to review (as we've done with documents,
> secretariat, etc.)?
>
> Manal: I'm again in favor of one team and separate leads for the
> reasons stated above.
>
> Alissa: I agree with Manal.
>
> == Question F==
> Do we need to add any more detail in step 3, or is the existing
> description sufficient?
>
> Manal: Nothing to add but I have a couple of questions. Should we have
> some place holder to step 4 of our timeline, which is 'Testing'?
> Should we link the steps above to the dates we have in the timeline?
>
> Alissa: I'm not sure there is anything we need to do vis a vis
> testing. The communities need to do their own testing.
>
> Alissa: I added dates from the timeline. Not sure if I aligned them
> properly, though.
>
> Milton: I found it unclear whether we go through another public
> comment if the proposals are modified. Probably we should. If we are
> forced to go through the rather important step of returning a proposal
> to an OC and modifying some part of it, we may want to give the public
> another crack at expressing their support for the new totality. NTIA
> may want us to do that also. On the other hand we want to avoid
> creating opportunities for political mobilizations that seek to levels
> of support rather than confirming or denying them. I would listen to
> differing views on this.
>
> Alissa: Good point, we should discuss.
>
>
>
>
>
>
> On Sep 23, 2014, at 11:57 AM, Kavouss Arasteh
> <kavouss.arasteh at gmail.com <mailto:kavouss.arasteh at gmail.com>> wrote:
>
>> Dear All,
>> Good start
>> Let us working on that as soon as possible
>> Please could someone create a naming and version and then moving ahead
>> Perhaps we could also discuss that at our third f2f meeting
>> I will comeback to you soon.
>> One important element to be added to Manal,s updated version is
>> partial or total overlap
>> Kavouss
>>
>>
>> 2014-09-23 20:54 GMT+02:00 Kavouss Arasteh <kavouss.arasteh at gmail.com
>> <mailto:kavouss.arasteh at gmail.com>>:
>>
>> Dear A
>>
>> 2014-09-23 16:23 GMT+02:00 Milton L Mueller <mueller at syr.edu
>> <mailto:mueller at syr.edu>>:
>>
>> Alissa
>> This is a great start. It does adhere closely to the charter
>> and raises good questions about decisions we have to make.
>>
>> I noticed a few things things I would want to modify or
>> questions I would want to answer in a specific way. I avoided
>> modifying the document directly at this stage (and would urge
>> others to do so as well) so that we can see how much support
>> specific ideas have before we start re-editing.
>>
>> 1. Step 1
>> I think this step needs to be modified a bit to put more
>> emphasis on ascertaining that the proposal we get from an OC
>> has followed a proper process and actually has the consensus
>> it claims to have. Our charter says:
>>
>> "Each proposal should be submitted with a clear
>> record of how consensus has been reached for the
>> proposal in the community, and provide an analysis that
>> shows the proposal is in practice workable. The ICG
>> should also compile the input it has received beyond
>> the operational communities, and assess the impacts of
>> this input."
>>
>> No major change needed here, I would simply propose to modify
>> step 1.d. to reflect that part of the charter more closely,
>> as follows:
>>
>> d. Verify the record of how consensus was reached, check if
>> input/comments the ICG received directly were shared with the
>> operational community and addressed by the process.
>>
>> 2. Step 3
>> I found it unclear whether we go through another public
>> comment if the proposals are modified. Probably we should. If
>> we are forced to go through the rather important step of
>> returning a proposal to an OC and modifying some part of it,
>> we may want to give the public another crack at expressing
>> their support for the new totality. NTIA may want us to do
>> that also. On the other hand we want to avoid creating
>> opportunities for political mobilizations that seek to levels
>> of support rather than confirming or denying them. I would
>> listen to differing views on this.
>>
>> Milton L Mueller
>> Laura J and L. Douglas Meredith Professor
>> Syracuse University School of Information Studies
>> http://faculty.ischool.syr.edu/mueller/
>>
>>
>> > -----Original Message-----
>> > From: internal-cg-bounces at icann.org
>> <mailto:internal-cg-bounces at icann.org> [mailto:internal-cg-
>> <mailto:internal-cg->
>> > bounces at icann.org <mailto:bounces at icann.org>] On Behalf Of
>> Alissa Cooper
>> > Sent: Monday, September 22, 2014 6:35 PM
>> > To: ICG
>> > Subject: [Internal-cg] Strawman proposal finalization process
>> >
>> > As discussed in the thread about ICANN 51 side meetings, it
>> seems like it
>> > would be helpful for us to develop a shared understanding
>> of how we will
>> > assemble and finalize a unified transition proposal after
>> we start receiving
>> > individual proposals from the operational communities and
>> broader input
>> > from all stakeholders. My guess is that we will not come to
>> a firm conclusion
>> > about all details of this process prior to ICANN 51, which
>> is fine. But we
>> > certainly need to come to some conclusions about it within
>> the next few
>> > months, so that we are prepared when we start receiving
>> proposals from the
>> > operational communities and input from all stakeholders.
>> >
>> > I've put together a strawman proposal for a process to use
>> to assemble and
>> > finalize a unified transition proposal (attached and in
>> dropbox). It is heavily
>> > influenced by our charter. You will see that there are many
>> open questions
>> > --- I'm just throwing this out as a starting point to get
>> discussion going. Please
>> > comment.
>> >
>> > I don't think we need to document every little detail and
>> possible corner case
>> > for how things might go once we start receiving proposals
>> and input, but I do
>> > think we should have a rough plan that we can articulate to
>> establish
>> > expectations about how we will proceed.
>> >
>> > Thanks,
>> > Alissa
>> >
>>
>> _______________________________________________
>> Internal-cg mailing list
>> Internal-cg at icann.org <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20141008/14707d19/attachment.html>
More information about the Internal-cg
mailing list