RE: [gnso-raa-b] Task 2 -- for our discussion April 15

["Metalitz, Steven" <met@xxxxxxx>]

As previously noted, at some point  in the process leading up to the
last round of RAA amendments (late 2007?  the document is undated) the
ICANN staff listed those proposed topics that they considered "either to
be under discussion in the context of a Consensus Policy already or,
otherwise because of their nature, could/should be handled through the
Consensus Policy process." See
http://www.icann.org/en/topics/raa/comment-summary.html. 

A quick run through this list suggests that few of these topics are
included in the compilation we are working from, and most of those that
are in our matrix we have already "flagged" under task 2.  

I'd call your attention to item 9 below.  While the precise topic is
uncertain, it is interesting that in this round the staff has proposed
at least one topic that may overlap with the topic they pushed off the
table last round.  

One conclusion we might draw from this list is that we are doing a
pretty good job so far in anticipating which topics the staff, at least,
might consider "flaggable" under task 2.  That does not mean, of course,
that we necessarily agree with the staff's determination on this issue.
The main outlier MIGHT be item 6.9 (verification of registrant data).  

Below is the list from the 2007 (?) staff document.  I have [bracketed]
those that do not appear to overlap with anything on our matrix.  The
others I have annotated.  Of course I welcome your corrections, comments
or questions.  

        1.      [ICANN should establish or provide a dispute resolution
mechanism for unauthorized changes of registrant ]
        2.      ICANN should require registrars to verify registrant
identity. NOTE: See 6.9 of our matrix.    
        3.      Registrars should be prohibited from registering and
otherwise acquiring domain names and should be divested of domain name
registrations NOTE: See 2.2. of our matrix, which we have already
flagged under task 2.  
        4.      [ICANN should create a registrar shared database of
"invalid" domain names]
        5.      Require adherence to Consensus Policy - eliminate post
expiration loopholes (Staff note: Consensus Policy compliance
enforcement already exists, further limitations to existing policy would
require the adoption of additional Consensus Policies) NOTE:  The second
phrase may overlap with items 10.1 and 10.2 of our matrix, where we have
noted PEDNR involvement and assigned low priority.  
        6.      [ICANN should assure that a centralized Whois be
established that is searchable to benefit UDRP complainants] 
        7.      ICANN should reconvene the Technical Steering Committee
to introduce competition into the RGP  NOTE:  May overlap with 10.5 of
our matrix, where we have noted PENDR and assigned low priority. 
        8.      Require verification by mail of a registrant's address
prior to activating domain name .  NOTE:  See 6.9 of our matrix.
        9.      Establish registrar action deadlines for dealing with
registrant non-compliance .  NOTE: Not clear, but note that some staff
proposals in our matrix incorporate action deadlines (see e.g. item
3.1).  
        10.     [Enable registrars to do mass deletions of names
registered by proven serial spammers and block attempts at future
registrations] 
        11.     Contact data should be verified at the time of
