[gtld-tech] gtld-tech URS technical requeriments

[Neuman, Jeff]

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 at 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 at 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 at iecc.com]
>>> Sent: Monday, July 08, 2013 06:29 PM
>>> To: Gustavo Lozano <gustavo.lozano at icann.org>
>>> Cc: gtld-tech at icann.org <gtld-tech at 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 at 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.)
>