- gtld-tech - lists.icann.org

Publishing of the Allocation Token EPP Extension IETF Draft
by Gould, James Oct. 9, 2014

Oct. 9, 2014

The first draft of the Allocation Token EPP Extension ( http://tools.ietf.org/html/draft-gould-allocation-token-00 ) has been submitted to the IETF. I co-authored this draft with Sharon Wodjenski and Trung Tran from Neustar to support the definition of an allocation token for allocating an object like a domain name. In one use case, the token can be used to support the releasing of reserved names via an external auction provider, where the domain names and tokens are provided to the auction provider, and the winning registrant of the auction will receive the token to pass through the registrar to the registry to allocate a domain name using a transform command like create, update, or transfer. Another use case is to use the token to authorize the allocation of domain names in a founder’s program. Other alternatives like leveraging the authinfo or leveraging one of the key, value pair extensions were considered, but we felt that having an explicit allocation token to authorize the allocation of an object was the cleanest approach. Please review the draft and provide any feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0

ICANNs WHOIS "clarifications" - overreaching and contradicting?
by Alexander Mayrhofer Sept. 18, 2014

Sept. 18, 2014

ICANN has published extensive "WHOIS Service Clarifications" on September 12, posted here: https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-201… We think that some of the points would warrant discussion among registries/registrars, as well as feedback from ICANN. Specifically, our points are: 1) Relation between current WHOIS requirements and RDAP implementation: Given the progress of RDAP in the IETF, we're wondering why ICANN can justify requesting the industry to put significant effort into modifying existing (and PDT-approved!) implementations of a protocal that ICANN probably intends to replace in the near future anyways. -> Therefore, Please provide a (if preliminary!) view on ICANN's intended roadmap on the future of RDDS protocols. 2) "Incremental", contradicting specifications: It seems like the "clarifications" contradict earlier requests by ICANN to modify the WHOIS service in at least one requirement: Clarification I.5 requires that Domain status field values conform to the respective EPP mappings. However, ICANNs earlier request in the "AWIP" (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en) requires that the line also includes a web link back to an information page - which means that the field value is required to carry cruft that is not contained in the EPP mappings, and hence violates ICANN's own "Clarification". I think this happens because of the "incremental" way the service is specified. -> Please provide an aggregated, complete, standalone specification without any contradicting requirements. 3) RAA specification affecting Registries: It seems weird that Registries should suddenly be subject to requirements that are included in the *RAA*. For example, see the "reseller" field in Clarification 1 - Why on earth would a *Registry* be required to display that field, which would contain information that only the registrar has access to? -> Please re-consider using the loophole of "Clarifications" to apply RAA requirements to registries 4) Redundant "empty" fields: Displaying an empty set of keys (eg. the field "Name Server" for domains, or the various DNSSEC-related fields) makes very little sense to me. Specifically for data relations that have a cardinality of 0..n, the requirement to include *all* fields seems overreaching. It might be sensible for fields that have a 1:1 relation, but artificially adding denormalized field sets for non-existing object relations is sloppy. Particularly because the only reasoning seems that people write cra..^H inadequate parsers. -> Please relax the respective requirement. 5) Data Protection requirements, EPP hidden fields vs. WHOIS: EPP allows for the "hiding" of certain fields in an contact object. The main use for this is (and will be) to achieve compliance with local data protection law, for example for EU based registries. However, the requirement in the Clarification document that "all fields MUST be shown", together with the provision that only "fields for which no information does exist in the registry" can be left empty effectively requires registries to breach the EPP "hidden field" settings. I'm not diving much deeper into the policy side of this, but preventing this from the *technical* side already looks like another loop hole to me. -> Please consider the option to exclude certain fields (particularly those affected by the EPP "hide" policy) on the technical level, to allow for doing so should a current or future policy allow (or a legal ruling to require) registries to do so. Feedback and discussion appreciated. thanks, Alex Mayrhofer Head of R&D nic.at / TLDBOX GmbH.

2 2

Registry Escrow Policy Object
by John Keating Sept. 15, 2014

Sept. 15, 2014

