NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Dan Krimm <[log in to unmask]>
Reply To:
Dan Krimm <[log in to unmask]>
Date:
Tue, 24 Jul 2012 11:11:01 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (191 lines)
I think it's important to remember that ICANN is not ICTWI (the Internet
Corporation for The Whole Internet).  Just Assigned Names and Numbers.  Not
web sites, not email, not VoIP, etc.

Whatever issues arise in terms of fraud, etc., that do not follow directly
from IP addresses and domain names per se should not be part of ICANN's
purview.  To the extent that DNS-related policy can support law enforcement
in addressing these other realms, balanced policy would be productive.  But
ICANN should not have any direct authority over those other realms.

The main question here is, is ICANN the proper forum to adjudicate all of this?

ICANN is not (and shouldn't become) the King of the Internet.  It's just
charged with making sure DNS doesn't break, and anything directly related
to that mission.

Fraud is certainly a serious issue, but this org is not the one to address
it comprehensively.  It's still unclear to me that there is any "fraud"
that can be applied to domain names per se without taking into account the
*use* of the domain (applications such as web sites, etc.).  And once you
get into that realm you're beyond ICANN's charge.  Or at least you should
be.

As Robin points out, ICANN already has a bunch of TM-related provisions in
place.  Burden of proof is on those who call for more or special treatment.
Are we going to make ad hoc policy for everyone in the world?  Where does
it stop?

Dan


--
Any opinions expressed in this message are those of the author alone and do
not necessarily reflect any position of the author's employer.



At 12:31 PM -0400 7/24/12, Nicolas Adam wrote:
>Content-Type: text/html; charset=UTF-8
>X-MIME-Autoconverted: from 8bit to quoted-printable by mx3.syr.edu id
>q6OGQPBn028431
>
>I think Evan's points are sensible.
>
>I would add Å\ and hopefully it makes some sense Å\ that sometimes
>organizations, governments, and other political body (even sometimes
>including courts, Supreme Ones, too) go to great length to do something,
>not for the sake of its *policy-effect*, but for the sake of its
>*political-effect*, on its legitimacy [or insert your favorite concept],
>on the ideological [your favorite concept] structure underlying
>issues-axis, on the legal [normative or some other concept] structure
>underlying issues-axis, or forother some such long term
>strategical/structural reasons.
>
>There are more considerations than just stopping fraud'n phishin' to this
>quandary. It is naive not to recognize this, not the other way around.
>
>There is the issue of the GAC and GNSO's relationship with it. How is
>option 1 helping this? We display strength, which is good, but we don't
>harness any of it for future fights, which is bad. No principles becomes
>enshrine with option 1, because obviously we say nothing that will be
>lasting about *why* we do nothing. We stress and gain (I suppose) the
>importance of process. Not so bad, but I contend we could be doing more.
>The Board has few ally on its gTLD plan and NCSG (and gNSO) is one of
>those few. There is missed opportunity here. We should not ask for a legal
>study, we should give RC its candy while coughing it in a legal language
>that will have lasting effect. This is by far the best option we have.
>*How* and *why* we act are more important than what we do in this instance
>(I'm assuming we can give RC a candy in such a way as to gather strength
>for future fights. I could be wrong. But I won't know until we've explored
>and debated this).
>
>There is for instance the issue of the MSM relationship to both technical
>and the global [not inter-national] community which needs to be strengthen.
>
>Those political-jurisdictional-foundational issues aren't going anywhere
>anytime soon. And the other issue-axis, well, they are issue-axis! They
>are here to stay. Every time we have a chance to put pressure our way on
>one of the many underlying political foundation of ICANN/MSM, it is
>irresponsible to let it pass. Other interests having differing preferred
>positions on some issue-axis than NCSG does, don't usually miss out on any
>of those opportunity, and they try to hammer home some ways that will not
>only lend them victory on this issue short term, but also on the longer
>term on the related axis.
>
>It is true that it doesn't help that we don't have a simile-constitutional
>principles/jurisdictional/political set to push. But I contend that
>whatever it is we are doing or not entails and enables (if slightly) some
>simile-normative positions. When we stay with more "technical" issues, and
>refrain from pushing more political foundational stuff, we might be doing
>some prudent good-governance but we are also actually missing out on
>advancing some positions on debates that will come back. Crucially, others
>are not so idle.
>
>Just laying these thoughts out there. I'm not assuming we can etch out
>something quick in the dead of night here. And in the immediate absence of
>some set of principles that bear longer term strategical impact
>politically and around which we can work, then it might makes sense to go
>the route of option 1. But I would contend that we would need some more
>thoughts toward asserting our own preferred foundation, derived from human
>rights and from the service to the global community as it may.
>
>Nicolas
>
>
>On 7/23/2012 2:52 PM, Evan Leibovitch wrote:
>
>>On 23 July 2012 13:54, David Cake
>><<mailto:[log in to unmask]>[log in to unmask]> wrote:
>>
>>        As far as the issue of charitable names being exploited for
>>fraudulent purposes, as discussed by Evan and Milton - it seems to me,
>>from discussions with the charities, that the *real* solution that the
>>charities need (and not just the ICRC, with its unique legal protections,
>>but ANY charity) is basically a takedown solution like those provided by
>>the APWG etc. Fraud is fraud, we need good solutions to stop fraud - but
>>not only will special rules for the ICRC not have a large effect on fraud
>>targeted against charities in general, it won't even eliminate fraud
>>against the ICRC - much fraud against the ICRC appears to use domain
>>names that don't include the specific protected designations redcross
>>etc, but just variations such as just
>><http://somethingrc.org>somethingrc.org. If the specific redcross term
>>and other protected designations were protected at the second level, we'd
>>see fraudsters simply switch to less preferred names, such as variations
>>on namerc type 2LD names, and 3LDs and such.
>>
>>
>>Agreed 100%.
>>
>>The kind of issue people in ALAC were responding to were the short-term
>>scam sites such as
>>"<http://redcrosshaitirelief.com>redcrosshaitirelief.com", ones that
>>specifically used the charity's name (specifically its conventional
>>Internet 2LD names) inside bogus 2LD strings. As I mentioned in the
>>earlier email, there's also agreement that nothing is special about the
>>Red Cross in this regard, I would consider
>>"<http://unicefhaitifelief.org>unicefhaitifelief.org" or
>>"<http://oxfamhaitirelief.net>oxfamhaitirelief.net" to be just as bad.
>>
>>As such, I would remind that ALAC has never been in favour of any Red
>>Cross or IOC or IGO restrictions on TLDs -- ever. Some of you may recall
>>that I was in the room near the end of the g-council debate on the issue
>>in San Jose, ready if necessary to detail ALAC's just-passed statement
>>supporting the NCSG position. There is similarly no belief in special
>>treatment for IGOs, *especially* considering that most of them possess
>>the rare qualifications for the exclusive .int TLD already. So our
>>position on gTLDs is still one of no change to existing policy.
>>
>>Furthermore... I never, in my original comment, suggested that prior
>>restriction -- at any level -- was our direction, only that a legitimate
>>larger issue, buried within the RC/IOC/IGO mess, did bare consideration.
>>We don't claim the answer yet, just ask the question (that indeed does
>>not yet appear to have been asked -- in all these years -- from the PoV
>>of the end user rather than the registrants.) There are many possible
>>approaches, not all of which have had a proper hearing to date. We're
>>totally aware of the limitations of ICANN and domain names, and that
>>removing obviously fraudulent strings won't eliminate phishing or fraud.
>>But it is also wrong to refuse to do anything because no solution can be
>>complete. And denying of scammers the ability to use (clearly) fraudulent
>>domain names impairs their ability to do SEO to increase traffic to their
>>sites.
>>
>>ICANN's denial of responsibility for cleaning up a problem that its
>>policy enabled (ie, creation of fraudulent domains) simply offers useful
>>ammunition to those who would dispense with the multi-stakeholder model
>>completely, through demonstrating that one significant stakeholder -- the
>>end user being scammed -- is going unheard by the MSM.
>>
>>
>>
>>Their is a fundamental difference between the ICRC arguments based on its
>>special legal status, and arguments based on the ICRCs mission and
>>specific operation concerns. The arguments based on the ICRCs special
>>legal status are one thing. But the arguments based on the humanitarian
>>mission and operational concerns of the iCRC could just as easily apply
>>to organisations such as the MSF or UNHCR. I wish a lot more of the
>>effort that has gone into the ICRCs arguments had gone into practical
>>fraud takedown measures that would be applicable to all charitable
>>organisations.
>>
>>
>>
>>Agreed. IMO, ALAC is seeking to drive this forward in a useful manner, by
>>steering and focusing (rather than outright rejecting) the claims in a
>>manner that benefits the public interest.
>>It would be nice if we could do this together with the NCSG, which is why
>>I'm writing this.
>>
>>
>>- Evan

ATOM RSS1 RSS2