- gtld-tech - lists.icann.org

Documentation on CZDAP
by Adrian Cho Oct. 2, 2013

Oct. 2, 2013

I have been looking about for documentation on the centralized zone data access provider. All I am able to find so far is the webinar from Durban so I was wondering if any of you kind folk can point me in the direction of the supporting documents. Regards Adrian

1 0

Q about ICANN Reporting, transfer related fields
by Alexander Mayrhofer Sept. 30, 2013

Sept. 30, 2013

Hi, there's a bit of ambiguity with some transfer-related fields in the ICANN reporting specifications. Since we're currently implementing the respective reports, some guidance would be appreciated: The description of the fields transfer-gaining-nacked transfer-losing-successfully transfer-losing-nacked leaves it open whether the datetime of the transfer request, or the datetime of the execution/rejection of the transfer shall be considered for identifying the reporting period, i.e. shall a transfer that is requested on March 30, and nacked on April 02 reported in March or April? Advice highly appreciated :-) thanks, Alex

1 0

Has anybody successfully uploaded LORDN data to test.ry.marksdb.org?
by Andreas Papst Sept. 27, 2013

Sept. 27, 2013

Hi, according to http://tools.ietf.org/html/draft-lozano-tmch-func-spec-07 I have tried both curl and wget to upload test-LORDN-files to https://test.ry.marksdb.org/LORDN/<TLD>/sunrise for example: curl -i -X POST -d @lordn.sunrise -u <username>:<password> https://test.ry.marksdb.org/LORDN/<GTLD>/sunrise where file lordn.sunrise contains test-data copied from draft-lozano-tmch-func-spec: 1,2013-09-26T02:15:00.0Z,1 roid,domain-name,SMD-id,registrar-id,registration-datetime,application-datetime 8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,2012-07-15T00:50:00.0Z the only answer returned is everytime: 400 - No file provided Any hint how this works? Best wishes Andreas -- ________________________________________________________________________ Andreas Papst | Vienna University Computer Center | E-Mail: andreas.papst(a)univie.ac.at Universitaetsstrasse 7 | Phone: +43 1 4277 / 140 36 A-1010 Vienna, Austria, Europe | Fax.: +43 1 4277 / 8 140 36

2 2

Using API to submit .REP file to ICANN
by Johnson, Scott Sept. 24, 2013

Sept. 24, 2013

Has anyone had success submitting the report using curl? Using the following: curl --request PUT --data @<filename.rep> --user <usename>:<password> <URL> I continue to get a result of: curl: (7) couldn't connect to host I have an account establish and I'm using the test url. --------------------------------------------------------------------------------- Scott Johnson Sr. Data Architect, Data Services Group NeuStar Inc. <mailto:scott.johnson@neustar.biz> 46000 Center Oaks Plaza, Cube 1137, Sterling, VA 20166-6596 Voice: 571-434-5496

2 1

URS technical requirements, comments and questions
by Gustavo Lozano Sept. 9, 2013

Sept. 9, 2013