Hi, There seems to be a discrepancy between the way an Escrow Deposit Policy object is defined. In section 5.8.1 of version 5 of the Object mapping doc it's defined as: The OPTIONAL <policy> contains the following attributes: o An <element> that defines that the referenced <element> is REQUIRED. o <scope> that defines the XPath of the element referenced by <element>. Example of <rdePolicy:policy> object: <rdePolicy:policy scope="//rde:deposit/rde:contents/rdeDomain:domain" element="rdeDom:registrant" /> In rde-policy-1.0.xsd it's defined as: <element name="policy" type="rdePolicy:policyType" substitutionGroup="rde:content"/> <complexType name="policyType"> <complexContent> <extension base="rde:contentType"> <attribute name="element" type="anyURI" use="required"/> </extension> </complexContent> </complexType> Which says it has one attribute named 'element' of type 'anyURI', and the attribute 'scope' is not mentioned and so is not allowed. Has this difference in definitions been mentioned before? Thanks, John

3 10

Call for Presentations for TechDay 25 at ICANN LA
by Dr Eberhard Lisse Aug. 7, 2014

Aug. 7, 2014

Hi, As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Los Angeles. This will be the 25th TechDay and this time we'll do it jointly with DNS-OARC again (Sunday). See https://indico.dns-oarc.net/conferenceCFA.py?confId=20 We'll try to have one focus on large data and another one on security but this is not a condition. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz As we have a very small budget presenters are responsible for their own transport and room and board, though we might be able to assist the most riveting proposal :-)-O As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

Handling of "loc" and "int" contacts
by Alexander Mayrhofer July 18, 2014

July 18, 2014

All, We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements) we're looking into the options to move forward with allowing "loc" postalInfo types as well. I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback: - For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, "int" optional - For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc"?) - For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?) - Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables? Feedback appreciated :) thanks, Alex

6 5

Re: [gtld-tech] Almost Final Draft Agenda for TechDay London
by Dr Eberhard Lisse June 23, 2014

June 23, 2014

Please find enclosed and distribute widely. Times are more or less fixed now and for the speakers, please email your presentations in PDF without effects by Sunday evening London Time 2014-06-22 to kristina.nordstrom(a)icann.org so we can add them to the Adobe COnnect software for the remote participants. el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

3 2

