[Internal-cg] Revised RFP

Subrenat, Jean-Jacques jjs at dyalog.net
Mon Aug 18 15:17:15 UTC 2014


Agree with Manal's position.
Jean-Jacques.


----- Mail original -----
De: "Manal Ismail" <manal at tra.gov.eg>
À: "Paul Wilson" <pwilson at apnic.net>, "James M. Bladel" <jbladel at godaddy.com>
Cc: "ICG" <internal-cg at icann.org>
Envoyé: Lundi 18 Août 2014 01:39:57
Objet: Re: [Internal-cg] Revised RFP


I see your point Paul and agree that "as many iterations as we can" is
too much to ask within the tight timeframe we have but, to the extent
possible, even one more shorter public comment period may help us
resolve issues and increase consensus .. Anyway, if this won't be
feasible then I support the approach you suggested below, and agree that
it's early to guarantee since we have no idea how many proposals we will
receive ..

Kind Regards
--Manal

-----Original Message-----
From: Paul Wilson [mailto:pwilson at apnic.net] 
Sent: Monday, August 18, 2014 2:05 AM
To: Manal Ismail; James M. Bladel
Cc: Milton L Mueller; ICG
Subject: Re: [Internal-cg] Revised RFP



> Dear All ..
>  
> I still have to go through the latest version of the RFP but would
like to make a few remarks in light of this thread of discussion:
> -          Like Mohamed, Adiel and maybe others, I hope we can
encourage and convince the community with the importance and benefits of
early discussions and consolidated submissions without setting a hard
limit of 3 or 4 proposals; which I believe is somehow reflected in the
sentence referenced in Milton's email below .. I also support changing
"expected" to "required"  as suggested by Milton ..
> -          Similar to what Martin said regarding ccTLDs who do not
engage with ICANN, there may be also governments who do not engage with
ICANN and still want to submit their views .. Moreover there may be
governments who already engage with ICANN and would still like to put
their proposals on record .. I'm not saying this should be encouraged
but saying we cannot but accept such submissions ..
> -          The above suggestions do not diminish the importance of the
3/4 proposals of the operational communities ..
> I do apologize if the above points have already been addressed and
settled ..   

I agree with Manal's 3 points above.

>  
> Furthermore, I believe it's important to discuss Milton's below
statement which summarizes the situation perfectly well .. I believe ICG
should not "make a decision limiting who can submit" (rather encourage
and convince) .. On the other hand ICG should, to the extent possible,
avoid making "a decision about which proposals are selected" as it
already has a limited role of integrating and consolidating all inputs
into one proposal .. Accordingly, in case of conflicting views,
selections may be settled either by how broadly a proposal is supported
or preferably by reverting back to the (relevant) communities to make
the choice .. In all cases, in a perfect situation, we should work on
allowing iterations of public comment periods (as many as needed and as
time allows) to fine tune the final proposal, make selections whenever
necessary and ensure broadest community support ..

Agreed regarding the theoretical perfect situation, but we cannot rely
on the communities to grant us this luxury.  I believe we will
inevitably need to make judgements/decisions at some level (as James
said), and the difficult of doing that will depend on the specifics.


On submissions, I think we cannot rule out anyone in advance; we can
only strongly direct people to community processes.  Can we draw a clear
distinction between the sources of proposals: for instance while we will
work to fully reconcile the community proposals, we will consider other
proposals and make best efforts to incorporate them, and attempt to note
where this has not been possible (and all will go on the public record
of course).  We should probably also note that we will work within the
target timeframes established, and make our best efforts to fully
consider all inputs received.  It is not possible to guarantee this when
we have no idea how many proposals we will see.


Paul.

>  
> Kind Regards
> --Manal
>  
> From: internal-cg-bounces at icann.org
[mailto:internal-cg-bounces at icann.org] On Behalf Of James M. Bladel
> Sent: Friday, August 15, 2014 7:51 PM
> To: Milton L Mueller; internal-cg at icann.org Internal
> Subject: Re: [Internal-cg] Revised RFP
>  
> Interesting points, Milton.  Especially with regard to:
>  
> "So, take your pick: make a decision limiting who can submit, or make
a decision about which proposals are selected."
>  
> Personally I do not believe the ICG can totally insulate itself from
making material decisions (or "choices") on the proposals, regardless of
the path chosen.  Even if submissions are limited to the smallest
possible number, there are bound to be minor differences between them
that require some degree of reconciliation by the ICG.
>  
> Thanks-
>  
> J.
>  
>  
>  
>  
>  
> From: Milton L Mueller <mueller at syr.edu>
> Date: Friday, August 15, 2014 at 11:38 
> To: ICG List <internal-cg at icann.org>
> Subject: Re: [Internal-cg] Revised RFP
>  
> I've reviewed v 0.7 with comments of Martin, Mohamed and Adiel, and am
also addressing Russ Mundy's observations on the RFP.
>  
> First, an easy issue: nothing in the language referring to the IANA
contract implies that anyone is "bound" by anything. It simply uses the
current IANA contract as a uniform point of reference. Let me reproduce
the language here:
>  
> "In the interest of consistency, each community is encouraged to
review and consider the current IANA Functions Contract between NTIA and
ICANN when describing existing arrangements and proposing changes to
existing arrangements."
>  
> I think that is clearly just asking for a consistent point of
reference and we can dispose of this "don't bind the operational
communities" issue completely.
>  
> The more difficult issue concerns the leading role of the operational
communities and the possibility of multiple submissions. This problem
challenges the concept that the ICG is a "non-decisional" body. If we
decide who can and cannot submit proposals, we are in fact making a
critical substantive decision, one that profoundly influences the nature
of the proposals. On the other hand, if we allow or encourage proposals
by anyone and everyone who feels like submitting one, we are put into
the position of selecting among them and even modifying/reassembling
them.
>  
> So, take your pick: make a decision limiting who can submit, or make a
decision about which proposals are selected.
>  
> I actually think the current draft finds the appropriate middle ground
between this Scylla and Charybdis. It strongly encourages everyone to
work together in an operational community-led process, but does not
expressly prohibit other proposals. Here is the language:
>  
> During the development of their proposals, the operational communities
are expected to consult and work with other affected parties; likewise,
other affected parties are strongly encouraged to participate in
community processes, as the ICG is requiring proposals that have
consensus support from a broad range of stakeholder groups.
>  
> Only change I would suggest is that we change "expected" to "required"
in the first line.
>  
> To Mohamed, I would say that the operational communities HAVE TO be
considered the primary stakeholders in the transition, because they are
the people who rely on the IANA functions in a direct, operational sense
and its functionality and responsiveness  is a life or death matter for
them.
> --MM
>  
> From: internal-cg-bounces at icann.org
[mailto:internal-cg-bounces at icann.org] On Behalf Of Martin Boyle
> Sent: Friday, August 15, 2014 11:28 AM
> To: Mohamed El Bashir; internal-cg at icann.org Internal
> Subject: Re: [Internal-cg] Revised RFP
>  
> Hi All,
>  
> Mohamed beat me to it, so I have applied the amendments/comments I was
working on on top of his and posted back in dropbox.
>  
> I'd like to make a couple of explanatory notes, though:
>  
> 1.      There seems to be a tendency to widen the number of fronts:  I
am concerned that, if we open to all stakeholder communities, we are
essentially bypassing the focus on the three functions as centres of
thinking.  The more I have thought about this, the more I see little
value for any community NOT to submit its own proposal(s) whereas we
really need the different groups to work with all affected stakeholders
on their bit of the puzzle.  I thought (really believed) that were
working on the operational lead approach expecting each to adopt its own
process with its affected parties and other stakeholders.  I hope that
we can keep to this approach.
>  
> 2.      I've noted in a previous mail on this document that there are
a number of ccTLDs who do not (and will not) engage with ICANN.  I'm
happy for us not to encourage individual or small-group submissions, but
we have to understand that there is a high probability that we will get
input, so there is no point in trying to discourage them.  But we do
need to think about how this might be dealt with and pose our questions
to the wider community in a different form.  One way might be to offer a
"fast track" approach to identify specific problems or requirements that
they feel need to be addressed.
>  
> 3.      I was left puzzled by references to an input from Daniel which
I was not able to find.  I have commented on this paragraph somewhat in
the dark (apologies if I've missed the point), but it does seem to me to
be important for us to use the current NTIA/ICANN as the current basis.
This is then reflected in a couple of comments in the last section, on
maintaining the framework for service delivery and on the clear
separation of policy responsibility from the IANA.
>  
> By the way, is it v0.7 (as in the file title) or v0.6 (as in the
document)?
>  
> Thanks
>  
> Martin
>  
> _______________________________________________
> 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