ICANN ICANN Email List Archives

[gnso-rapimpl-dt]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-rapimpl-dt] For review - updated letter to the GNSO Council

  • To: "'Greg Aaron'" <gaaron@xxxxxxxxxxxx>, "'Marika Konings'" <marika.konings@xxxxxxxxx>, <gnso-rapimpl-dt@xxxxxxxxx>
  • Subject: RE: [gnso-rapimpl-dt] For review - updated letter to the GNSO Council
  • From: "Berry Cobb" <berrycobb@xxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 10 Nov 2010 11:46:53 -0800

Hi all,

 

Greg,

.         +1 on your 1st bullet.

.         +1 on your 2nd bullet.  I checked the old matrix responses and
could not find mention of a WHOIS dependency to Cybersquatting, nor do I
recall how it was added.  It must have been during our discussions on the
call.  I do not agree that this is a dependency and should be removed.

 

One other bit of feedback on the letter...

 

Because we have 5 recommendations labeled with "Refer to Council," I suggest
we be more explicit in advising the GNSO Council what "Refer to Council"
really means.  I reference the 4th sentence in the Recommended Approach
section.  I think it will benefit to advise the Council that they should
perform the following:

1.       review each section of the RAP Final report that corresponds to
recommendation, where significant consensus was not achieved

2.       request for additional input or research to become better informed
of the recommendation (optional)

3.       and then vote  the recommendation up or down and bring closure

4.       any others we should include???

 

.and now for a question of probability..

 

Not having experienced how the GNSO Council approves or declines multiple
recommendations from a pre-PDP, I begin to ponder the possibility of a
recommendation with "unanimous consensus" from the RAP WG and High
prioritization by the RAPIMP team NOT being passed by the GNSO Council.  We
were chartered with prioritizing recommendations that had yet to be approved
or denied for action; so I am curious if there were underlying assumptions
to priority assignments where unanimous consensus correlated to Council
approval.

 

Many kudos to Marika, Greg & Mikey for this effort.  In fact, I think this
should be defined as a closing deliverable for all PDP Final reports before
submission to Council.

 

 

Berry Cobb

Infinity Portals LLC

berrycobb@xxxxxxxxxxxxxxxxxxx

http://infinityportals.com

720.839.5735

 

From: owner-gnso-rapimpl-dt@xxxxxxxxx
[mailto:owner-gnso-rapimpl-dt@xxxxxxxxx] On Behalf Of Greg Aaron
Sent: Wednesday, November 10, 2010 8:27 AM
To: 'Marika Konings'; gnso-rapimpl-dt@xxxxxxxxx
Subject: RE: [gnso-rapimpl-dt] For review - updated letter to the GNSO
Council

 

Hello; two items:

 

1.       Under the Malicious Use entry, the notes say "Preference for PDP
approach even if desired outcome is not policy but best practices."  The
"if" is confusing, since it accidentally implies that policy is a possible
outcome.   I suggest: "Preference to use PDP process; outcome to be best
practices."

 

2.       Cybersquatting: the notes section says "There may be a dependency
with WHOIS studies."  I can't remember what that dependency was.  Can anyone
refresh my memory?

 

All best,

--Greg

 

 

 

From: Marika Konings [mailto:marika.konings@xxxxxxxxx] 
Sent: Monday, November 08, 2010 2:00 PM
To: gnso-rapimpl-dt@xxxxxxxxx
Subject: [gnso-rapimpl-dt] For review - updated letter to the GNSO Council

 

Dear All,

 

Following today's meeting, please find attached the latest version of the
proposed letter to the GNSO Council which incorporates the edits discussed
on the call.You'll find attached a clean as well as a redline version.
Please review the letter carefully. You are requested to share any comments,
edits, suggestions on the mailing list prior to next week's call. The
objective of the next meeting is to finalize the letter and submit it to the
GNSO Council immediately following the call to meet the 15 November
publication deadline for Cartagena.

 

Thanks,

 

Marika



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy