[Internal-cg] [IANAxfer] [ianatransition] Jurisdiction (wasComposition of the ICG)

Manal Ismail manal at tra.gov.eg
Mon Aug 4 09:39:32 UTC 2014


Thanks Joseph, Patrik and Adiel for this exchange and the important points raised ..

I believe 2 key success factors here would be:
1. Timely and clear communications to clarify the process and guide the submissions ..
2. Allowing time to go through several consultation iterations with the community, along the lines suggested by Joseph, to further ensure not only broader consensus of the final consolidated proposal but also trust in the followed process ..

More concretely, I suggest:
1. In addition to, requesting the three proposals from the three communities (Joseph point 1 below) (through the draft led by Paul), 
2. that we also post a clear guideline communication for communities other than the 3 above to:
	2.1 encourage them to contribute their views through any of the 3 above mentioned communities .. and post all relevant information regarding their consultation processes (for example: email addresses to submit comments, websites, contact persons, group leads, current drafts, ...?)
	2.2 encourage consolidated, broadly supported proposals
	2.3 encourage community members to attribute themselves to any submitted proposal they fully agree to, rather than submitting a new one 
	2.4 clarify, if yet clear to us, ICG approach in consolidating and integrating submitted proposals, for instance, in case of conflicting views are we going to add both views and start a new consultation iteration? Are we going to choose only one? Which one? the more broadly supported? those submitted through stakeholder groups and/or cross community working groups? individual creative/out-of the-box submissions? Of course whatever the approach is, we will be making community consultation iterations, along the lines suggested by Joseph below ..
	2.4' Alternatively, as I have just read in a recent message, we may agree to suggest that in order not to take on a greater decision-making role, that the community comments on proposals from the 3 above mentioned communities (if this is what we agree to do) ..

In summary, I think it is most important that we discuss, make sure we agree and have a common understanding (if we are not, how can we expect the community to be clear about the process), post this suggested process/approach online, seek community feedback, set a deadline, and fine tune the process accordingly ..

Thanks again for this useful discussion ..

Kind Regards
--Manal  

 

-----Original Message-----
From: internal-cg-bounces at icann.org [mailto:internal-cg-bounces at icann.org] On Behalf Of Adiel Akplogan
Sent: Monday, August 04, 2014 8:19 AM
To: joseph alhadeff
Cc: ICG Internal
Subject: Re: [Internal-cg] [IANAxfer] [ianatransition] Jurisdiction (wasComposition of the ICG)

Thank you Joe and Patrick, and all please excuse my straight and non-diplomatic talk here, but I think we are not being consistent with our own discussion and agreement. I recall that we had this discussion in London and it was clear that we cannot restrict the contribution solely to the 3 groups (even if we expect each of them to run an open process where everyone can participate) but we have clearly highlight the fact (at least I made that comment) that we need to allow broader input and proposal even though __particular__ attention will be given to the one coming from the 3 main customers. We need to reaffirm this to the community (if it was not clear enough). We need to make the process as broader as possible as not everyone clearly identify themselves to these 3 main groups so it should be clear how their views reach to us. Maybe we have not been clear enough about that in our communication outside. 

Again my plea for us to collectively operate as ICG and not representative of our community view. We want it or not our work hold a political dimension for many around the world (genuinely or not) and we have, as ICG, to collectively accept that and try to carefully reflect that in our proceedings (of course without diluting the real substance of what is on stake).

Thanks.

- a. 

On Aug 3, 2014, at 18:22 PM, Patrik Fältström <paf at frobbit.se> wrote:

