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

BRUEGGEMAN, JEFF (ATTSI) jb7454 at att.com
Mon Jul 19 18:50:03 UTC 2010


Jon, admittedly I may be missing something in the DAG4 materials, but it
isn't clear to me how the rounds are being structured to address the
recommendations made in the economic paper.  I don't have a specific
suggestion for implementation, but rather want to be sure that the
overall implementation plan addresses the issues that are identified in
the economic paper.  This should include a roll-out process that allows
ICANN to learn from the initial round(s) and make adjustments as needed
to address any issues or concerns.   I don't see where that has been
addressed in the DAG4.

 

Jeff

 

From: Jon Nevett [mailto:jon at nevett.net] 
Sent: Monday, July 19, 2010 2:32 PM
To: BRUEGGEMAN, JEFF (ATTSI)
Cc: Ron Andruff; bc-GNSO at icann.org
Subject: Re: [bc-gnso] RE: UPDATED DRAFT BC Public Comments on DAGv4

 

Jeff:

 

How would you suggest that ICANN implement New TLDs in discrete, limited
rounds?  Do you have an alternative proposal to what currently is in the
DAGv4, or are you comfortable with what is in the current version?  Just
trying to understand what you are advocating for on this issue.  We
might be on the same page.  

 

Thanks.

 

Jon

 

 

 

On Jul 19, 2010, at 2:27 PM, BRUEGGEMAN, JEFF (ATTSI) wrote:





Ron, you have captured the intent of my comment.  The economic framework
paper is "new" information for the comment proceeding and it provides
some perspectives that are relevant to the issues being discussed within
the BC.  The paper discusses the potential user benefits of new gTLDs
(e.g., innovative business models and IDNs), while also acknowledging
the potential costs and externalities.  I read the two conclusions in
the paper as being related - ICANN should introduce new gTLDs in
discrete, limited rounds and adopt practices for gathering additional
information about the costs and benefits of new gTLDs.  By implementing
both recommendations, ICANN can learn from experience and make informed
decisions.  


Jeff

 

From: owner-bc-gnso at icann.org [mailto:owner-bc-gnso at icann.org] On Behalf
Of Ron Andruff
Sent: Monday, July 19, 2010 12:26 PM
To: 'Jon Nevett'
Cc: bc-GNSO at icann.org
Subject: RE: [bc-gnso] RE: UPDATED DRAFT BC Public Comments on DAGv4

 

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 at nevett.net] 
Sent: Monday, July 19, 2010 12:09 PM
To: Ron Andruff
Cc: bc-GNSO at icann.org
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 at icann.org [mailto:owner-bc-gnso at icann.org] On Behalf
Of Phil Corwin
Sent: Monday, July 19, 2010 10:39 AM
To: Jon Nevett; Zahid Jamil
Cc: 'Deutsch, Sarah B'; michaelc at traveler.com; mike at haven2.com;
jb7454 at att.com; randruff at rnapartners.com; ffelman at markmonitor.com;
bc-GNSO at icann.org
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 at nevett.net]
Sent: Sunday, July 18, 2010 9:39 PM
To: Zahid Jamil
Cc: 'Deutsch, Sarah B'; Phil Corwin; michaelc at traveler.com;
mike at haven2.com; jb7454 at att.com; randruff at rnapartners.com;
ffelman at markmonitor.com; bc-GNSO at icann.org
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>

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/bc-gnso/attachments/20100719/207957a7/attachment.html>


More information about the Bc-gnso mailing list