March 2014 - ALAC - lists.icann.org

NTIA Announces Intent to Transition Key Internet Domain Name Functions
by Eduardo Diaz March 15, 2014

March 15, 2014

You may find this interesting. http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition… -ed -- *NOTICE:* This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.

3 2

Lack of Enforcement of UDRP Decisions
by Garth Bruen March 13, 2014

March 13, 2014

Dear ALAC Chair Olivier MJ Crepin-Leblond and ALAC Members, I am forwarding you the immediate results of an investigation into UDRP Complaint handling by ICANN with a request for action. As everyone here knows, the UDRP is a critical component of Internet compliance and ensuring the public trust. As sometimes happens, registrars fail to cooperate with the process and it is up to ICANN to enforce this component of the RAA. What you will see in the attached memo is a number of cases where a UDRP provider reported to ICANN that a registrar failed to comply with the process but ICANN did not issue enforcement on the matter. In some cases, the domain was never transferred and is still held by the registrant/registrar in violation of the UDRP. There are three cases in particular which should be of great concern, domains potentially selling: *Illicit Pharmaceuticals *Counterfeit Electronics *Knockoff Cigarettes Please review the details in the attached document. I am requesting that this document be forwarded to ICANN Compliance and that ALAC take this matter up for inquiry. While it is late, I would like to see this on the agenda while in Singapore. I will be distributing this information widely myself, but I encourage you to share it with any interested party. As a representative of an Internet user community and an officer of At-Large it is my duty to investigate and report on these matters. As the At-Large community is our duty to advise ICANN on these specific issues. Sincerely, Garth Bruen ------------------------------------- Garth Bruen gbruen(a)knujon.com 617-947-3805 http://www.knujon.com Chair of ICANN At-Large North America (naralo.org) Twitter: @Knujon Skype: gobruen "If history is deprived of the Truth, we are left with nothing but an idle, unprofitable tale" -Polybius

1 0

Re: [ALAC] Compliance complaint
by Alan Greenberg March 13, 2014

March 13, 2014

I received a message from Compliance on 10 March saying that the complaint we submitted had been closed because "Based on the current Whois data, the domain was suspended when the complaint was received by ICANN, or the registrar demonstrated that it took reasonable steps to investigate the Whois inaccuracy claim by suspending, deleting, cancelling or otherwise deactivating the domain name." On checking the Whois record, the domain still exists, but it is in "client Hold" status which means that it is no longer in the zone file. A DNS lookup confirmed this. The domain is due to expire on 24 April. So the result of this exercise is that the particular domain that we were complaining about is out of service. It remains to be seen whether it will pop back again or not. The fictitious e-mail address is still reported (by domaintools.com) as being in use by over 1000 other domain names. It is not clear how many of them might also be unusable, but at least one that I checked (updflashplayer.com) is still in the DNS but does not seem to be live. To do further investigation would require more time than I have at the moment, and access to domain tools that I don't have. Perhaps Garth would like to follow0up and if so, I ask that he contact me directly to develop a plan of action. The bottom line seems to be that the compliance process worked in this case, but it is clearly insufficient to address the root problem that was being identified. The complaint process that we have suggested to Compliance would be far better suited. Have we had ANY response from them? Alan At 18/02/2014 05:03 PM, Alan Greenberg wrote: >>The problem summary: >> >>Reporter Name: Alan Greenberg, on behalf of ALAC Leadership Team >>Reporter Email: alan.greenberg(a)mcgill.ca >>Domain being reported: rapetube.org >> >>Time of submission/processing: Tue Feb 18 16:23:13 2014 >> >>Problem in whois block: Technical Contact >> --- Error in address: Incorrect address >> --- Error in email: Incorrect email >> --- Comment: Same information as above. >> >>Problem in whois block: Registrant Contact >> --- Error in address: Incorrect address >> --- Comment: Domain given for e-mail address, >> "Privacy-Protect.cn" is a non-existent domain and >> therefore cannot possible be a valid address. >> >>Street address, "Rue la produit 34, Nimes, >>Languedoc-Roussillon, France, Postal Code:30189" is a >>non-existent address, and the postal code given (30189) is in fact >>an "area code" or "INSEE code" and not a valid postal code. >> >>The same registrant for other registrations gives the same invalid >>e-mail address, but often a valid street address (26 Rue Jean >>Reboul, Nimes, Languedoc-Roussillon, France 30900" which is >>apparetnly the address of a restaurant - >>https://maps.google.com/maps?q=26+Rue+Jean+Reboul,+Nimes,+France&hl=en&…) >> >>Problem in whois block: Administrative Contact >> --- Error in address: Incorrect address >> --- Error in email: Incorrect email >> --- Comment: Same information as above. >> >>The whois at the time of processing is: >> >> >>REGISTRY WHOIS: >> >> >>Domain Name:RAPETUBE.ORG >>Domain ID: D155914076-LROR >>Creation Date: 2009-04-21T14:44:42Z >>Updated Date: 2013-04-16T08:41:16Z >>Registry Expiry Date: 2014-04-21T14:44:42Z >>Sponsoring Registrar:Bizcn.com, Inc. (R1248-LROR) >>Sponsoring Registrar IANA ID: 471 >>WHOIS Server: >>Referral URL: >>Domain Status: clientTransferProhibited >>Registrant ID:orgre90683958698 >>Registrant Name:Henry Nguyen Gong >>Registrant Organization:Privacy-Protect.cn >>Registrant Street: Rue la produit 34 >>Registrant City:Nimes >>Registrant State/Province:Languedoc-Roussillon >>Registrant Postal Code:30189 >>Registrant Country:FR >>Registrant Phone:+33.466583875 >>Registrant Phone Ext: >>Registrant Fax: +33.466583875 >>Registrant Fax Ext: >>Registrant Email:contact@privacy-protect.cn >>Admin ID:orgre90683959424 >>Admin Name:Henry Nguyen Gong >>Admin Organization:Privacy-Protect.cn >>Admin Street: Rue la produit 34 >>Admin City:Nimes >>Admin State/Province:Languedoc-Roussillon >>Admin Postal Code:30189 >>Admin Country:FR >>Admin Phone:+33.466583875 >>Admin Phone Ext: >>Admin Fax: +33.466583875 >>Admin Fax Ext: >>Admin Email:contact@privacy-protect.cn >>Tech ID:orgre90683960526 >>Tech Name:Henry Nguyen Gong >>Tech Organization:Privacy-Protect.cn >>Tech Street: Rue la produit 34 >>Tech City:Nimes >>Tech State/Province:Languedoc-Roussillon >>Tech Postal Code:30189 >>Tech Country:FR >>Tech Phone:+33.466583875 >>Tech Phone Ext: >>Tech Fax: +33.466583875 >>Tech Fax Ext: >>Tech Email:contact@privacy-protect.cn >>Name Server:NS3.CNMSN.COM >>Name Server:NS4.CNMSN.COM >>Name Server: >>Name Server: >>Name Server: >>Name Server: >>Name Server: >>Name Server: >>Name Server: >>Name Server: >>Name Server: >>Name Server: >>Name Server: >>DNSSEC:Unsigned