Colleagues, The following is a list of comments/questions related to the second version of the URS technical requirements. Your feedback is appreciated. Comments from James Gould: 1. The text for requirement 8 provides two options for handling a domain that expires while in URS Lock that focuses on allowing the URS Lock domain to be deleted (online or offline) after the expiry and the subsequent auto renew. I believe that this is a corner case that adds some additional complexity. Allowing deletion of the URS Lock domain post-expiry makes the domain expiration date an element that must be considered when submitting the URS complaint. If the main driver of this requirement is to allow the domain to be deleted within the auto renew grace period, the likelihood of the URS process exceeding the auto renew grace period is extremely low. Based on my calculation the maximum URS duration is 45 days which matches our auto renew grace period of 45 days. The auto renew grace period of various TLD's could be shorter, but the auto renew grace period will most likely be a long enough period to cover the URS process. My recommendation is to not do anything at expiry of URS Lock domains and allow the URS process to complete prior to allowing the domain to be deleted. GL - For UDRP there is a provision (3.7.5.7) in the http://www.icann.org/en/resources/registrars/accreditation/eddp for handling the scenario of active UDRP process during the end of the validity period. Unfortunately the URS Procedures are silent about what happens if a URS locked DN expires. During our internal discussions, the conclusion was that the normal registration lifecycle should be followed when the URS Procedures are silent. The auto-renew grace period, as you mentioned may be shorter for some TLDs and this will create corner cases for the Registrars and the Registry Operator of that TLD, e.g. Is the registrar billed for the renew? Who pays the renew? Is credit provided to the Registrar if the URS process finalize and the registrant/complainant don't want the DN to be renewed? The number of UDRP cases filled in the last month of the validity period of a DN is low and we believe this is likely going to be the case for URS. The proposal is to show a warning message when filling the URS procedure if the domain name is within the last month of validity, explaining that the domain name may be deleted during the URS process and the process will be terminated. 2. The text in requirement 9 "Registry Operator MUST offer the option for the URS Complainant to extend a URS Suspended domain name registrations for up to one year from the date the domain name was Suspended", sounds like the renew command behavior needs to change for URS Suspension domains. The renew command should extend from the prior expiration date and not the date the domain name was suspended. I do not recommend making any change to the renew logic for URS Suspension domains, since it will impact all of the registries and the registrars. I recommend that the registries allow for the renew of URS Suspension domains and leave it up to the Registrars to ensure that the renew is done at most once for URS Suspension domains, by the URS Complainant, according to the Registry-Registrar Agreement. GL - The text needs to be clarified, as the idea behind Requirement 9 is basically what you are proposing. This is the proposed new text: Registry Requirement 9: In cases where a URS Complainant (as defined in the URS Rules) has prevailed, Registry Operator MUST offer the option for the URS Complainant to extend a URS Suspended domain name's registration (if allowed by the maximum validity period of the TLD). Registry Operator MAY collect the renewal fee paid by the URS Complainant for the URS Suspended domain name from the sponsoring Registrar of the domain name. It's worth mentioning that in section 4, the following provisions are defined: The Registry Operator MUST specify in the Registry-Registrar Agreement for the Registry Operator¹s TLD that the Registrar MUST accept and process payments for the renewal of a domain name by a URS Complainant in cases where the URS Complainant prevailed. The Registry Operator MUST specify in the Registry-Registrar Agreement for the Registry Operator¹s TLD that the Registrar MUST NOT renew a domain name to a URS Complainant who prevailed for longer than one year (if allowed by the maximum validity period of the TLD). 3. Handling the URS Suspension of domains when the domain has child hosts. The redirect of the domain with child hosts could impact many other domains outside that TLD, since the resolution of those name servers will not or should not work. If a registry shares the same pool of name servers across TLD's, the glue for the child hosts might be returned in DNS, but the resolvers might not trust cross-TLD name server glue. Consider the case of URS Suspension domain foo.com with child host ns1.foo.com, where bar.net uses ns1.foo.com as a name server. A query for bar.net could include the IP addresses for ns1.foo.com, but since .com and .net are different TLD's the resolver could and most likely independently attempt to resolve ns1.foo.com. Resolution of ns1.foo.com will not work if foo.com is redirected to the URS Provider's name servers. This issue impacts TLD's outside of that registry, since they most likely would not have the glue. There might be nothing that can be done about potentially breaking resolution of other domains using child name servers of a URS Suspension domain, but we should discuss it and determine if there is anything that needs to be done to minimize the impact. GL - It's difficult to know which domain names depend on another domain name as separate entities administer separate sections of the DNS tree. However, this seems to be a corner case. It would seem unlikely that URS suspended domain names will be used to define hosts of other domain names, as the expectation is that these domain names are not used for legitimate purposes, but we will work with URS providers to add some text that advises the Registrant of the URS suspended domain name that he/she should notify other Registrants which domain names may depend on the URS suspended domain name to take the appropriate action. 4. A related topic to #3 is what to do with the child hosts when a URS Suspension domain is auto-deleted / auto-purged at expiry. In our registries, a domain cannot be deleted if there are child hosts being used as name servers for other domains in our registry database. The registrars will typically rename the child hosts under another domain to allow for the domain to get deleted. My recommendation is to remove the serverDeleteProhibited status at expiry of a URS Suspension domain instead of auto-deleting or auto-purging it, and allow the domain to auto renew. The Registrar can and will most likely go ahead and delete the domain during the auto renew grace period following the existing process that they follow in deleting domains with child hosts being used as name servers for other domains. I recommend disallowing the use of the RGP restore command for URS Suspension domains that entered RGP after deletion. Without the ability to restore, the domain will propagate through the RGP statuses (redemptionPeriod and pendingDelete) prior to getting purged from the registry, which is consistent with how domains are currently deleted. GL - When creating the draft of the URS technical requirements, we followed the strategy that if something is not clear in the URS Procedures, we should follow the normal registration life cycle. Your suggestion follows this strategy; therefore we believe your proposal is adequate. The activation of serverUpdateProhibited during URS Lock and URS Suspension should be enough to prohibit the restore from working, therefore there is no need to specify that a Registrar should not send a restore command for URS suspended DNs or that the Registry should disallow restore, correct? Comments from Rubens Kuhl: As the second version still shows issues that the community addressed in the past for domain registrations, it seems to us that registries should handle URS providers the same ways they handle domain registrars: thru EPP. URS providers could have proper EPP credentials that would allow them to make a limited set of transformations (URS Suspension, URS Lock, URS Roll-back) to every domain in the registry (except for mandatory domains like NIC or WHOIS). Everything we are trying to do with e-mail have already been done with a higher degree of process integrity thru EPP. GL - The idea of using EPP has been discussed internally and was also mentioned during the conference call. Defining EPP extensions, requiring registries to modify their SRS implementations and requiring URS providers to implement EPP may be over engineering if we don't know the volume of URS procedures and the URS Procedures define email as the interaction mechanism. In case that the volume of URS procedures is high and the community believes that EPP support is required, ICANN is willing to consider transitioning the process to EPP. Comments from Kal Feher: Under what circumstances would a name transition from URS Suspension to URS Lock? I am referring to your Note under the definition of URS Lock. I¹ve reviewed both the technical and non-technical requirements and neither explain when this would occur. GL - This is an unlikely scenario, and the purpose of the note is that if this transition is required, the Registry Operator regenerates the glue records. Also will there be further detail on how URS interacts with other processes, such as UDRP? GL- Section 3(g) of the URS rules define: A URS Complaint may not be filed against a domain name that is part of an open and active URS or UDRP case. Regards, Gustavo

