With all due respect, most of the registries that have been planning on actually launching at some point this year I would venture to say have either already built their functionality to do this or are otherwise planning to do this manually, both of which are acceptable options. We have pretty much known the rules now from the Guidebook for months - dare I say years for this. I am not sure who asked for a "standard" to be developed on this, but this is WAY too late in the game for icann to expect any registry to move to this new "standard" at this point in time. So I will ask the dumb question again...do we really need this? My question Sent from my iPad On Jul 8, 2013, at 7:42 PM, "Mike O'Connor" <mike@haven2.com> wrote:
hi all,
a few questions:
- is this really a "technical specification" or is it really a higher level document (maybe something along the lines of a functional requirements definition)? if i were a coder looking for a technical spec, i'd be sending this back with a little note saying "try again." is a technical spec to follow? or is it up to the registries/registrars to implement these capabilities within their own architecture?
- when does all the implementation (across registries and registrars) need to be complete? is there a testing cycle to see whether things work as expected? who leads that? what happens if it's not done on time or doesn't work right?
- is it expected that registries store the prior state of NS and DS records when a URS provider makes a request (i'll leave it up to Levine as to how they do it)? if the registries don't store that data (presumably using new code), how can they fulfill the requirements that prior data be restored in various use cases? if they do store it, who has access to that data? how does domain-name lifecycle information from registrars find its way into the stored data so that if the domain is restored, it's restored to the current (rather than the stored) state?
if this isn't due to roll out for a year, i think we've got time to react. if it's supposed to roll out in a few months, life's going to get interesting.
mikey
On Jul 8, 2013, at 5:39 PM, John R. Levine <johnl@iecc.com> wrote:
Let me ask the dumb question....do we really need a set of standard specs for this for a registry?
If URS exists at all (a battle that appears to have been lost quite a while ago) I would have to say yes, since if people roll their own, they'll likely make all the same security mistakes this spec does, and more.
The basic problem is that the Internet is not synonymous with web servers, but too many people forget that.
R's, John
----- Original Message ----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Monday, July 08, 2013 06:29 PM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
Please provide your feedback no later than Tuesday 23 of July.
Thanks for publishing this.
Unfortunately, the "URS Lock with Redirection" spec is a security disaster for e-mail, pariticularly since, as I understand it, a typical use for the URS will be to deal with typosquats of famous names such as páypàl.tld.
Do we just send comments to you or is there a more formal place? I expect that several anti-abuse organizations will want to weigh in.
R's, John
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)