4 6

Re: [ALAC] Compliance complaint
by Alan Greenberg March 13, 2014

March 13, 2014

At 12/03/2014 11:23 PM, Evan Leibovitch wrote: >On Mar 12, 2014 8:33 PM, "Alan Greenberg" ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: > > > > I am assuming that the lack of a reply from Olivier means we have > heard nothing back. > > > > Compliance has already they don't want to spend the time with us > going over the same presentation that they will give in the public > session, so focusing on our proposal for a new submission tool > seems appropriate. > >I agree, partially. > >The submission tool issue is important, but only part of a larger >conversation about ICANN's approach towards third-party >whistleblowers, consumer groups, state regulators, etc. Improving >the submission tool is necessary but not sufficient. No not sufficient, but a mechanism by which one can submit a CLASS of infractions without necessarily identifying them one-by-one will result in a quantum change. >And then there is still the issue of backlogs of complaints, which >cannot be brushed aside if they remain unresolved. This isn't like a >bankruptcy; ICANN can't just absolve itself of responsibility >because it has upgraded the contract. > >Even if action can't be taken because an older fraudulent act didn't >violate an old RAA, these issues still needs closure as a matter of >salvaging trust. > >It will be interesting to know how much of the above will be covered >in the public Compliance session. Probably none. That is why I said that our wantin to discuss this meshes well with not previewing the public meeting with us.

1 0

Statement Necessary? ICANN Strategy Panels
by ICANN At-Large Staff March 12, 2014

March 12, 2014

Dear All, Do you believe that a Statement on the following PC is necessary? Please note that the ALAC are likely to discuss this in Singapore F2F. ICANN Strategy Panels<https://community.icann.org/x/2hLRAg> Regards, Heidi Ullrich, Silvia Vivanco, Matt Ashtiani, Ariel Liang, Gisella Gruber, Nathalie Peregrine and Julia Charvolen ICANN Policy Staff in support of ALAC E-mail: <mailto:staff@atlarge.icann.org%3cmailto:staff@atlarge.icann.org> staff(a)atlarge.icann.org<applewebdata://68497759-1B04-4F9B-84B7-B9445B8F305F/Regards,%20Heidi%20Ullrich,%20Silvia%20Vivanco,%20Matt%20Ashtiani,%20Ariel%20Liang,%20Gisella%20Gruber,%20Nathalie%20Peregrine%20and%20Julia%20Charvolen%20ICANN%20Policy%20Staff%20in%20support%20of%20ALACmailto:staff@atlarge.icann.org>