> I think this looks good.
> 
> I would even like to see as an over arching request from us to have as many as possible participate in the development of the proposals we get to us. There might even be things all three groups get some consensus on together? If they detect that, why not have them tell us?
> 
> We will reach the day when we as part of our coordination activities must decide some proposals that reach us are on rough side of rough consensus. Either proposals not getting traction within each one of the communities (i.e. filtered out before proposals reaches us, but the proposals still get posted to us), or because we see the proposals be so different than what is proposed from the general consensus that we do not see it being possible to be integrated.
> 
> The more those "odd one out" proposals have been discussed _before_ we get them, the better. Otherwise that will be a delay for us. When we have to measure what the feeling is about them.
> 
>    Regards, Patrik
> 
> On 3 aug 2014, at 15:22, joseph alhadeff <joseph.alhadeff at oracle.com> wrote:
> 
>> Would one way to address the breadth issue while considering the needs of channeling and efficiency be to:
>> 
>> 1.  At the outset, request the three proposals from the three communities.
>> 2.  Assure that those communities make public ways for non-members of the community to comment on their work.
>> 3.  From the outset allow comments on all ICG processes for transparency etc.
>> 4. As we receive each proposal, publish it as a draft for consideration and accept comments on those proposals as well as comments on how the proposals may work together.
>> 5. As we coordinate across the proposals to develop the NTIA submission allow comments across that process.
>> 
>> This could be considered inclusive without being disruptive or overwhelming. 
>> 
>> As to accountability, I would perhaps ask people to only comment on linkages that should be considered between IANA transition and the larger ICANN accountability question.  Issues specifically dealing only with ICANN accountability should be more appropriately routed to that committee.
>> 
>> Joe
>> 
>> 
>> On 8/2/2014 5:49 PM, Kavouss Arasteh wrote:
>>> 
>>> Dear All,
>>> 
>>> 
>>> Please FIND ATTACHED MY COMMENTS
>>> 
>>> 
>>> Regards
>>> 
>>> K.ARASTEH
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2014-08-02 23:15 GMT+02:00 Kavouss Arasteh <kavouss.arasteh at gmail.com>:
>>> Dear All,
>>> 
>>>  1) The draft ICG charter published in 17 July is  still a draft, it 
>>> is  not final until it is formally approved by ICG in its formal 
>>> first f2f meeting on 06 September ,due to the fact that there has been no ICG-approved  text yet tghus it is subject to further comments and modifications.
>>> 
>>>  2) Thus it appears that the ICG should take decisions regarding the 
>>> process  taking into account community comments.
>>>  ICG  should therefore make proposls regarding the process and to 
>>> submit them for public comment before deciding on any thing .
>>> 
>>>  3) As far as I can tell, the proposed process calls for proposals 
>>> from only the 3 customer communities of IANA - representing Names, 
>>> Numbers and  Protocol Parameters - which addresses certain aspects 
>>> of their own
>>> > individual community requirements/arrangements.
>>> > 
>>> > I don't see anything wrong with that, but I also don't see why 
>>> > those should be the only proposals.
>>> > 
>>> > In my view, the issue can also be approached globally, through a 
>>> > proposal that covers all three elements (names, numbers, and 
>>> > protocol parameters), and that also covers the related issue of 
>>> > ICANN's accountabily.  I recognize that the issue of ICANN's 
>>> > accountability is not in the scope of the ICG, but the ICG could 
>>> > note the relation between a proposal regarding IANA Stewardship and ICANN accountability.
>>> > 
>>> > Thus, if the process you outline below is the only way to submit 
>>> > proposals, then I think that it is too restrictive and will unduly 
>>> > reduce the breadth and scope of the proposals.
>>> > 
>>> > Further, I don't think that the process itself is broad enough, 
>>> > because not all members of the global multi-stakeholder community 
>>> > are members of the 3 communities mentioned above.  Thus they are 
>>> > not familiar with the processes used in those communities.
>>> > 
>>> > Asking them to contribute through those communities narrows the 
>>> > scope for inputs and, in my view, impoverishes the discussion.
>>> > 
>>> > Recall that, as I have indicated in my comments on the draft 
>>> > charter, NTIA did not ask ICANN to convene discussions within just 
>>> > the Internet community.  It asked ICANN to also consult the global 
>>> > multi-stakeholder community.
>>> 
>>> I guess we just disagree about the above. As I said in my note, it 
>>> is my sincere hope that no notion of "membership" prevents anyone 
>>> from participating, and also that anyone who needs help 
>>> participating can get it. The IETF certainly does not have membership.
>>> 
>>> 
>>> 2014-08-02 19:43 GMT+02:00 Alissa Cooper <alissa at cooperw.in>:
>>> 
>>> Hi Richard,
>>> 
>>> On 8/1/14, 11:54 PM, "Richard Hill" <rhill at hill-a.ch> wrote:
>>> 
>>> >Dear Alissa,
>>> >
>>> >Thank you very much for this.  Since you are the chair of the ICG, 
>>> >I consider your comments to be very important.
>>> 
>>> The chair discussion is ongoing, actually. Regardless, please do not 
>>> consider my comments to be any more important than those of any 
>>> member of the ICG. The chair role (and the interim chair role) is 
>>> functional and lends no additional credibility to the person in the 
>>> role (beyond the ability to deal with lots of logistics!).
>>> 
>>> >
>>> >What I deduce from your message below is that:
>>> >
>>> >1) The draft ICG charter published in 17 July is not actually a 
>>> >draft, it is final, at least with respect to the process for 
>>> >obtaining proposals for the transition.
>>> >
>>> >Although there has been no ICG-approved method for commenting on 
>>> >the draft charter, we know from messages on this list that there 
>>> >have beeen proposals to modify the draft charter.
>>> >
>>> >2) Thus it appears that the ICG (or at least its chair) is making 
>>> >decisions regarding the process without taking into account 
>>> >community comments.
>>> >
>>> >I would have expected the ICG to make proposls regarding the 
>>> >process and to submit them for public comment before deciding.
>>> 
>>> I'm not sure why you deduce the above. My message explicitly 
>>> described "[t]he thrust of my understanding of what the ICG has 
>>> proposed for a process going forward." Importantly, it described "my 
>>> understanding" of "what the ICG has proposed."
>>> 
>>> 
>>> >
>>> >3) As far as I can tell, the proposed process calls for proposals 
>>> >from the 3 customer communities of IANA - representing Names, 
>>> >Numbers and Protocol Parameters - which addresses certain aspects 
>>> >of their own individual community requirements/arrangements.
>>> >
>>> >I don't see anything wrong with that, but I also don't see why 
>>> >those should be the only proposals.
>>> >
>>> >In my view, the issue can also be approached globally, through a 
>>> >proposal that covers all three elements (names, numbers, and 
>>> >protocol parameters), and that also covers the related issue of 
>>> >ICANN's accountabily.  I recognize that the issue of ICANN's 
>>> >accountability is not in the scope of the ICG, but the ICG could 
>>> >note the relation between a proposal regarding IANA Stewardship and ICANN accountability.
>>> >
>>> >Thus, if the process you outline below is the only way to submit 
>>> >proposals, then I think that it is too restrictive and will unduly 
>>> >reduce the breadth and scope of the proposals.
>>> >
>>> >Further, I don't think that the process itself is broad enough, 
>>> >because not all members of the global multi-stakeholder community 
>>> >are members of the 3 communities mentioned above.  Thus they are 
>>> >not familiar with the processes used in those communities.
>>> >
>>> >Asking them to contribute through those communities narrows the 
>>> >scope for inputs and, in my view, impoverishes the discussion.
>>> >
>>> >Recall that, as I have indicated in my comments on the draft 
>>> >charter, NTIA did not ask ICANN to convene discussions within just 
>>> >the Internet community.  It asked ICANN to also consult the global 
>>> >multi-stakeholder community.
>>> 
>>> I guess we just disagree about the above. As I said in my note, it 
>>> is my sincere hope that no notion of "membership" prevents anyone 
>>> from participating, and also that anyone who needs help 
>>> participating can get it. The IETF certainly does not have membership.
>>> 
>>> Best,
>>> Alissa
>>> 
>>> >
>>> >4) I also note that, in your view, the composition of the ICG is 
>>> >arbitrary.
>>> >
>>> >Thanks again and best,
>>> >Richard
>>> >
>>> >> -----Original Message-----
>>> >> From: Alissa Cooper [mailto:alissa at cooperw.in]
>>> >> Sent: samedi, 2. août 2014 02:46
>>> >> To: Tamer Rizk; rhill at hill-a.ch; Stephen Farrell
>>> >> Cc: internal-cg at icann.org; ianatransition at icann.org; 
>>> >> ianaxfer at elists.isoc.org
>>> >> Subject: Re: [IANAxfer] [ianatransition] Jurisdiction (was 
>>> >> Composition of the ICG)
>>> >>
>>> >>
>>> >> Perhaps the problem here is that the viable path for 
>>> >>participation of any  interested party is evident to some but not 
>>> >>to others. I'm wondering if a  clarification would help. The 
>>> >>thrust of my understanding of what the ICG  has proposed for a 
>>> >>process going forward is explained below.
>>> >>
>>> >> There will be, at a minimum, three sets of processes for 
>>> >> developing components of the transition proposal:
>>> >>
>>> >> (1) An IETF process for developing the protocol parameters 
>>> >>component. As  with all IETF processes, it is open to anyone with 
>>> >>an email address. No  one is prevented from participating. If 
>>> >>people need help understanding how  to participate, the IETF ICG 
>>> >>appointees (as well as other experienced IETF
>>> >> participants) are here to help. The process uses well established  
>>> >>mechanisms for discussion and consensus-building that have been 
>>> >>used to  successfully craft thousands of documents over the years.
>>> >>
>>> >> (2) RIR processes for developing the numbers component. My 
>>> >>expectation  (which I'm sure will be corrected if wrong) is that 
>>> >>these processes will  also be open to anyone who wants to 
>>> >>participate. And again if people need  help understanding how, 
>>> >>there are folks who are committed to providing  that help.
>>> >>
>>> >> (3) A CCWG process for developing the names component. Again I 
>>> >>think the  only way this will work is if anyone is permitted to 
>>> >>participate, and I  haven't seen any indication that participation 
>>> >>will be somehow restricted.
>>> >> Unlike the other two components, this process is perhaps more 
>>> >>novel - but  certainly not more novel than any conceivable 
>>> >>alternative process the ICG  could run.
>>> >>
>>> >> If we have three sets of open processes where anyone can 
>>> >>participate,  where work and attention can be efficiently divided 
>>> >>so as to develop  focused proposals, where the ICG makes it a 
>>> >>priority to ensure that  coordination happens so that areas of 
>>> >>overlap get addressed within the  appropriate communities, and 
>>> >>where tried-and-trusted discussion and  consensus processes can be 
>>> >>leveraged, how is it possible than an arbitrary  group of 30 
>>> >>people in the ICG running a single centralized process created  de 
>>> >>novo for this purpose would produce a result that has broader 
>>> >>support  and better reflects the specific oversight/accountability 
>>> >>needs of the  various IANA functions?
>>> >>
>>> >> Alissa
>>> >>
>>> >> On 8/1/14, 4:47 PM, "Tamer Rizk" <trizk at inficron.com> wrote:
>>> >>
>>> >> >
>>> >> >Richard is spot on. The reason why many of us have had to 
>>> >> >curtail our feedback is that a viable path for our comments to 
>>> >> >be reflected in the output of this process is not evident. If we 
>>> >> >desire an outcome that is representative of a diverse set of 
>>> >> >stakeholder interests, then the ICG should function to publicly 
>>> >> >aggregate input from those sources, merge them into discrete, 
>>> >> >topic based proposals for review by the wider community, and 
>>> >> >offer a transparent mechanism by which to gauge both external 
>>> >> >and internal consensus. Otherwise, if the coordination group
>>> >>is
>>> >> >interested in drafting a proposal of its own accord, but would 
>>> >> >appreciate external feedback for internal deliberation, please 
>>> >> >refer to the previous suggestions herein.
>>> >> >
>>> >> >Richard Hill wrote:
>>> >> >> Please see below.
>>> >> >>
>>> >> >> Thanks and best,
>>> >> >> Richard
>>> >> >>
>>> >> >>> -----Original Message-----
>>> >> >>> From: Patrik Faltstrom [mailto:paf at frobbit.se]
>>> >> >>> Sent: vendredi, 1. aout 2014 15:57
>>> >> >>> To: rhill at hill-a.ch
>>> >> >>> Cc: Eliot Lear; Avri Doria; ianatransition at icann.org
>>> >> >>> Subject: Re: [ianatransition] Jurisdiction (was Composition
>>> >> of the ICG)
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> On 1 Aug 2014, at 12:01, Richard Hill <rhill at hill-a.ch> wrote:
>>> >> >>>
>>> >> >>>> I am proposing that the ICG assemble and summarize, and the
>>> >> >>> summary could well include a satement to the effect that 
>>> >> >>> proposals X, Y, and Z are consistent with, and accomodated, 
>>> >> >>> in consolidated proposal A, which can therefore be said to be 
>>> >> >>> a consensus proposal.
>>> >> >>>
>>> >> >>> Why would not parties first talk with each other and merge 
>>> >> >>> their respective proposals before sending it to the ICG?
>>> >> >>
>>> >> >> Of course they should.  But what is the role of the ICG if all 
>>> >> >> the coordination is done outside ICG?
>>> >> >>
>>> >> >>>
>>> >> >>> What you propose is for me not bottom up, but an informed top 
>>> >> >>> down process with consultations.
>>> >> >>
>>> >> >> Hunh?  What I propose is the usual process.  People make 
>>> >> >>inputs, an editor  collates them and produces a consolidated 
>>> >> >>draft.  People comment on
>>> >>the
>>> >> >> draft.  The editor produces a new draft, etc.
>>> >> >>
>>> >> >> If some of the stakeholders work together to agree a common 
>>> >> >>proposal, why  not.  But if nothing else is acceptable, then I 
>>> >> >>don't call that
>>> >>"bottom
>>> >> >>up",
>>> >> >> I call that "pre-cooked deal".
>>> >> >>
>>> >> >>>
>>> >> >>> Not good enough for me.
>>> >> >>>
>>> >> >>>> The ICG would then put that assembled proposal out for 
>>> >> >>>> comment,
>>> >> >>> as you say, and if they got it right, nobody would object to it.
>>> >> >>>
>>> >> >>> Saying no one would object to a proposal is of course 
>>> >> >>> something that will never happen. You know that as well as I do.
>>> >> >>
>>> >> >> There will surely be more objections at the end if people are 
>>> >> >>discouraged  from sending inputs and if their comments are not 
>>> >> >>reflected in the output in  some way (which may be an 
>>> >> >>explanation of why the input was not included).
>>> >> >>
>>> >> >>>
>>> >> >>>     Patrik
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> ianatransition mailing list
>>> >> >> ianatransition at icann.org
>>> >> >> https://mm.icann.org/mailman/listinfo/ianatransition
>>> >> >>
>>> >> >_______________________________________________
>>> >> >IANAxfer mailing list
>>> >> >IANAxfer at elists.isoc.org
>>> >> >https://elists.isoc.org/mailman/listinfo/ianaxfer
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> 
>>> 
>>> _______________________________________________
>>> 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
>> 
>> _______________________________________________
>> 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




More information about the Internal-cg mailing list