Re: [gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Gould, James June 22, 2014

June 22, 2014

Elaine, Claims Lite consists of a LORDN like interface between the registries and the TMCH that provides a notice of the release and the allocation of reserves names with no front end claims to the registrar or registrant. The registries would need to implement this new LORDN like feed that will provide ICANN and the trademark holders systematic visibility into the reserved name activity. The release (i.e start of auction) of the reserved names would not show up in the zone files, so Claims Lite will provide more timely notice for the trademark holders. ICANN could use the feed to monitor the reserved name activity. The key is to not require a mix of registration flows for the registrars and registrants depending on whether the domain is a standard domain or a released reserved domain, which is disruptive to all parties. JG James F. Gould Principal Engineer Verisign jgould(a)verisign.com<mailto:jgould@verisign.com> On Jun 22, 2014, at 7:19 AM, "Elaine Pruis" <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: Hi James, Thanks for the reply. Sorry I've forgotten the details of "claims lite." Is that just notifying trademark holders when a name is registered right? If not, what does that require from the registry? Are claims still presented to the registrant? Elaine On Jun 20, 2014, at 9:23 AM, "Gould, James" <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: Elaine, Using a small subset of the list does reduce the probability of a match, but it does not remove it completely, meaning that the claims check still needs to be invoked by the registrar with the chance, yet very small, that the registrar would need to interface with the CNIS to present the claims notice and submit the claims acknowledgement on the create. Claims defines the general flow of a TLD, meaning a phase, and really is not a service that is applicable to a very small subset of domains of the TLD. I still prefer the "Claims Lite" option that does not require any front end interface changes, but does provide additional visibility to ICANN and the trademark holders for the releasing and allocation of reserved names. JG James F. Gould Principal Engineer Verisign jgould(a)verisign.com<mailto:jgould@verisign.com> On Jun 18, 2014, at 2:02 PM, "Elaine Pruis" <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: The easiest option is to verify against a small subset of the DNL Since the full DNL isn't checked, no claims will be presented after the mandatory 90 days for names that were available during that period. Claims would only be presented on names that come off the reserved list and are also on the DNL list. The "claims check" would be against a sub-list of the DNL list, instead of checking the entire list. This works for reserved names and for NXD names when they become available. This solution doesn't require much workflow change for registrars--just removing the "end date" for claims. It requires a bit of dev work for registry operators because we'd have to check a different list after the mandatory 90 days are up, but the cost would be significantly less. Jeff asked for some data to help guide the discuss, can we get an idea from the TMCH how many names on the DNL actually have been registered, and from registrars how many customers don't register after seeing a claims notice? We checked registrations in 90 TLDs against the DNL--the average number of names in our TLDs that are on the DNL is only 1%. This data is verifiable by checking zone files against the DNL. Considering the name collision block lists (the greatest source of reserved names, thousands in every TLD), on average only 0.47% of the names blocked for NXD are also on the DNL. Elaine Pruis Vice President, Operations ……………………………… …… …… elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161 <Donuts_Logo_Signature.png> On Jun 11, 2014, at 12:34 PM, Michele Neylon - Blacknight <michele(a)blacknight.com<mailto:michele@blacknight.com>> wrote: Jeff Sorry if I’m a bit thick here, but if you could clarify what you’re proposing for me it would be helpful. At the moment most new TLD registries seem to support a variant of the “claims check” which extends the standard “domain check”. Are you proposing removing that or tweaking it? Just trying to understand what you’re saying Thanks and regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: tmch-tech-bounces(a)icann.org<mailto:tmch-tech-bounces@icann.org> [mailto:tmch-tech-bounces@icann.org<mailto:tech-bounces@icann.org>] On Behalf OfJeffrey Eckhaus Sent: Tuesday, June 10, 2014 10:27 PM To: tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>; gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> Subject: [tmch-tech] Fwd: RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Hi all, We have been thinking a great deal about this and cannot come to any other conclusion is that this will be a major pain with little to no benefit to anyone involved. I like the idea of addressing this at a policy level to see if this can be removed or retracted based on information and evidence we have to date. How many claims notices have been served by the TMCH, how many registrations did not go through because the registrant did not agree to the Claims Notification. how many URS's have been sent? I believe that ICANN made this mandatory in the RPM "negotiations" and hopefully they can reverse this the same way they mandated it. Now that we are stuck with this , I think we still need to work towards a solution and think this is going to be driven by Registrars and how their solutions are setup. Even if a Registry decides to run eternal claims , if the registrar has their system set for .EXAMPLE TLD to only run claims for 90 days , it will be a bad user experience as the registration will fail, if the claims acknowledgment is not submitted. On the other side , if the Registrar has eternal claims running , then it will require all SLD's on the claims list to go through the TMCH, regardless if it is past 90 days. This is not a great option either , as it would add a tremendous workload to both Registries and Registrars and I do not see Registrars keeping this eternal claims on I think a possible solution for both sides is to have domain level claims checks. When a registrant searches for a domains at their favorite registrar , the registrar would send a claims check to the Registry. If the Registry has been in GA for over 90 days and the domain name was available the whole time (not on reserve) then it would return that there is no claims on this domain , even if it is actually in the TMCH. If it was just taken off reserve and is less than 90 days than it would come back with yes for Claims and the registrar would need to pull the claims notice and present it to the registrant. While this is still not ideal , it is the least burdensome method to registries and registrars and will cause the least amount of confusion for registrants Would love to hear any thoughts on this or any other proposals as we get closer to London meeting Jeff Begin forwarded message: From: Jeffrey Eckhaus <jeff(a)rightside.co<mailto:jeff@rightside.co>> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Date: June 10, 2014 at 2:19:49 PM PDT To: "Gould, James" <JGould(a)verisign.com<mailto:JGould@verisign.com>> Cc: Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>>, "tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>" <tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Hi all, We have been thinking a great deal about this and cannot come to any other conclusion is that this will be a major pain with little to no benefit to anyone involved. I like the idea of addressing this at a policy level to see if this can be removed or retracted based on information and evidence we have to date. How many claims notices have been served by the TMCH, how many registrations did not go through because the registrant did not agree to the Claims Notification. how many URS's have been sent? I believe that ICANN made this mandatory in the RPM "negotiations" and hopefully they can reverse this the same way they mandated it. Now that we are stuck with this , I think we still need to work towards a solution and think this is going to be driven by Registrars and how their solutions are setup. Even if a Registry decides to run eternal claims , if the registrar has their system set for .EXAMPLE TLD to only run claims for 90 days , it will be a bad user experience as the registration will fail, if the claims acknowledgment is not submitted. On the other side , if the Registrar has eternal claims running , then it will require all SLD's on the claims list to go through the TMCH, regardless if it is past 90 days. This is not a great option either , as it would add a tremendous workload to both Registries and Registrars and I do not see Registrars keeping this eternal claims on I think a possible solution for both sides is to have domain level claims checks. When a registrant searches for a domains at their favorite registrar , the registrar would send a claims check to the Registry. If the Registry has been in GA for over 90 days and the domain name was available the whole time (not on reserve) then it would return that there is no claims on this domain , even if it is actually in the TMCH. If it was just taken off reserve and is less than 90 days than it would come back with yes for Claims and the registrar would need to pull the claims notice and present it to the registrant. While this is still not ideal , it is the least burdensome method to registries and registrars and will cause the least amount of confusion for registrants Would love to hear any thoughts on this or any other proposals as we get closer to London meeting Jeff On Thu, May 29, 2014 at 1:38 PM, Gould, James <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: I agree with both Jeff and Elaine that having a discussion at the ICANN meeting along with further discussion on the list ahead of the meeting would be very useful. Can someone from ICANN respond to the request for adding this to the ICANN meeting agenda? Thanks, -- JG <image001.png> James Gould Principal Software Engineer jgould(a)verisign.com<mailto:jgould@verisign.com> 703-948-3271<tel:703-948-3271> (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> From: Jeffrey Eckhaus <jeff(a)rightside.co<mailto:jeff@rightside.co>> Date: Tuesday, May 27, 2014 at 4:13 PM To: Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>> Cc: "tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>" <tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Great idea Elaine. We are still thinking about this since we are looking at it from the Registry and Registrar side and the few weeks leading up to London would be helpful . I think we should continue discussion on the list leading up to the event , try to get to a plan right before event and maybe try to finalize something with ICANN in London Jeff On May 27, 2014, at 11:17 AM, Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: There are a few more options we can consider for Claims. Considering there is some dissent over how to apply the RPM requirements to reserved names it would be wise to meet in London for further discussion. That will give folks some time to come up with additional options. Would the ICANN person managing this list please arrange for that? Elaine Pruis Vice President, Operations ……………………………… …… …… elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161<tel:%2B1%20509-899-3161> <Donuts_Logo_Signature.png> On May 27, 2014, at 5:46 AM, Wil Tan <wil(a)cloudregistry.net<mailto:wil@cloudregistry.net>> wrote: On Thu, May 22, 2014 at 6:23 AM, Gould, James <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: I prefer option 2 for the “Allocation of the reserved names” problem. I prefer option 4 first, followed by option 3, for the “Handling the claims service for reserved names that have marks in the TMCH” problem. Running eternal claims services is clearly not a view shared by all registries. The middle ground -- asking registrars and registries to reactivate all the claims machinery for a subset of names -- presents a significant challenge. As such, I concur with option 4 or 3 for handling claims for reserved names with marks in TMCH. .wil Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

1 0

Re: [gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Gould, James June 20, 2014

June 20, 2014

Elaine, Using a small subset of the list does reduce the probability of a match, but it does not remove it completely, meaning that the claims check still needs to be invoked by the registrar with the chance, yet very small, that the registrar would need to interface with the CNIS to present the claims notice and submit the claims acknowledgement on the create. Claims defines the general flow of a TLD, meaning a phase, and really is not a service that is applicable to a very small subset of domains of the TLD. I still prefer the "Claims Lite" option that does not require any front end interface changes, but does provide additional visibility to ICANN and the trademark holders for the releasing and allocation of reserved names. JG James F. Gould Principal Engineer Verisign jgould(a)verisign.com<mailto:jgould@verisign.com> On Jun 18, 2014, at 2:02 PM, "Elaine Pruis" <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: The easiest option is to verify against a small subset of the DNL Since the full DNL isn't checked, no claims will be presented after the mandatory 90 days for names that were available during that period. Claims would only be presented on names that come off the reserved list and are also on the DNL list. The "claims check" would be against a sub-list of the DNL list, instead of checking the entire list. This works for reserved names and for NXD names when they become available. This solution doesn't require much workflow change for registrars--just removing the "end date" for claims. It requires a bit of dev work for registry operators because we'd have to check a different list after the mandatory 90 days are up, but the cost would be significantly less. Jeff asked for some data to help guide the discuss, can we get an idea from the TMCH how many names on the DNL actually have been registered, and from registrars how many customers don't register after seeing a claims notice? We checked registrations in 90 TLDs against the DNL--the average number of names in our TLDs that are on the DNL is only 1%. This data is verifiable by checking zone files against the DNL. Considering the name collision block lists (the greatest source of reserved names, thousands in every TLD), on average only 0.47% of the names blocked for NXD are also on the DNL. Elaine Pruis Vice President, Operations ……………………………… …… …… elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161 <Donuts_Logo_Signature.png> On Jun 11, 2014, at 12:34 PM, Michele Neylon - Blacknight <michele(a)blacknight.com<mailto:michele@blacknight.com>> wrote: Jeff Sorry if I’m a bit thick here, but if you could clarify what you’re proposing for me it would be helpful. At the moment most new TLD registries seem to support a variant of the “claims check” which extends the standard “domain check”. Are you proposing removing that or tweaking it? Just trying to understand what you’re saying Thanks and regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: tmch-tech-bounces(a)icann.org<mailto:tmch-tech-bounces@icann.org> [mailto:tmch-tech-bounces@icann.org<mailto:tech-bounces@icann.org>] On Behalf OfJeffrey Eckhaus Sent: Tuesday, June 10, 2014 10:27 PM To: tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>; gtld-tech(a)icann.org<mailto:gtld-tech@icann.org> Subject: [tmch-tech] Fwd: RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Hi all, We have been thinking a great deal about this and cannot come to any other conclusion is that this will be a major pain with little to no benefit to anyone involved. I like the idea of addressing this at a policy level to see if this can be removed or retracted based on information and evidence we have to date. How many claims notices have been served by the TMCH, how many registrations did not go through because the registrant did not agree to the Claims Notification. how many URS's have been sent? I believe that ICANN made this mandatory in the RPM "negotiations" and hopefully they can reverse this the same way they mandated it. Now that we are stuck with this , I think we still need to work towards a solution and think this is going to be driven by Registrars and how their solutions are setup. Even if a Registry decides to run eternal claims , if the registrar has their system set for .EXAMPLE TLD to only run claims for 90 days , it will be a bad user experience as the registration will fail, if the claims acknowledgment is not submitted. On the other side , if the Registrar has eternal claims running , then it will require all SLD's on the claims list to go through the TMCH, regardless if it is past 90 days. This is not a great option either , as it would add a tremendous workload to both Registries and Registrars and I do not see Registrars keeping this eternal claims on I think a possible solution for both sides is to have domain level claims checks. When a registrant searches for a domains at their favorite registrar , the registrar would send a claims check to the Registry. If the Registry has been in GA for over 90 days and the domain name was available the whole time (not on reserve) then it would return that there is no claims on this domain , even if it is actually in the TMCH. If it was just taken off reserve and is less than 90 days than it would come back with yes for Claims and the registrar would need to pull the claims notice and present it to the registrant. While this is still not ideal , it is the least burdensome method to registries and registrars and will cause the least amount of confusion for registrants Would love to hear any thoughts on this or any other proposals as we get closer to London meeting Jeff Begin forwarded message: From: Jeffrey Eckhaus <jeff(a)rightside.co<mailto:jeff@rightside.co>> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Date: June 10, 2014 at 2:19:49 PM PDT To: "Gould, James" <JGould(a)verisign.com<mailto:JGould@verisign.com>> Cc: Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>>, "tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>" <tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Hi all, We have been thinking a great deal about this and cannot come to any other conclusion is that this will be a major pain with little to no benefit to anyone involved. I like the idea of addressing this at a policy level to see if this can be removed or retracted based on information and evidence we have to date. How many claims notices have been served by the TMCH, how many registrations did not go through because the registrant did not agree to the Claims Notification. how many URS's have been sent? I believe that ICANN made this mandatory in the RPM "negotiations" and hopefully they can reverse this the same way they mandated it. Now that we are stuck with this , I think we still need to work towards a solution and think this is going to be driven by Registrars and how their solutions are setup. Even if a Registry decides to run eternal claims , if the registrar has their system set for .EXAMPLE TLD to only run claims for 90 days , it will be a bad user experience as the registration will fail, if the claims acknowledgment is not submitted. On the other side , if the Registrar has eternal claims running , then it will require all SLD's on the claims list to go through the TMCH, regardless if it is past 90 days. This is not a great option either , as it would add a tremendous workload to both Registries and Registrars and I do not see Registrars keeping this eternal claims on I think a possible solution for both sides is to have domain level claims checks. When a registrant searches for a domains at their favorite registrar , the registrar would send a claims check to the Registry. If the Registry has been in GA for over 90 days and the domain name was available the whole time (not on reserve) then it would return that there is no claims on this domain , even if it is actually in the TMCH. If it was just taken off reserve and is less than 90 days than it would come back with yes for Claims and the registrar would need to pull the claims notice and present it to the registrant. While this is still not ideal , it is the least burdensome method to registries and registrars and will cause the least amount of confusion for registrants Would love to hear any thoughts on this or any other proposals as we get closer to London meeting Jeff On Thu, May 29, 2014 at 1:38 PM, Gould, James <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: I agree with both Jeff and Elaine that having a discussion at the ICANN meeting along with further discussion on the list ahead of the meeting would be very useful. Can someone from ICANN respond to the request for adding this to the ICANN meeting agenda? Thanks, -- JG <image001.png> James Gould Principal Software Engineer jgould(a)verisign.com<mailto:jgould@verisign.com> 703-948-3271<tel:703-948-3271> (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> From: Jeffrey Eckhaus <jeff(a)rightside.co<mailto:jeff@rightside.co>> Date: Tuesday, May 27, 2014 at 4:13 PM To: Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>> Cc: "tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>" <tmch-tech(a)icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Subject: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names Great idea Elaine. We are still thinking about this since we are looking at it from the Registry and Registrar side and the few weeks leading up to London would be helpful . I think we should continue discussion on the list leading up to the event , try to get to a plan right before event and maybe try to finalize something with ICANN in London Jeff On May 27, 2014, at 11:17 AM, Elaine Pruis <elaine(a)donuts.co<mailto:elaine@donuts.co>> wrote: There are a few more options we can consider for Claims. Considering there is some dissent over how to apply the RPM requirements to reserved names it would be wise to meet in London for further discussion. That will give folks some time to come up with additional options. Would the ICANN person managing this list please arrange for that? Elaine Pruis Vice President, Operations ……………………………… …… …… elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161<tel:%2B1%20509-899-3161> <Donuts_Logo_Signature.png> On May 27, 2014, at 5:46 AM, Wil Tan <wil(a)cloudregistry.net<mailto:wil@cloudregistry.net>> wrote: On Thu, May 22, 2014 at 6:23 AM, Gould, James <JGould(a)verisign.com<mailto:JGould@verisign.com>> wrote: I prefer option 2 for the “Allocation of the reserved names” problem. I prefer option 4 first, followed by option 3, for the “Handling the claims service for reserved names that have marks in the TMCH” problem. Running eternal claims services is clearly not a view shared by all registries. The middle ground -- asking registrars and registries to reactivate all the claims machinery for a subset of names -- presents a significant challenge. As such, I concur with option 4 or 3 for handling claims for reserved names with marks in TMCH. .wil Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Rightside Group, Ltd. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

1 0

Re: [gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Alexander Mayrhofer June 20, 2014

June 20, 2014

Elaine, it's not difficult at all. Where did you get the information from that the TMCH is using zone files instead of the LORDN reporting for extended claims`? Would appreciate a pointer. thanks, Alex Von: Elaine Pruis [mailto:elaine@donuts.co] Gesendet: Freitag, 20. Juni 2014 13:50 An: Alexander Mayrhofer Cc: Michele Neylon - Blacknight; tmch-tech(a)icann.org; gtld-tech(a)icann.org Betreff: Re: [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names How difficult is it to not submit the LORDN to the TMCH? Just make the claims available to the Registrar? Since the TMCH is offering extended claims by using the zone file to find names registered that are on the DNL list, they don't really need the LORDN after the 90 days, right? Elaine Pruis Vice President, Operations .................................... ...... ...... elaine(a)donuts.co<mailto:elaine@donuts.co> +1 509-899-3161 [cid:image001.png@01CF8C98.400068C0] On Jun 20, 2014, at 3:31 AM, Alexander Mayrhofer <alexander.mayrhofer(a)nic.at<mailto:alexander.mayrhofer@nic.at>> wrote: Elaine, all, The easiest option is to verify against a small subset of the DNL Since the full DNL isn't checked, no claims will be presented after the mandatory 90 days for names that were available during that period. Claims would only be presented on names that come off the reserved list and are also on the DNL list. The "claims check" would be against a sub-list of the DNL list, instead of checking the entire list. This works for reserved names and for NXD names when they become available. [Alexander Mayrhofer] That's exactly the way we will implement this. However, as we noticed recently, the TMCH *rejects* LORDN-entries for Claims once a registry moves beyond the "official" Claims Phase (as indicated on the ICANN startup schedule page). The TMCH responsds with an 4606 error ("TLD not in Sunrise or Claims"). That means that after the "official" 90-day Claims phase has ended for a TLD, the registry operator actually *can't* use the standard LORDN reporting process to submit domain names that required claims. Since i'm not aware of any other mechanism to report such Claims cases to the Clearinghouse, it seems to me that ICANN has created a requirement that doesn't seem to be implemented right now. So, without either: a) the TMCH accepting LORDN files *beyond* the standard claims phase (preferred, since it doesn't require *any* change on the registry/registrar side!) or b) ICANN/TMCH proposing a different solution for reporting of Claims associated with such "Late Claims" cases, i don't see how a registry could currently fulfil that requirement. We'll continue to send the respective reporting LORDN files, even though the TMCH does reject them. At least we tried. However, i'm definitely interested to join other Registry Backend Operators during the ICANN meeting if there's a discussion about this. Alex

1 0

Re: [gtld-tech] [tmch-tech] RPM Requirement of Supporting Claims Service for Release or Allocation of Reserved Domain Names
by Alexander Mayrhofer June 20, 2014

June 20, 2014

Elaine, all, The easiest option is to verify against a small subset of the DNL Since the full DNL isn't checked, no claims will be presented after the mandatory 90 days for names that were available during that period. Claims would only be presented on names that come off the reserved list and are also on the DNL list. The "claims check" would be against a sub-list of the DNL list, instead of checking the entire list. This works for reserved names and for NXD names when they become available. [Alexander Mayrhofer] That's exactly the way we will implement this. However, as we noticed recently, the TMCH *rejects* LORDN-entries for Claims once a registry moves beyond the "official" Claims Phase (as indicated on the ICANN startup schedule page). The TMCH responsds with an 4606 error ("TLD not in Sunrise or Claims"). That means that after the "official" 90-day Claims phase has ended for a TLD, the registry operator actually *can't* use the standard LORDN reporting process to submit domain names that required claims. Since i'm not aware of any other mechanism to report such Claims cases to the Clearinghouse, it seems to me that ICANN has created a requirement that doesn't seem to be implemented right now. So, without either: a) the TMCH accepting LORDN files *beyond* the standard claims phase (preferred, since it doesn't require *any* change on the registry/registrar side!) or b) ICANN/TMCH proposing a different solution for reporting of Claims associated with such "Late Claims" cases, i don't see how a registry could currently fulfil that requirement. We'll continue to send the respective reporting LORDN files, even though the TMCH does reject them. At least we tried. However, i'm definitely interested to join other Registry Backend Operators during the ICANN meeting if there's a discussion about this. Alex

1 0