1 0

Re: [ALAC] [community] Ariel Liang shared "At-Large ICANN Strategy Panels Workspace" with you
by Olivier MJ Crepin-Leblond March 12, 2014

March 12, 2014

Dear all, just following up on Ariel's note. It is worth knowing that the work of these Strategy Panels will be shared in a session in Singapore, in addition to the recent Webinars. Kind regards, Olivier On 12/03/2014 16:06, Ariel Liang (Confluence) wrote: > Ariel Liang <https://community.icann.org/display/%7Eariel.liang> has > just shared a page with you: > At-Large ICANN Strategy Panels Workspace > <https://community.icann.org/display/alacpolicydev/At-Large+ICANN+Strategy+P…> > > Hello everyone, > > I hope your day has been going well. > > Do you think a Statement on this PC is necessary? > > Please note that ALAC are likely to discuss this PC in Singapore F2F. > > Thank you, > Ariel > Also shared with: > alac(a)atlarge-lists.icann.org <mailto:alac@atlarge-lists.icann.org> > If you are having trouble accessing the link, please copy and paste > the URL below into your browser: > https://community.icann.org/x/2hLRAg > > Sent by Atlassian Confluence > <http://www.atlassian.com/software/confluence> 5.1.5, the Enterprise > Wiki <url.enterprise.wiki> >

1 0

[community] Ariel Liang shared "At-Large ICANN Strategy Panels Workspace" with you
by Ariel Liang (Confluence) March 12, 2014

March 12, 2014

1 0

At-Large IDN Update
by Rinalia Abdul Rahim March 11, 2014

March 11, 2014

Dear Colleagues, This is an update about IDN-related matters in preparation for the Singapore ICANN Meeting: 1. ALAC Statement on Translation and Transliteration of Contact Information - The finalized draft statement has been posted on the wiki and will be open for an ALAC vote shortly: https://community.icann.org/display/alacpolicydev/At-Large+Translation+and+… - The PDP Working Group on Translation and Transliteration of Contact Information will have meetings in Singapore. 2. At-Large IDN Working Group Meeting @ Singapore ICANN 49 Meeting (Wed, March 26th, 5-6pm, VIP room) *Agenda:* 1. Welcome by Co-Chairs (Rinalia Abdul Rahim and Edmon Chung) 2. Universal Acceptance of IDN TLDs: A discussion on collaboration and coordination needed for the universal acceptance of IDN TLDs worldwide for the benefit of end users Discussants: Ram Mohan (Afilias), Jothan Frakes (Mozilla), Jordyn Buchanan (Google), Sarmad Hussein (Al-Khawarizmi Institute for Computer Science, Pakistan), Michele Neylon (Blacknight Solutions), Andrei Kalesnikov ( ccTLD.ru) and Edmon Chung (Joint ccNSO-GNSO IDN Working Group) 3. Root Zone LGR Project Generation Panel Development: Language Community Issues - Arabic script community (Sarmad Hussein - KICS Pakistan) - Chinese language community (Edmon Chung - dotAsia) - Japanese language community (Hiro Hotta - JPRS) - Korean language community (Joo Young (Ethan) Kim / YJ Park - KISA) - Cyrillic script community (Andrei Kalesnikov - ccTLD.ru) Please join us for this meeting as there is no IDN Working Group update scheduled for the ALAC Meetings during the week in Singapore. Best regards, Rinalia

1 0

Sam Lanfranco: "Challenges facing ICANN in particular and Internet Governance Stakeholders in General"
by Evan Leibovitch March 2, 2014

March 2, 2014

Hello all, The following has been recently published on the website of The Internet Society Canada Chapter, a NARALO ALS. "Challenges facing ICANN in particular and Internet Governance Stakeholders in General <http://www.internetsociety.ca/lanfranco-icann-challenges/>" Its author is Sam Lanfranco, Professor Emeritus and Senior Scholar of York University in Toronto, and also a participant in the Non-Profit Organization Constituency (NPOC) of ICANN. He is also the subject of a series of video interviews on Internet issues<http://www.youtube.com/channel/UCEVM0xMLSuCKt5UwU8eQlgA>done by the Chapter. Comments are welcomed but moderated. -- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56

1 0

(DRAFT) ALAC Statement on Translation and Transliteration of Contact Information in Response to Working Group Input Request from SO/AC
by Rinalia Abdul Rahim March 2, 2014

March 2, 2014

