<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Everyone:<div class=""><br class=""></div><div class="">In preparation for THURSDAY’s call, I have been through the notes and the distillation of them since the last meeting where we discussed §4.4 of the Temporary Specification. In order to make headway on a few issues, I wish to make a few comments and pose a few questions. I am not taking any side in these questions but think there is the opportunity is a few cases to narrow issues down so they can be resolved to the entire group’s satisfaction. </div><div class=""><br class=""></div><div class="">I am admittedly cherry-picking some issues that might be resolved on email. If the §4.4 subsection is not listed here, I think a meeting discussion is required. </div><div class=""><br class=""></div><div class="">I note that the discussion we had in Thursday’s meeting was preliminary and additional thoughts can be introduced at any time. I also note that these were the proposals made by the registrar representatives and not adequately considered by all at the time of the meeting. </div><div class=""><br class=""></div><div class="">Perhaps the support team can set thesis up in a comment-only google doc - one for each topic - to create a tool for discussing these. </div><div class=""><br class=""></div><div class="">Issues below, thanks and regards,</div><div class=""><br class=""></div><div class="">Kurt</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">1). §4.4.1 thus far, acceptable as written in the Temporary Specification: "Reflecting the rights of a Registered Name Holder in a Registered Name and ensuring that the Registered Name Holder may exercise its rights in respect of the Registered Name;”</div><div class=""><br class=""></div><div class="">Is there disagreement with this conclusion by any group?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">2)  In §4.4.3, it was recommended that in "Enabling a reliable mechanism for identifying and contacting the Registered Name Holder for a variety of legitimate purposes more fully set out below,” </div><div class=""><br class=""></div><div class="">that the “identifying' be lined out. </div><div class=""><br class=""></div><div class="">The Business Constituency and ALAC recommended that “identifying” be left in the subsection. </div><div class=""><br class=""></div><div class="">The initial question for the ALAC and BC is to flesh out this point of view and describe what purpose is lost by taking the word “identifying” out (or gained by having it included)? I.e., describe a set of circumstances where, in the case that “identifying” was left out, an opportunity to correct / avoid illegal or abusive behavior would be lost. </div><div class=""><br class=""></div><div class="">With that legitimate purpose confirmed, those supporting the removal of "identifying” (NCSG and registrars) would be asked to describe how including “identifying” unnecessarily reveals personal data that the word “contacting” does not. </div><div class=""><br class=""></div><div class="">A brief look at definitions and synonyms for “identifying” indicates that it is a manner in which to establish contact - so without being conclusory, this might work out the same from a data perspective in either case. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">3) §4.4.4 thus far, it is agreed to remove this: "Enabling a mechanism for the communication or notification of payment and invoicing information and reminders to the Registered Name Holder by its chosen Registrar;"</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">4)  In §4.4.5:. "Enabling a mechanism for the communication or notification to the Registered Name Holder of technical issues and/or errors with a Registered Name or any content or resources associated with such a Registered Name;”</div><div class=""><br class=""></div><div class="">It was recommended that “content” be taken out, with some other phrases to result in: “Enabling a mechanism for the communication or notification to the Registered Name Holder of technical issues <strike class="">and/or errors</strike> with a Registered Name<strike class=""> or any content or resources associated with such a Registered Name</strike>;”</div><div class="">.</div><div class="">This was found to be generally acceptable except that ALAC requested that we, "ask ICANN Org to provide more context on why "content" was added to this section.” That is being done and the issue discussion will await that response. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">5).  In §4.4.6, it was recommended that the section be deleted,  "Enabling a mechanism for the Registry Operator or the chosen Registrar to communicate with or notify the Registered Name Holder of commercial or technical changes in the domain in which the Registered Name has been registered”</div><div class=""><br class=""></div><div class="">ALAC recommended that the paragraph should remain, stating, "Reference to registry is still relevant.”</div><div class=""><br class=""></div><div class="">The question for registries and registrars: If some registries have a legitimate interest in personal data, is this the section where that purpose is described? If yes, should it remain in this form or an alter form?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">6) In §4.4.10, it was recommended that the section be deleted,  "Facilitating the provision of zone files of gTLDs to Internet user,” because, "registrars are not aware of a registrar purpose for publication of zone files.”</div><div class=""><br class=""></div><div class="">There were no comments regarding this section. </div><div class=""><br class=""></div><div class="">Question: Does anyone object to this deletion? If yes, or what purpose is this data to be put?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">7)  In §4.4.11, it was recommended that the section be deleted,  "Providing mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure, or other unavailability of a Registrar or Registry Operator,” because, "this is covered in registrar data escrow.”</div><div class=""><br class=""></div><div class="">There were no comments regarding this section. </div><div class=""><br class=""></div><div class="">Question: Does anyone object to this deletion?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">8) Regarding §4.4.12. "Coordinating dispute resolution services for certain disputes concerning domain names,”</div><div class=""><br class=""></div><div class=""> It was suggested that this be changed to,"Coordinating dispute resolution services for URS and UDRP”</div><div class=""><br class=""></div><div class="">Both the IPC and ALAC indicated that "dispute resolution can be used in other contexts,” and "We cannot leave just these two DRPs.”</div><div class=""><br class=""></div><div class="">The question for IPC, ALAC and presumably others is to flesh out this point of view and describe a set of circumstances where the registrar edition would be inadequate. Is it to anticipate new policies or practices such as UDRP and URS or is it to address domain disputes in a different way?</div><div class=""><br class=""></div><div class="">By identifying those additional purposes, we might be able to apply Thomas’ and Benedict’s construct to address those purposes. </div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>