ICANN ICANN Email List Archives

[bc-gnso]


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

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

  • To: "'Jon Nevett'" <jon@xxxxxxxxxx>
  • Subject: RE: [bc-gnso] RE: UPDATED DRAFT BC Public Comments on DAGv4
  • From: "Ron Andruff" <randruff@xxxxxxxxxxxxxxx>
  • Date: Mon, 19 Jul 2010 12:26:24 -0400

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>

 



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

Privacy Policy | Terms of Service | Cookies Policy