Dear Colleagues, A draft ALAC statement has been posted on the Charter questions posed by the Translation and Transliteration of Contact Information Working Group on this wikipage: https://community.icann.org/display/alacpolicydev/At-Large+Translation+and+… The draft is provided as a basis for discussion. Please note that you need to log-in to enable the comments feature of the wikipage. If you cannot log-in for whatever reason, please send your comments to staff ( staff(a)at-large.icann.org) and they can help you. The draft statement is pasted below for a quick review so that you can decide whether or not to comment via the wiki. Best regards, Rinalia *(DRAFT) ALAC Statement on Translation and Transliteration of Contact Information in Response to Working Group Input Request from SO/AC* (Note: The use of the word "transformation" of contact information pertains to the "translation and / or transliteration" of contact information.) *(1) Whether it is desirable to translate contact information to a single common language or transliterate contact information to a single common script* It is important to note that translating contact information to a single common language privileges the users of that language over other users, just as the transliteration to a single common script privileges users of that particular script over others. The choice of one single common language or script does not reflect or support a global Internet community, which is diverse in language and script use. Our preference is to have registration contact information in languages and scripts that reflect the diversity of Internet users. We believe that it is unreasonable to assume that registrants will be able to enter contact information in scripts or languages other than their local script and language. It is possible that some registrants may have the ability to do so, but in principle registrants should not be expected or required to transform their own contact information. In terms of the choice of whether to translate or transliterate contact information, the transformation of contact information to a level where it is understandable to users of registration data may require a combination of both. For example, when transforming contact information, proper names or nouns (i.e., unique names of persons, places, events and things) should not be translated and should instead be transliterated. *(2) What exactly the benefits to the community are of translating and/or transliterating contact information, especially in light of the costs that may be connected to translation and/or transliteration?* The Internet has a global user base. Transformed contact information that is validated to be accurate and useable allows users worldwide to see who are the domain name registration holders and how to contact/reach them. Contact information is used for various purposes by a range of users. The purposes include regulatory/contract enforcement, domain name monitoring and research, domain name purchase/sale, individual Internet use, technical issue resolution, legal action, abuse mitigation and malicious Internet activities (see Expert Working Group on gTLD Directory Services Report). In cases where harmful Internet activities are perpetrated, the availability of transformed contact information that is accurate and useable facilitates those taking action to protect end users. Moreover, transformed contact information that is validated for accuracy and usability promotes consumer trust in the Domain Name System and is beneficial to the At-Large community. *(3) Should translation and/or transliteration of contact information be mandatory for all gTLDs?* Based on the principle that gTLDs serve global Internet users, transformation of contact information should be mandatory for all gTLDs. *(3) Should translation and/or transliteration of contact information be mandatory for all registrants or only those based in certain countries and/or using specific non-ASCII scripts* If transformation of contact information is to be implemented as a matter of policy, then it should be mandatory for all registrants for the purpose of serving global Internet users. Registrants based in countries and / or using specific non-ASCII scripts should not be discriminated against in the implementation of contact data transformation. Contact information for registrants in ASCII script should also be equally transformed for the benefit of non-ASCII script users. *(4) What impact will translation/transliteration of contact information have on the WHOIS validation as set out under the 2013 Registrar Accreditation Agreement?* No comment. *(5) When should any new policy relating to translation and transliteration of contact information come into effect?* No comment. *(6) Who should decide who should bear the burden translating contact information to a single common language or transliterating contact information to a single common script? This question relates to the concern expressed by the Internationalized Registration Data Working Group (IRD-WG) in its report that there are costs associated with providing translation and transliteration of contact information. For example, if a policy development process (PDP) determined that the registrar must translate or transliterate contact information, this policy would place a cost burden on the registrar.* The decision on who should bear the burden of transforming contact information should be informed by the views of and impact on all affected parties, which would include the provider of the information (registrants), those involved in collecting and maintaining the information (i.e., registrar, reseller, registry) and the range of users that include end users and regulatory authorities/law enforcement agencies. The PDP decision-making rules and procedures for Consensus Policy should apply with input from all ICANN Advisory Committees (i.e., At-Large Advisory Committee, Governmental Advisory Committee and Security and Stability Advisory Committee). *(7) Who does your SG/C believe should bear the cost, bearing in mind, however, the limits in scope set in the Initial Report on this issue?* In determining who should bear the cost, it would be important to consider whether the transformation of contact information is made for general use or specialized use. If the transformation is required for general use, the cost should be borne by the process/entities that collect the information. If the transformation is required for specialized use, the parties requiring the specialized service should bear the cost of contact information transformation. If transformation has general use and is crucial for particular specialized use, then a sharing of costs between those collecting the information and those requiring specialized use of the information could be considered. END

1 0