Re: [bc-gnso] RE: UPDATED DRAFT BC Public Comments on DAGv4

[Jon Nevett <jon@xxxxxxxxxx>]

Sounds good.  Would like that.  Thanks Ron.

On Jul 19, 2010, at 12:26 PM, Ron Andruff wrote:

> Jon,
>  
> That addition was submitted by Jeff Bruegeman (AT&T), but it was meant as a 
> supporting statement to the Economic Framework, i.e., NOT based on 
> categories.  It is not meant to roll back the clock.
>  
> Regarding the “in line with past positions” refers to the fact that the BC is 
> consistent in its desire to see an orderly rollout versus being a 
> constituency stuck in history.
>  
> Can you and I take this offline and work through language that you feel is 
> more definitive?
>  
> RA
>  
> Ronald N. Andruff
> President
>  
> RNA Partners, Inc.
> 220 Fifth Avenue
> New York, New York 10001
> + 1 212 481 2820 ext. 11
>  
> From: Jon Nevett [mailto:jon@xxxxxxxxxx] 
> Sent: Monday, July 19, 2010 12:09 PM
> To: Ron Andruff
> Cc: bc-GNSO@xxxxxxxxx
> Subject: Re: [bc-gnso] RE: UPDATED DRAFT BC Public Comments on DAGv4
> Importance: High
>  
> Ron:
>  
> I just took a quick look at the document and unless I am mistaken, It looks 
> like there was at least one material change to at least the first document.  
> For example, I do not recall seeing the following sentence in any of the 
> prior versions.  
>  
> "Therefore the BC recommends that ICANN continue its practice of introducing 
> new gTLDs and IDNs in discrete, limited rounds."
>  
> I don't support this insertion.  It is unclear.  Does this mean the BC agrees 
> or not with the implementation plan in DAGv4, which includes discrete rounds. 
>  Or does it mean that the BC supports some kind of rounds based on categories 
> or applicants?  Such a model would take us back to days of ICANN staff and 
> board conducting beauty contests either by application or by category.  We 
> rejected this approach at the GNSO recommendation level and shouldn't go back 
> to it.  
>  
> I haven't looked closely enough to see if there are other changes in this new 
> document.  
>  
> Also, I don't support attaching the prior comments to these comments.  Our 
> comments should be able to evolve with the passage of time.  If we just want 
> to repeat ourselves, then it is appropriate to attach prior comments.  In 
> this case, however, we shouldn't just support a position simply because we 
> did so last year.  Indeed, why must the BC post comments "in line with past 
> positions?"  Can't the BC change its mind on an issue?  We shouldn't just 
> regurgitate old arguments simply because they were supported historically.  
>  
> My two cents.  
>  
> Thanks.
>  
> Jon
>  
>  
> On Jul 19, 2010, at 11:13 AM, Ron Andruff wrote:
> 
> 
> Dear colleagues,
>  
> Pursuant to the comments that have been sent in, as rapporteur for this 
> process, I have incorporated the amendments and prepared two final documents 
> for your review and comment.  Two documents, insomuch as I broke the original 
> comments into two separate postings so that the BC membership can work 
> through the issues accordingly.  As Philip Sheppard noted, the BC must post 
> its comments in line with past positions.  Splitting the documents hopefully 
> enables focused discussion on the RPM piece without impeding posting the 
> other comments.
>  
> The first document incorporates a slimmed down version of the original 
> comments I posted last week on the issues of ‘market differentiation’, 
> ‘translation of ASCII to other scripts’ and ‘revised community priority 
> evaluation scoring’, with the BC’s DAGv3 comments attached for reference.  It 
> should be noted that I have made no material changes in these comments; 
> rather I simply tightened up the arguments and cleaned up typos, etc.
>  
> The second document is effectively Jon’s edits on RPMs.  I have made no 
> changes to his edition other than made the correction (‘complainant’ vs. 
> ‘registrant’) that Phil Corwin noted in his recent posting to the list.
>  
> Once again, I welcome comments/amendments to finalize these two documents for 
> posting.
>  
> Kind regards,
>  
> RA
>  
> Ronald N. Andruff
> President
>  
> RNA Partners, Inc.
> 220 Fifth Avenue
> New York, New York 10001
> + 1 212 481 2820 ext. 11
>  
> From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of 
> Phil Corwin
> Sent: Monday, July 19, 2010 10:39 AM
> To: Jon Nevett; Zahid Jamil
> Cc: 'Deutsch, Sarah B'; michaelc@xxxxxxxxxxxx; mike@xxxxxxxxxx; 
> jb7454@xxxxxxx; randruff@xxxxxxxxxxxxxxx; ffelman@xxxxxxxxxxxxxxx; 
> bc-GNSO@xxxxxxxxx
> Subject: RE: Re[2]: [bc-gnso] DRAFT BC Public Comments on DAGv4
>  
> ICA believes that John's redraft is a significant improvement in many ways.
>  
> However, we do continue to have some concerns about the URS section, 
> specifically:
> We can't support the transfer option, as suspension versus transfer was one 
> of the major distinctions between URS and standard UDRP as originally 
> proposed by the IRT -- that is, URS was supposed to be for rapid, lower cost 
> blocking of a domain in slam dunk cases, with UDRP reserved for less clear 
> cut cases as well as instances where the complainant wished to permanently 
> acquire the domain. We think it's important to preserve that distinction and 
> that problems with the use of the UDRP for default cases should be addressed 
> by comprehensive UDRP reform.
> We don't agree that the language asserting that the "impact" test is too low 
> for a finding of abuse of process. The exact language now in the DAG is --
>             "An Examiner may find that Complaint contained a deliberate 
> material falsehood if it
>             contained an assertion of fact, which at the time it was made, 
> was made with the
>             knowledge that it was false and which, if true, would have an 
> impact on the outcome on
>             the URS proceeding."
>  
> What this says is that if a complainant deliberately lied about a material 
> fact in order to influence the outcome of a URS in its favor it will suffer a 
> penalty in order to protect the integrity of the overall process. The penalty 
> for one such deliberate lie is being suspended from using the URS for one 
> year; the penalty for two such lies is permanently barring it from use of the 
> process. Now, as a practical matter, it will be the rare case where the 
> examiner is able to conclude that the complainant deliberately misrepresented 
> material facts, so this isn't going to happen very often, plus there are no 
> monetary sanctions - including fines or a requirement that the complainant 
> pay the registrant's costs of defending the domain - so it isn't as severe a 
> pernalty as some called for it to be. If the BC is going to say that the 
> impact test is too low (with which we don't agree) then I think it has some 
> responsibility to propose an alternate tests that protects the integrity of 
> the URS against the (hopefully rare) complainant who deliberately seeks to 
> abuse it.
>  
>  
> As a typographical matter, the last portion of the last sentence of the first 
> URS paragraph should read "less certainty for the complainant using this 
> process", not "registrant". 
>  
> Finally, we appreciate the serious and civil debate that has been taking 
> place within the BC on this matter -- this is precisely what should occur 
> within a constituency to bridge differences in perspective.
>  
> Philip S. Corwin 
> Partner 
> Butera & Andrews 
> 1301 Pennsylvania Ave., NW 
> Suite 500 
> Washington, DC 20004
> 202-347-6875 (office) 
> 202-347-6876 (fax)
> 202-255-6172 (cell)
> "Luck is the residue of design." -- Branch Rickey
> From: Jon Nevett [jon@xxxxxxxxxx]
> Sent: Sunday, July 18, 2010 9:39 PM
> To: Zahid Jamil
> Cc: 'Deutsch, Sarah B'; Phil Corwin; michaelc@xxxxxxxxxxxx; mike@xxxxxxxxxx; 
> jb7454@xxxxxxx; randruff@xxxxxxxxxxxxxxx; ffelman@xxxxxxxxxxxxxxx; 
> bc-GNSO@xxxxxxxxx
> Subject: Re: Re[2]: [bc-gnso] DRAFT BC Public Comments on DAGv4
> 
> Folks:
>  
> Attached is a suggested redraft to bridge the gap.  I personally don't agree 
> with some of the arguments I left in the attached, but I tried to keep the 
> longstanding BC positions while toning down the anti-TLD language.  I also 
> deleted a couple of the arguments that were objected to in some of the notes 
> I reviewed.
>  
> Here are some of the highlights:
>  
> *I deleted the GPML section.
>  
> *I deleted the clear and convincing evidence issue with regard to the URS.  
> As a member of the IRT, I can say that it clearly was our intent for the URS 
> to have a higher burden of proof  than the UDRP -- the legal standard is 
> exactly the same.  We wanted the URS to be for "slam dunk" cases.  The URS 
> was to be a less expensive alternative to the UDRP cognizant of the fact that 
> 70% of UDRPs go unanswered.  Has this issue even been raised before by the BC?
>  
> *Based on Sarah's helpful e-mail, I left alone the complaint about 
> transferring names after a successful URS as that has been an issue that 
> Zahid, Mike and others in the BC have argued consistently.  I do note, 
> however, that transfer was not in the IRT recommendation and the STI agreed 
> to add a year to the registration at the request of the complainant as a 
> compromise.  
>  
> *Again based on Sarah's e-mail, I left the PDDRP section pretty much alone 
> except for an argument about registries warehousing names, but not using 
> them, as that argument didn't make much sense to me.  That's exactly the 
> function of a registry to warehouse names until they are sold by registrars.  
> If a registry "reserves" a name and it is not in use at all, the mark holder 
> should be thrilled that it can't be registered by a squatter.
>  
> *I also deleted the paragraph about the Director of Compliance.  I don't 
> think it appropriate to comment on those kinds of personnel matters. 
>  
> *I didn't touch the arguments related to community and 13 points (though I 
> personally favor 14 points to avoid gaming -- sorry Ron), as that seems to be 
> longstanding BC position.
>  
> *I didn't do much on the Market Differentiation section either other than 
> soften some of the language.
>  
> I have no idea if my attempt will get consensus or not, but I thought it 
> worthwhile to offer alternative language and I tried hard to find a balance.  
>  
> Thanks.
>  
> Jon
>  
> <DRAFT BC Pub Comm 1-3 DAGv4 - (RA).doc><DRAFT BC Pub Comm 4  DAGv4 - 
> (SD-JN).doc>
>