- RDS-WHOIS2-RT - lists.icann.org

Comments about the Subgroup Report of Privacy/Proxy Services
by SUN Lili June 12, 2018

June 12, 2018

Dear Privacy & Proxy subgroup members, I went through the draft report of this subgroup on wiki page (https://community.icann.org/pages/viewpage.action?pageId=71604717) and step in with my concerns: 1. To the Data Accuracy subgroup, the Whois accuracy of domain names that utilize Privacy and Proxy Services is invisible. And Volker also mentioned that this will be dealt with in the Privacy & Proxy subgroup. As such, I strongly support Susan’s comments on “6 Conducting periodic due diligence checks on customer contact information” and “8 Providing clear and unambiguous guidance on the rights and responsibilities of registered name holders, and how those should be managed in the privacy/proxy environment.” There is no reason for a customer who chose P/P service thus been protected from responsibilities. 2. There is no indication about the legacy domain names that utilize P/P Services before the provider been accredited. Will it be a similar situation as Grandfathered domains? 3. Like the example I gave during the 2nd F2F meeting, if there is not enough regulation and overseeing in place, P/P service is very likely to be abused. To be clear, I elaborated the example in a word document (see attached). Do we really need this kind of fake prosperity of domain industry? A response from this subgroup is much appreciated. Thanks, Lili *************************************************************************************************** This message, and any attachment contained, are confidential and subject of legal privilege. It may be used solely for the designated police/justice purpose and by the individual or entity to whom it is addressed. The information is not to be disseminated to another agency or third party without the author’s consent, and must not be retained longer than is necessary for the fulfilment of the purpose for which the information is to be used. All practicable steps shall be taken by the recipients to ensure that information is protected against unauthorised access or processing. INTERPOL reserves the right to enquire about the use of the information provided. If you are not the intended recipient, be advised that you have received this message in error. In such a case, you should not print it, copy it, make any use of it or disclose it, but please notify us immediately and delete the message from any computer. *************************************************************************************************

7 20

Apologies
by Carlton Samuels June 11, 2018

June 11, 2018

Dear All: Was planning to join but called away at the last minute to attend a piece of work. My apologies. Best, -Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* =============================

1 0

call today
by Erika Mann June 11, 2018

June 11, 2018

Dear All - apologies for missing the call today, my calendar simply did not adopt to the change in timing (I'm in Washington DC) and I did not recognize it either. Sorry for this! Erika

1 0

Declined: RDS-WHOIS2 Review Team Plenary | 15:00 UTC on Monday
by Cathrin.BAUER-BULST＠ec.europa.eu June 11, 2018

June 11, 2018

Dear fellow team members, I'm afraid I have to miss today's conference call due to urgent work commitments. My apologies. Best regards Cathrin

1 0

IDN Subgroup report
by Dmitry Belyavsky June 11, 2018

June 11, 2018

Dear RT members, Please find attached the new draft report of the IDN subgroup. It has some changes in phrasing in "Overall conclusion" and "Recommendations" parts. -- SY, Dmitry Belyavsky

1 0

Re: [RDS-WHOIS2-RT] Data Accuracy subgroup draft report
by SUN Lili June 11, 2018

June 11, 2018

Hi Volker, You forgot to include the RT in your last response. The ARS was designed with community inputs, and deemed as an proactive approach to identify potentially inaccurate gTLD WHOIS contact data and forward to gTLD registrars for investigation and follow-up. That’s the foothold for this subgroup to review the implementation of Rec #6, 7, 9 according to the Action Plan. If you challenge the legitimacy of ARS at this stage, I don’t know where this subgroup should set foot on. Based on the facts so far, I support Susan’s assessment that the current Whois accuracy status is unacceptable. I’m also curious about what would be your feasible recommendations to improve Whois accuracy from registrar perspective. All the email exchanges between us are visible to this subgroup members. By this Friday I should know whether your comments will be supported by this subgroup. Furthermore, the RT has the Review Terms of Reference (ToR) regarding decision making. Relax. Regards, Lili From: Volker Greimann [mailto:vgreimann@key-systems.net] Sent: Tuesday, 5 June, 2018 11:50 PM To: SUN Lili <L.SUN(a)interpol.int> Subject: Re: [RDS-WHOIS2-RT] Data Accuracy subgroup draft report Hi Lili, the best confirmation of this is the language of the recommendation itself, as I pointed out earlier. I will have to reach out to a few people to get further confirmation. It may very well be inconsisent with the NORC study, but then the RT1 was free to recommend what they wanted, whereas our task is only to see whether their recommendations were properly implemented and to recommend changes where not. I posit that this recommendation is fully implemented. Whether or not ARS needs phase 3 is a different question. Some would say it is another example of ICANN being overly zealous. I also do not need a reminder as to how the ARS was implemented as I see these complaints come in from time to time. What you call considerable failures, I call picking nits. If you had seen some of those complaints coming out of the ARS, you might understand why this is such a frustrating experience for registrars and registrants alike. Here is one example where I redacted the irrelevant fields: The problem summary: Reporter Name: WHOIS Accuracy Reporting System (ARS) Reporter Email: whoiscompliance(a)icann.org<mailto:whoiscompliance@icann.org> Domain being reported: [Domain] Time of submission/processing: [timestamp redacted] Problem in whois block: Registrant Contact --- Error in address: Incorrect Address --- Comment: The telephone number is disconnected State/Province is missing for Country Problem in whois block: Administrative Contact --- Error in address: Incorrect Address --- Comment: State/Province is invalid for Country Problem in whois block: Technical Contact --- Error in address: Incorrect Address --- Comment: State/Province is invalid for Country Sounds reasonable, right? Until you realize that the proper address format of the country the registrant is in does not require the use of the State/Province field and in fact it is highly uncommon to provide it as the postal code already is a nationwide indicator. So what ultimately remained of the complaint was that a registrant had changed his phone number, but forgot to update his whois details. And for that, he was exposed to the risk of losing his domain name or having it suspended, had our compliance response email arrived at an inopportune time or been filtered into spam or anything else that can happen. Sure, contactibility was slightly improved (although he had been perfectly contactable through his physical address and his email address). Considerable failure? I don't agree. And because we received this complaint and did everything we were obliged to do, we should in your opinion now be required to undergo an extra round of audit fun, which - as I mentioned - takes at least a man month across all departments to complete and compile (not taking into account the time our resellers must also contribute to provide their part of the audit response). And please do not think that I chose a particular example. Most of them are like this. I picked one ARS complaint at random from our ticket system. Whois ARS regularly flags correct data as incorrect, flags non-required fields as missing, and from time to time, finds actually incorrect data that is irrelevant to the overall contactibility of the registrant. Sometimes, ICANN is engaged in taking cannon shots at sparrows and the WHOIS ARS is one of these windmill-tilting exercises. Best, Volker Am 05.06.2018 um 17:15 schrieb SUN Lili: Could you provide the official confirmation about RT1’s intension? I have doubts on this. If that’s the case, it’s inconsistent with the NORC study, and why WHOIS ARS needs Phrase 3? Please also be reminded that WHOIS ARS only implemented “contactability” check so far, while considerable failures occurred. From: Volker Greimann [mailto:vgreimann@key-systems.net] Sent: Tuesday, 5 June, 2018 9:51 PM To: SUN Lili <L.SUN(a)interpol.int><mailto:L.SUN@interpol.int> Cc: rds-whois2-rt(a)icann.org<mailto:rds-whois2-rt@icann.org> Subject: Re: [RDS-WHOIS2-RT] Data Accuracy subgroup draft report I have talked again to some of the members of the RT1 regarding their intentions behind the interpretation and they were very clear that they were only concerned with achieving a significant level of contactability. In fact, one commented: " the original WHOIS Review team was not interested in full accuracy, but "contactability." That concept for fully -- almost completely -- achieved in the 2013 RAA when the registrars verify (or is it validate, I always mix up the terms) phone or email. This should be listed as a huge, key success of the original WHOIS Review Team recommendation -- a big check mark for a job well done (yes this enormous effort, work and completion of mission is nowhere to be found!)." I would therefore strongly urge that we follow the original intent of the recommendation and mark it as fully achieved. When analyzing whether the aims of the recommendations of the first review have been met, being neutral means not to misinterpret their objectives to fit ones' own needs. The first RT made a recommendation which has been acted upon and which has in their own view been achieved. Our work here is done! Volker Am 30.05.2018 um 12:14 schrieb SUN Lili: Hi Volker, I believe the divergence between us roots in the understanding or interpretation of accuracy. I checked once again about the definition of “accuracy” in the 2010 NORC study (used Whois requirements of 2009 RAA as benchmarks), quoted below for information. Under Registrar Accreditation Agreement Section 3.3.1.6, an accurate name and postal address of the registered name holder means there is reasonable evidence that the registrant data consists of the correct name and a valid postal mailing address for the current registered name holder. Adapting this for the study, there were three criteria to be met for any WHOIS record to be considered accurate: 1. Was the address of the registrant a valid mailing address? 2. Was the registrant named associated in some way with the given address? 3. When contacted, would the named registrant acknowledge that they were indeed the registrant of the domain name, and confirm all details given as correct and current? As such, the core of accurate Whois data is contactable while with association with the registrant. The NORC study defined “Substantial failure” as “Undeliverable address and/or unlinkable name, however registrant located. Unable to interview registrant to obtain confirmation; Deliverable address, but unable to link or even locate the registrant, removing any chance of interview”. Again, if the information in the record has no association with registrant, it will be deemed as “Substantial failure”. The Whois ARS project has checked syntax and operability accuracy described in the SAC058 Report so far. The operability accuracy checks the functionality of the information in a record (e.g. Does the email go through? Does the phone ring? Will the mail be delivered?). In this context, whether the information in a record has association with registered name holder has not been checked (postponed to Phrase 3 – Syntax + Operability + Identity accuracy). Thus, Phrase 1 plus Phrase 2 are contactable test only, Phrase 3 has not started yet, there is no reason to take Whois ARS project “over- or underperforms the recommendations”. Again, I insisted that even a Whois record could perfectly pass syntax and operability check, while has no association with the registered name holder, which will deem as inaccurate. I do agree some registrars would be fully compliance with RAA, but as exposed during Whois ARS project, some registrars don’t, the evidence is that the inaccuracy could be remedied after Compliance informing, or the relating domain names were suspended or cancelled. If the issue could be remedied at this stage, why the validation and verification couldn’t be down upon registration? You may argue that “Who should pay for that?”, but this is a responsibility registrar should take according to RAA. I also want to remind you that unfortunately, except registrars who may have internal accounting /ticket system to keep tracking registrant not only on Whois data, but also billing information, the public Whois data is the only information that legitimate users or generic public could access about registered name holders. If the Whois data is outdated or even falsified, it could be a mislead for the information users. Last but not least, I understand your standpoint as a representative of registrar, but as a review team member, please keep neutral. What have been reviewed in this subgroup falls in the Action Plan provided by ICANN and contractual obligations of RAA. We are not in the position to challenge decisions have been made. Thanks, Lili From: Volker Greimann [mailto:vgreimann@key-systems.net] Sent: Monday, 28 May, 2018 6:29 PM To: SUN Lili <L.SUN(a)interpol.int><mailto:L.SUN@interpol.int> Cc: rds-whois2-rt(a)icann.org<mailto:rds-whois2-rt@icann.org> Subject: Re: [RDS-WHOIS2-RT] Data Accuracy subgroup draft report Hi Lili, responses inline. Regarding Section 3.2, I am a bit puzzled why no reference at all is made to a significant qualifier included in Rec 6. Rec 6 only refers to reducing the occurrence of the accuracy groups of Substantial Failure and Full Failure (of contactibility of the contact). In other words, if there is a partial inaccuracy, this would not even be covered by the recommendation if sufficient contactibility is maintained by the remaining contact points. WHOIS ARS does not make such a differentiation either, and instead goes beyond the recommendation as it merely looks for any error in the data regardless of whether the remaining data provides for sufficient contactibility. The data from the ARS would have to be analyzed in more significant detail before making the determination of whether the recommendation was implemented. I also am not convinced that the observations under 3.2 are fit to match the recommendation, and some are baseless speculation: The NORC study defined “Substantial failure” as “Undeliverable address and/or unlinkable name, however registrant located. Unable to interview registrant to obtain confirmation; Deliverable address, but unable to link or even locate the registrant, removing any chance of interview”; defined the “Full failure” as “Failed on all criteria - undeliverable address and unlinkable, missing, or patently false name, unable to locate to interview”. In this context, my view is that both Syntax check and Operability check are not necessarily linkable to the registrant. A Whois record could perfectly pass Syntax and Operability check while has not a single linkable information of the registrant. I don’t think “sufficient contactibility” is the objective of Rec #6, the essence of Rec #6 is how much relevant the Whois data to the registrant. The WHOIS ARS leave the identity check to the last stage, which means the relevance has not been checked yet. 1) This may very well be the case, but eneral improvement of the whois data is not what the recommendation is about. The recommendation is about achieving a certain level of accuracy, not total accuracy as the ARS is designed for. This observation is an overall assessment of the impact of WHOIS ARS. We should also comment on how the ARS implementet the recommendations and where it over- or underperforms the recommendations. Both are important when looking at how ICANN implemented the recommendations. 2) We should not speculate on causes for reasons of why the numbers are what they are. Accordingly, the entire second paragraph should be removed. Disagree. The fact was already there, the review means assessing the implementation, identifying problems/issues, and putting out new recommendations, if the RT doesn’t dig into the reasons, how can the RT recommend? I have no objections against fact-based reviews of reasons, however we should not enter into the realm of speculation. I therefore object to the inclusion of any conclusions that are not based on research and facts but only on pure speculation. Otherwise we could also blame anything on the phases of the moon or the ascendancy of Jupiter in Virgo. 3) Again, the inaccurate rate is of no importance in the contect of the recommendation. The only rate of concern would be that of inaccuracies that would be considered as Substantial and Full Failure of contactibility of the contact. Therefore this observation has no relevance to the recommendation as it stands. See above. The objective of Rec #6 is to reduce the inaccuracy in a measurable way, and Syntax + Operability accuracy doesn’t mean the criteria of not falling in Substantial failure have been met. As such, I used the term “confirmed”. I disagree with the interpretation of that objective. The recommendation specifically determines the inaccuracy levels it is concerned with. Inaccuracies in general or 100% accuracy were not the objective of that recommendation. The language here is clear. 4) Instead of seldom, I would use the term "very rarely, and only in the first cycle" to correctly reflect the numbers. Four cases of breach notices out of 2,688 tickets is statistically irrelevant. The statistics were quoted from WHOIS ARS Contractual Compliance Metrics<https://whois.icann.org/en/whoisars-contractual-compliance-metrics> as a fact. Correct. I only object to the word "seldom". We should be specific when interpreting the statistic. In this case, the breach notices only occurred in the first cycle. With regard to section 3.5, I fully disregard with the phrasing of the statement in section 4 that refers to "... if the WDRP were fully enforced...". We have no reason to believe that at this time this policy is not fully enforced and followed by registrars merely because of a report ICANN issued in 2004, especially as the followig section points out that we do not have reliable data from the compliance audit program. We must look at the situation today and if we have no data on that, we cannot make such a statement. I therefore suggest to strike the entire last paragraph of section 4. If anything, we should ask for compliance to provide better and more detailed data. The enforcement of WDRP was reflected in the following paragraph, and only sampled registrars were audited and no detailed information on how the registrars remedy deficiency on WDRP compliance is provided in the audit report. Regarding the statement of “Thus, there is good reason for this subgroup to believe that if the WDRP were fully enforced at annual basis, there would be a quite positive impact on Whois accuracy.”, that’s the assessment of the impact of WDRP policy you mentioned below, I’ll leave it for open discussion of the whole RT. Again, we have no indication that the WDRP requirement is not fully enforced. Your statement indicates it is not, which is a false statement. Further, the recommendation focusses on the impact of these messages, not on the observance of the policy by contracted parties, so the fifth paragraph focussing on registrar compliance misses that point entirely and should be removed. I agree with the assessment that rec 9 has not been implemented though. I don’t understand this comment well. The statement above is the impact of WDRP policy. As a proactive measure to improve Whois accuracy, the assessment of WDRP enforcement is necessary in my opinion. I disagree. Even if the policy were not properly enforced and only a small number of registrars followed it (which we have no indication for), we could still analyse how the policy impacts those registrants that receiver it, which is what the recommendation was about. 4.0-4.5 This section should again loses focus of the actual content of the recommendations to improving contactibility, not overall accuracy. We should therefore rephrase this section accordingly. Instead of "accuracy" and "reliability" we should use instead the terminology of sufficient contactibility, substantial and full failure. See Above. Again, I don’t agree “the actual content of the recommendations to improving contactibility, not overall accuracy”. The recommendation is clearly phrased. If it wanted to recommend full accuracy, it would have not used the substantial failure and full failure. If you interpret it otherwise, that is not covered by the language they intentfully used, but rather implies your own agenda. 4.2. What is the basis for this belief? As the ARS program took great lengths to create a significant sample size, its results regarding accuracy as a percentage should have some statistical relevance regarding the overall inaccuracy. Also, inaccuracies should be graded by the standards laid down in the recommendations. Insignificant inaccuracies that do not affect contactibility were still reported by the ARS program and included in the statistics, but play no role in the evaluation of the implementation of the recommendations. For example, many ARS compliance reports we received were for formatting errors where the data in the WHOIS, while accurate, did not match the format prescribed by the RAA, was entered in the wrong field, etc. Such inaccuracies do not normally affect contactibility. The rationale was depicted in the 2 paragraphs already. I disagree with the rationale. 4.3 I disagree with the section headline. The contractual compliance report to the contrary demonstrates proper enforcement of these obligations as they demonstrate the enforcement actions taken upon discovery of a deficiency. I also would argue for the removal of the section regarding Avalanche, since it is anecdotal at best and has no implication on compliance as the obligations are phrased in a way to allow multiple venues and methods of verification. To validate the format of Whois data and then verify Whois data are contractual obligations of registrar, it should be done upon registration, not to be dealt with after being discovered by complaints from community and/or WHOIS ARS. And according to contractual compliance report, the top issue with regards to registrar compliance on WHOIS inaccuracy is “registrars failing to verify or validate Whois information as required by 2013 RAA”. Your answer misses my point. This paragraph suggests whois obligations are not properly enforced based on the fact that there are inaccuraties. This is a fallacy, as the contractual obligations do not prevent all inaccuracies. An address can be perfectly formated and therefore validatable and the email address verifyable and the whois record may still be inaccurate for any number of reasons. The registrar can be fully compliant with his obligations under the 2013, but those do not guarantee accurate whois data and therefore cause whois inaccuracy complaints. I agree that the example of Avalanche currently has no relevance to compliance, it’s only a demonstration that registrar is in the best position and is also capable to verify Whois data. OK 4.4. seems to be missing a word in the headline. Also, as the the privacy proxy service take the role of the registrant in the public whois, on the accuracy of its own contact data should be of relevance for whois accuracy. Any issues with inaccuracies of the underlying data do not factor into the recommandations as issue for this subgroup. Instead any discussions of underlying data accuracies should be restricted to the privacy proxy subgroup. I agree that “underlying data accuracies should be restricted to the privacy proxy subgroup”, as it’s invisible to this subgroup. What has been outlined here is the facts of Whois check when it comes to P/P service. 4.5. As inaccuracy of whois is not at issue, this entire section would need reworking. I also do not agree with its conclusion that the measures are not sufficient to fulfill the targets of the recommendations. I totally disagree that “inaccuracy of whois is not at issue”, that was the reason why Rec #5-9 were to reduce the Whois inaccuracy. Only to a specific point, not inaccuracy in general. Reading more into the recommendation abuses them for purposes not intended. I also reject the assumption of the perception of non-compliance by registrars with their obligations. From my own experience, most inaccuracy reports received are not preventable by the measures required by the RAA. A record may be fully validatable and verifyable, yet still be incorrect. For example, an address may be perfectly formatted in accordance with the requirements, thus passing every required validation, yet still be incorrect due to the street not existing or being the address of someone else. I therefore strongly suggest removing the last paragraph of section 1 of 4.5. Your example perfectly indicate that validation is not enough, a following verification is needed to make sure the Whois information belongs to the registrant. Needed for what? Who should pay for that? As even cross-field verification is commercially unfeasible, verification of identity is impossible to achieve from a commercially reasonable perspective. Best, Volker Am 25.05.2018 um 12:40 schrieb SUN Lili: Dear all, Sorry for the late submission. Please refer to attached the revised version of the Data Accuracy subgroup draft report, which incorporated the discussion of 2nd F2F meeting and answers to the follow up questions on Data accuracy and Compliance from ICANN. As to the proposed recommendations, I’ll reflect in Compliance subgroup draft report. Thanks, Lili *************************************************************************************************** This message, and any attachment contained, are confidential and subject of legal privilege. It may be used solely for the designated police/justice purpose and by the individual or entity to whom it is addressed. The information is not to be disseminated to another agency or third party without the author’s consent, and must not be retained longer than is necessary for the fulfilment of the purpose for which the information is to be used. All practicable steps shall be taken by the recipients to ensure that information is protected against unauthorised access or processing. INTERPOL reserves the right to enquire about the use of the information provided. If you are not the intended recipient, be advised that you have received this message in error. In such a case, you should not print it, copy it, make any use of it or disclose it, but please notify us immediately and delete the message from any computer. ************************************************************************************************* _______________________________________________ RDS-WHOIS2-RT mailing list RDS-WHOIS2-RT(a)icann.org<mailto:RDS-WHOIS2-RT@icann.org> https://mm.icann.org/mailman/listinfo/rds-whois2-rt -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net> Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> www.twitter.com/key_systems<http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

2 3

Change of dates for July F2F
by Alan Greenberg June 8, 2018

June 8, 2018

Following the Doodle to reschedule the July F2F meeting in Brussels, in consultation with Susan, Cathrin and staff, we are moving the meeting to Thursday, 26 July and Friday 27 July. In addition to Thomas who could not make any of the dates when the venue and support staff are available, Dmitry has indicated that he cannot make the meeting at all, and Cathrin will have to leave early on the last day. But this option was the best possible option. Constituency Travel will be informed of the change. Alan

1 0

Plenary Call #31 | Monday 11 June | 15:00 UTC
by Jean-Baptiste Deroulez June 8, 2018

June 8, 2018

Dear Review Team Members, In preparation for your call #31 <https://community.icann.org/x/DiYFBQ> scheduled for Monday 11 June 2018 | 15:00 – 16:30 UTC, please find below the meeting agenda: * Welcome, Roll-Call, SoI Updates * Face-to-Face Meeting #3 * Subgroups Status Update * ICANN62 * A.O.B. * Confirm Decisions Reached and Action Items Please also note that today 23:59 UTC is the deadline for rapporteurs to send their approved subgroup report to the review team. You should all have received dial-in details to join this call. If not, please contact us (off list) at rds-whois2-staff(a)icann.org<mailto:rds-whois2-staff@icann.org>. As always, let us know if you have any questions or concerns. Kind regards, Jean-Baptiste

1 0

SubGroup Rapporteurs
by Alan Greenberg June 7, 2018

June 7, 2018

The question has arisen about exactly what the aims of the subgroups are, and the responsibilities of the Rapporteurs. Specifically, to what extent all questions and recommendation must be fully defined prior to the draft report being submitted to the Plenary. If a subgroup cannot reach consensus, then the report should document the differences and submit to the plenary for further discussion. On a related matter, Rapporteurs should reach out to group members to try to get positive agreement that they are fine with the report, but should not unreasonably delay submission to the plenary due to silence of team members. Alan

2 1

ICANN62 Presenters
by Alan Greenberg June 7, 2018

June 7, 2018

As you know, there will be a session in Panama to present our current findings and recommendations to the community, and to receive input. If you will be in Panama and want to present the section for which you are a rapporteur, please let me and staff know. If you are not willing to do this, or will not be in Panama, I, Cathrin or Susan will present on your behalf. Regardless of whether you are presenting, rapporteurs will need to make sure that the content of the slides for their section (being prepared by Lisa) is correct. Alan

4 3