3 2

Re: [gtld-tech] URS technical requirements, comments and questions
by Luis Muñoz Sept. 7, 2013

Sept. 7, 2013

A related question to the list, On Sep 6, 2013, at 10:13 PM, Rob Golding wrote: >> 2. The text in requirement 9 "Registry Operator MUST offer the option >> for the URS Complainant to extend a URS Suspended domain name >> registrations for up to one year from the date the domain name was >> Suspended", sounds like the renew command behavior needs to change for >> URS Suspension domains > > Why ? Allowing them to renew (at the Registrar) if it _expires_ makes sense. > > Allowing it to be extended 174 days before expiry by 365 days ( 1 year ) > will break all sorts of things. In addition to this point, what is the practical purpose of this renewal? What is the purpose of prolonging the period during which a domain affected by URS is showing a "URS suspended" page? Specially if the subordinate host objects were removed or otherwise rendered inoperable. If the URS complainant effectively has rights to the domain in dispute, why not simply give her complete control of the domain in dispute? At that point the complainant can do as she pleases with the domain through regular channels, including dealing with subordinate objects. Best regards -lem

1 0

Re: [gtld-tech] URS technical requirements, comments and questions
by Mike O'Connor Sept. 7, 2013

Sept. 7, 2013

um… i admit it -- i haven't been following this too closely. but this thread looks like it's turning into a policy discussion rather than a "technical requirements" discussion. could somebody kinda bring me up to speed on the state of play of the underlying policies? sorry to be such a dolt. the PGP discussion fit in my expectations for what's supposed to happen on this list, but this seems a bit far afield. didn't most of these issues go through some kind of policy process already? thanks, mikey On Sep 6, 2013, at 9:13 PM, "Rob Golding" <rob.golding(a)astutium.com> wrote: >> The proposal is to show a warning message when filling the URS procedure >> if the domain name is within the last month of validity, explaining that >> the domain name may be deleted during the URS process and the process >> will be terminated. > > Certainly _if_ the domain is (actually) deleted (i.e. has gone through > expiry/redemption/whatever all the way to the final-actual-definate 'really > is' deletion, then yes, that should end the URS > >> 2. The text in requirement 9 "Registry Operator MUST offer the option >> for the URS Complainant to extend a URS Suspended domain name >> registrations for up to one year from the date the domain name was >> Suspended", sounds like the renew command behavior needs to change for >> URS Suspension domains > > Why ? Allowing them to renew (at the Registrar) if it _expires_ makes sense. > > Allowing it to be extended 174 days before expiry by 365 days ( 1 year ) > will break all sorts of things. > >> The renew command should extend from the prior >> expiration date and not the date the domain name was suspended > > Absolutely. > > However I don't agree that 'random-3rd-party' (URS complainant) shouldn't be > able to just 'renew' (extend) the registration of a domain name *unless* > it's expired/expiring. > > >> I recommend that the registries allow for the renew of URS Suspension >> domains and leave it up to the Registrars to ensure that the renew is >> done at most once for URS Suspension domains, by the URS Complainant, >> according to the Registry-Registrar Agreement. > > Having the registry reject any renewal for > 1 year (and for a 2nd time) on > a URS locked domain (with such restrictions to be removed when the URS lock > is removed) does make the most sense. > >> Registry Requirement 9: In cases where a URS Complainant (as defined in >> the URS Rules) has prevailed, Registry Operator MUST offer the option >> for the URS Complainant to extend a URS Suspended domain name's >> registration (if allowed by the maximum validity period of the TLD). > > No, not option by the *registry operator* given to the *urs complainant* > > Has to be the registrar renewing it ... wording is wrong. > > Can be written much simpler as > > == > Registry Requirement 9: > Registry Operator MUST allow REGISTRAR OF RECORD to extend the registration > of (renew) a URS Suspended Domain Name a maximum of one period whilst domain > is USR locked (if allowed by the maximum validity period of the TLD). > == > Then nothing else about who pays or who requests it etc is necessary. > >> Registry Operator MAY collect the renewal fee paid by the URS >> Complainant for the URS Suspended domain name from the sponsoring >> Registrar of the domain name. > > They wont if the renewal fee wasn't paid to the registrar ! > >> The Registry Operator MUST specify in the Registry-Registrar Agreement >> for the Registry Operator's TLD that the Registrar MUST accept and >> process payments for the renewal of a domain name by a URS Complainant >> in cases where the URS Complainant prevailed. > > There can be no "MUST" - we -like most countries - have restrictions on who > we can do business with. Similarly we always reserve the right to choose who > we do business with - you cannot enforce a MUST on the Registrar to take > money and/or process it from an "unknown entity" (the URS Complainant) - > people who we may not legally, logically, ethically, any-other-ally accept > money from or do business with. > > Similarly, anyone we take money from has to have agreed to our terms and > conditions, and if they haven't, we don't want their business or their money > - USR complainant or otherwise. > >> The Registry Operator MUST specify in the Registry-Registrar Agreement >> for the Registry Operator's TLD that the Registrar MUST NOT renew a >> domain name to a URS Complainant who prevailed for longer than one year >> (if allowed by the maximum validity period of the TLD). > > Is dealt with above. > >>> 3. Handling the URS Suspension of domains when the domain has child >>> hosts >> GL - It's difficult to know which domain names depend on another domain >> name as separate entities administer separate sections of the DNS tree. >> However, this seems to be a corner case > > It's be a criminal case if you redirected the child hosts or the responses > from nameservers. > > If foo.bar had ns1.foo.bar and blah.blah used ns1.foo.bar as a nameserver > Then on suspension and redirection of foo.bar there *MUST* be no record for > ns1.foo.bar so dns would "stop" > - anything else would be illegal > > I'm not sure there should even be any redirection of foo.bar itself going on > > >> URS providers could have proper EPP > > With the potential for them to screw up and the potential knock on 'damage' > and claims that would ensue, I'd rather not see any URS provider have access > to a computer, and make this all done on multi-part carbon-copy forms. > > Regards, > Rob > -- > rob.golding(a)astutium.com www.astutium.com 020 3475 2555 > Astutium Ltd, 1st Floor, Number One Poultry, London, EC2R 8JR > Registered in England (UK) / Company #8183381 / VAT #145054825 > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

2 1

Re: [gtld-tech] URS technical requirements, comments and questions
by Michele Neylon - Blacknight Sept. 7, 2013

Sept. 7, 2013

On 7 Sep 2013, at 02:19, Gustavo Lozano <gustavo.lozano(a)icann.org> wrote: > > > GL - The text needs to be clarified, as the idea behind Requirement 9 is basically what you are proposing. This is the proposed new text: > > Registry Requirement 9: In cases where a URS Complainant (as defined in the URS Rules) has prevailed, Registry Operator MUST offer the option for the URS Complainant to extend a URS Suspended domain name's registration (if allowed by the maximum validity period of the TLD). Registry Operator MAY collect the renewal fee paid by the URS Complainant for the URS Suspended domain name from the sponsoring Registrar of the domain name. That last sentence doesn't make any sense. Registry Operators do not collect the fees paid by anyone other than the registrar- they collect the fees they charge the registrar. Period. Registry X charges registrar $10 / year Registrar Y charges registrant (or in this case the URS complainant) their retail rate for the domain So if I want to charge $30 / year and Rob wants to charge $15 / year then that's our business model and not relevant to this policy. As long as we pay the registry for the renewal .. Put another way, there's no direct relationship between the Registry Operator and the URS Complainant. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation http://www.blacknight.co/ http://blog.blacknight.com/ http://mneylon.tel/ 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

2 1

URS, PGP or S/MIME
by Gustavo Lozano Sept. 6, 2013

Sept. 6, 2013

Colleagues, The second version of the URS High Level Technical Requirements defines S/MIME as the authentication and non-repudiation mechanism for the interaction between URS providers and Registries, and for the communication between URS providers and Registrars. Several emails to the list and private messages suggest that PGP should be used instead of S/MIME. We believe that either PGP or S/MIME could be used. The PGP solution that we envision would be like this: * ICANN gathers the valid PGP keys from Registries and URS providers. * ICANN maintains and publishes a keyring of URS providers PGP keys and a keyring of Registry Operators PGP keys. Each keyring would be signed with ICANN's PGP key and published on an HTTPS site. * Registry Operator/Registrar downloads the keyring of URS providers PGP keys frequently (every 12 hours appears to be appropriate considering the 24 hour windows to URS lock a DN and the potential revocation of a compromised key). * URS provider downloads the keyring of Registry Operators frequently. * ICANN provides a list of "TLD, PGP key id" to URS providers (we could use the comment field of the PGP key to identify the TLD(s), but a simple CSV file appears easier). The S/MIME solution that we envision would be like this: * ICANN provides a list of "TLD, authorized email address" to URS providers. * ICANN provides a list of "URS provider, authorized email address" to Registry Operators/Registrars. * Registry Operators and URS providers obtain certificates from public CAs (the list of well-known root CAs in different software products and libraries do the rest). ICANN can accommodate either the PGP or the S/MIME solution. However, we believe we should only do one to avoid unnecessary complication. The question is: * What is your preference? For version three of the URS technical requirements, we will define whatever the majority believes is the best approach. Regards, Gustavo

9 8

Second version of the URS High Level Technical Requirements for Registries and Registrars
by Gustavo Lozano Sept. 3, 2013

Sept. 3, 2013

Colleagues, Attached you will find the second version of the "URS High Level Technical Requirements for Registries and Registrars" and a redline version of the document. This second version incorporates the feedback obtained from the conference call on August 07. We appreciate your feedback. Please send your feedback to the list or in private. Based on the feedback in this list, a new conference call may be required or this version may be published as the final version. Registry Operators will know the name servers deployed by the URS providers soon, in order to allow Registry Operators to create host objects (if necessary). Thank you, Gustavo

6 7