collection.  NOTE:  See item 6.9 of our matrix.  
        12.     [While the obligations of registrars for what regards
transfers are implicit in their obligations to abide by ICANN consensus
policies, we think that, given the extreme importance of this policy, it
would be useful to add a clear reminder in the RAA, under the form of a
clause saying something like "The registrar recognizes the right of the
registrants to transfer their domain names to other registrars,
according to the policies established by ICANN, and commits to make the
process of transferring domain names as simple and quick as possible,
and not to unreasonably stifle this opportunity in any way." ]
        13.     [We ask that the GNSO Transfer Policy include specific
requirements to enable transfer of domain names. Registrants should be
able to process a transfer entirely through the services of the gaining
registrar and/or the registry, without the need for action by the losing
one, including obtaining Auth-Info codes and the like when required. ]
        14.     [We ask that the GNSO Transfer Policy forbid losing
registrars to require an extra fee or paperwork to transfer their domain
names. Since the entire transfer process can be automated, its
operational cost is so low to be covered by the registration fee, and
there is no cost justification for extra fees.] 

    

Steve Metalitz

________________________________

From: owner-gnso-raa-b@xxxxxxxxx [mailto:owner-gnso-raa-b@xxxxxxxxx] On
Behalf Of Metalitz, Steven
Sent: Wednesday, April 14, 2010 6:08 PM
To: Hammock, Statton; Tim Ruiz; gnso-raa-b@xxxxxxxxx
Subject: [gnso-raa-b] Tasks 2 and 3 -- for our discussion April 15 


Thanks to Tim and Statton for their observations on tasks 2 and 3 of our
subteam. Of course we will discuss these on our call tomorrow, along
with the memo circulated by Margie, which I think takes a different
view.  I hope that a member of the Legal Staff, or someone authorized to
speak on their behalf, will attend tomorrow.   In the meantime, let me
offer a few reactions.  
 
 First, let's review what these tasks are:  
 
(1) Identify topics on which further action in the form of amendments to
the RAA may be desirable.
(2) From list (1), flag any topics that may require further analysis as
to impact on consensus policy.
(3) Propose next steps for considering such topics.
 
Source:  
http://gnso.icann.org/drafts/raa-drafting-team-charter-03sep09-en.pdf
<http://gnso.icann.org/drafts/raa-drafting-team-charter-03sep09-en.pdf> 
as cited in GNSO resolution 20090903-3
<http://gnso.icann.org/meetings/minutes-03sep09.htm> 
 
See also
https://st.icann.org/raa-related/index.cgi?draft_raa_drafting_team_chart
er. 
 
Let's also recall that over the past several months, we have been
attempting to proceed on tasks 1 and 2 in tandem. Subteam members were
consistently asked to flag items for task 2 as we reviewed them for task
1 as we walked through our compilation document.  
 
I read what Tim and Statton are suggesting as saying, every topic that
we have identified in task (1) is a topic "that may require further
analysis as to impact on consensus policy."  That seems to me to be the
same thing as asking the legal staff to "identify the items from our
list that require a consensus policy process."  
 
Today we have also received a document from staff that includes the
following:  
 
"The form of the RAA that may be approved by the GNSO Council may
include topics that are within the scope of "Consensus Policies" as
specified under Section 4.2 of the RAA as well as other possible topics.
Notwithstanding the broad nature of amendments that can be included in
the new form of the RAA, Staff recommends that the RAA Drafting Team
evaluate whether a proposed amendment topic is more appropriately
addressed through a formal PDP on the specific topic rather than through
the existing RAA amendment process."
 
The staff seems to be saying the opposite of what Statton and Tim are
recommending.  Statton and Tim seem to be saying, let the legal staff
decide which "proposed amendment topic is more appropriately addressed
through a formal PDP on the specific topic rather than through the
existing RAA amendment process."  The ICANN staff are saying that the
"Drafting Team" should evaluate this.  That also, in my view, is more
consistent with what our charter says (task (2)).  
 
Statton notes that "during the last round of amendments, Kurt P. gave
ICANN's opinion on which proposals required consensus policy."  Of
course, during the last round, the process we are going through did not
exist in the same form.  Instead, proposed topics for RAA amendments
were solicited through a public comment period.  The staff then reviewed
these topics, and concluded that 14 proposed topics for RAA amendments
as "considered by staff either to be under discussion in the context of
a Consensus Policy already or, otherwise because of their nature,
could/should be handled through the Consensus Policy process."  See
http://www.icann.org/en/topics/raa/comment-summary.html.   At a quick
glance, there is only a little overlap between this list of 14 and the
items in our compilation.  
 
My sense is that the Council wanted to have some input, this time
around, into the decision of whether a particular topic should not be
considered as an RAA amendment because it "could/should be handled
through the Consensus Policy process."  In the last cycle, they did not
have a chance to provide that input.  That, it seems to me, is why they
asked us to "flag" such topics in our report.  I would be reluctant to
shirk that assignment. But I look forward to hearing all the points of
view tomorrow.  
 
Let me turn briefly to task 3.  I appreciate Tim coming forward with a
counter-proposal to my original "straw man" on this topic, and I agree
that if affected parties other than the registrars and ICANN are to be
excluded from the negotiations, then there needs to be a "reiterative
process" by which those excluded are kept closely informed of the
negotiations. But I for one am not yet ready to accept the premise that
such an exclusion is required.  I accept that the final agreement on
amendments will be made between the registrars and the staff, but I do
not believe that other affected parties should be limited to the post
hoc role to which they were relegated last time.  That is why we exist,
because the process used last time was not deemed acceptable by many on
the Council.  
 
Rather than a closed room,  from which the contracting parties emerge
from time to time to tell us what they think we need to know about the
negotiation, I suggest we consider a more open room, from which the
contracting parties can excuse themselves from time to time when there
is demonstrated need to do so in order to bring confidential information
to the negotiating table.   
 
Another approach might be to accept representatives of the affected
parties as "observers" to the negotiation, in the same sense that
"observers" function in the GNSO processes generally.  
 
I look forward to discussing these options with subteam members
tomorrow.  
 
Steve Metalitz
 

________________________________

From: owner-gnso-raa-b@xxxxxxxxx [mailto:owner-gnso-raa-b@xxxxxxxxx] On
Behalf Of Hammock, Statton
Sent: Wednesday, April 14, 2010 3:02 PM
To: Tim Ruiz; gnso-raa-b@xxxxxxxxx
Subject: RE: [gnso-raa-b] Update on next steps and apologies



I'd like to support Tim's proposal to ask John Jeffrey or others on
ICANN's Legal Staff to identify the items from our list that require a
consensus policy process.  I believe someone acknowledged in the early
days of the WG, that the members wouldn't be able to agree on which
items were inside or outside of the "picket fence" so I think it's a
good idea to ask Staff to do this.  Also, I understand that during the
last round of amendments, Kurt P. gave ICANN's opinion on which
proposals required consensus policy so I think there is precedent for
this. 

 

Statton

 

 Statton Hammock 

 Sr. Director, Law, Policy & Business Affairs 

P 703-668-5515  M 703-624-5031 www.networksolutions.com

 

 

-----Original Message-----
From: owner-gnso-raa-b@xxxxxxxxx [mailto:owner-gnso-raa-b@xxxxxxxxx] On
Behalf Of Tim Ruiz
Sent: Wednesday, April 14, 2010 12:16 PM
To: gnso-raa-b@xxxxxxxxx
Subject: [gnso-raa-b] Update on next steps and apologies

 

 

I apologize, but it looks like I may not be able to make the call

tomorrow, although I still intend to try. So I'd like to offer some

thoughts on what we discussed last call, and another idea.

 

There were a few ideas put forward regarding the next steps I proposed

on the last call. As I noted, the RrSG feels strongly that only the two

parties to the agreement should be involved in the actual negotiations.

However, as discussed if there is a reiterative process that would keep

the community more informed and involed we would be open to that. If

there is anything specific we can define in that regard it would be

helpful in keeping things moving forward on this.

 

I would also like to make a proposal on another open issue, identifying

those items that would require the consensus policy process. Instead of

us trying to hash that out, we should ask John Jeffrey to do that for

the group. I know some work may have been done on that, but it should be

reviewed by John for his opinion.

 

 

Best,

 

Tim