<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-ppsc-pdp] Re: comments on PPSC PDP WG Draft Final Report
- To: Gnso-ppsc-pdp@xxxxxxxxx
- Subject: Re: [gnso-ppsc-pdp] Re: comments on PPSC PDP WG Draft Final Report
- From: Avri Doria <avri@xxxxxxx>
- Date: Wed, 19 Jan 2011 12:16:56 -0500
+1
On 19 Jan 2011, at 11:47, Mike Rodenbaugh wrote:
> Based on this string, it seems best to wait until the next version of the
> report before reviewing.
> Mike Rodenbaugh
> RODENBAUGH LAW
> tel/fax: +1 (415) 738-8087
> http://rodenbaugh.com
>
> From: owner-gnso-ppsc-pdp@xxxxxxxxx [mailto:owner-gnso-ppsc-pdp@xxxxxxxxx] On
> Behalf Of Marika Konings
> Sent: Wednesday, January 19, 2011 6:32 AM
> To: Diaz, Paul; Neuman, Jeff
> Cc: Gnso-ppsc-pdp@xxxxxxxxx
> Subject: [gnso-ppsc-pdp] Re: comments on PPSC PDP WG Draft Final Report
>
> Thanks Paul and James for your feedback. Please see some initial comments
> below in blue in relation to some of your concerns.
>
> Marika
>
> From: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>
> Date: Wed, 19 Jan 2011 05:44:43 -0800
> To: Marika Konings <marika.konings@xxxxxxxxx>, "Neuman, Jeff"
> <Jeff.Neuman@xxxxxxxxxx>
> Cc: "Gnso-ppsc-pdp@xxxxxxxxx" <gnso-ppsc-pdp@xxxxxxxxx>
> Subject: comments on PPSC PDP WG Draft Final Report
>
> Hi Marika,
>
> James and I combined our comments/edits into the attached PPSC PDP WG Draft
> Final Report. Much of it is straightforward, but we do have a couple of
> significant concerns:
>
> In Section 1, Executive Summary:
>
> • RE: Recommendation 10 (starting on Line 190), we believe the WT
> should put forward a single recommendation – Option B. If the WT does not
> have consensus on this, then the Report should note the level(s) of support
> for the other options.
> MK: Please see the notes in the outstanding issues document. The WT agreed to
> include option 2 in a slightly modified form. This will be included in the
> next version of the report.
>
> • RE: Recommendation 15 (starting on Line 242), we thought the WT has
> come down AGAINST recommending a “fast track” procedure for PDPs. As such,
> we believe this Recommendation should be deleted from the Report.
> MK: Please see notes in the outstanding issues document. There was no
> consensus, but it was agreed to 'keep this issue open for the moment and
> discuss it in the near future after having reviewed again the comments
> received in relation to this issue'. This recommendation will be updated (or
> deleted) following this further discussion.
>
> • RE: Recommendation 22 (starting on Line 318), this sounds like a
> round-a-bout way to say “status quo.” We suggest deleting this text.
>
> v v RE: Recommendation 24 (starting on Line 335), we want to see the
> text flipped, i.e. “in scope” should be based upon contracted parties’
> definitions of Concensus Policies.” While an ideal and robust definition of
> "in scope" would see no difference between the perspectives on ICANN's scope,
> the simple reality is that no such definition exists. As “ICANN’s mission
> and the role of the GNSO” will always be open to different interpretations,”
> we don’t see how potential issues can be predictably “mapped” against the
> Bylawsand/or Affirmation of Commitments. If the other members of the WG
> areunwilling to change this formulation, then we cannot support the proposal
> and will want to see our strong opposition to the text duly noted.
>
> • RE: Recommendation 28 (starting on Line 368), we suggest including
> “and how the proposed PDP is aligned with ICANN’s Strategic Plan” to the end
> of the sentence. This will further prevent frivolous PDPs and unnecessary
> wasting of ICANN’s and the Community’s limited resources.
>
> • On Line 463, it appears the text is garbled. We’re not sure what
> really is being recommended here.
>
>
> In Section 2, all of our comments/edits apply (as most of the Executive
> Summary text appears to have been lifted from this section).
>
> In Section 3, RE: Translation (starting on Line 1076), the Report should note
> that ICANN should not default to paid translation, as this will incur more
> time and costs make. Rather, multi-lingual volunteers should be sought for
> (non-governing) translations of key documents. We offer suggested language
> at Line 1114. RE: Transition (starting on Line 1379), we think the WT
> settled this on our 13 January 2011 call, but need to see proposed text. In
> our view, simplicity favors the cut-in approach.
>
> In Section 4, RE: Basis for a new Annex A:
>
> • Is the WT proposing the wholesale replacement of the existing Bylaws
> section with the language we have developed? We realize that a lot of the
> existing text simply carries over, but are concerned that the Community will
> balk if/when we suggest an entire “rewrite.” Shouldn’t we just show the
> changes we’re proposing, so it’s easier for non-WT members to see the
> differences?
> MK: This is indeed what has been proposed (the wholesale replacement).
> • Weren’t we going to set all public comment periods at no less than 30
> days? If so, see edit at Line 1421.
> MK: Please see notes in outstanding issues document. WT agreed to 'Require
> public comment period of a minimum of 30 days for Issue Report and Initial
> Report, with a minimum of 21 days for other public comment periods a WG might
> choose to initiate'. This will be updated in the next version of the report.
>
> • At Line 1440, please clarify that we mean ICANN (the Corporation).
>
> • RE: Board Approval Processes (f) (starting at Line 1459), what is the
> point of a “tentative vote”? Board votes should not be taken lightly,
> especially in an age of significant resource constraints. If the Board is
> looking for input ahead of a formal vote, they have plenty of informal
> opportunities and communication channels to vet the Community’s positions.
> We strongly recommend deleting this sub-section (f).
>
> • In sub-section 9, Maintenance of Records (starting at Line 1492),
> please add our proposed clarifying text about what is expected.
>
> In Section 5, PDP Procedure Manual:
>
> • Suggest adding “Consistent with ICANN’s commitment to fact-based
> policy development,” to the beginning of Line 1532.
>
> • RE: sub-section 6.5, Creation of the Preliminary Issue Report
> (starting on Line 1558), shouldn’t the WT just offer a single option? We
> support Option #1. If there’s support for Option #2, please poll the WT and
> note the levels of support for each option. RE: the list if issues for the
> ICANN General Counsel to consider (Lines 1586-1599), should these be read
> with “and” connectors or with “or” connectors? We believe some kind of
> connectors should be used or else the GC is left free to pick and choose at
> his sole discretion. Finally, on Lines 1598-1599 please split the issues
> into two bullet points.
> MK: Please see notes in the outstanding issues document. This section will be
> updated according to the WT agreement in the next version of the document.
>
> • Again, for consistency, aren’t all public comment periods through the
> Report to be “no less than thirty (30) days” (see Line 1738)?
> MK: As noted before, this will be updated in the next version of the report
> according to the WT agreement.
>
> • RE: sub-section 6.12, Expedited PDP Procedures, didn’t the WT move
> away from supporting such a process? If so, this sub-section should be cut
> (again, as we suggested re: deletion of Recommendation #15). If it stays in,
> we believe the Council threshold to approve a “fast track” PDP should be a
> super-majority vote of BOTH houses. Otherwise, we raise the possibility that
> this mechanism will easily over-used/abused.
> MK: As noted before, this will be updated in the next version of the report
> according to the WT agreement.
> • RE: sub-section 6.16, Termination of PDP Prior to Final Report, the
> WT discussed this at the 13 January 2011 call. We still need to see proposed
> text, but offer some suggested edits consistent with where we believe the WT
> came down.
> MK: Please see notes in the outstanding issues document. This will be updated
> in the next version of the report according to the WT agreement.
>
> Best regards, P
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|