[gtld-tech] gtld-tech URS technical requeriments

Neuman, Jeff Jeff.Neuman at neustar.us
Tue Jul 9 13:07:46 UTC 2013

I guess my point in this is that we should be concerned with the "what" are registries and registrars supposed to do as opposed to the "how".  And from my re-reading of the AGB, it seems like that document for the most part does an ok job in that.

ICANN should not be mandating that any of this be done in an automated fashion, nor should it mandate things like "all e-mails sent by Registry Operator to the URD Provider MUST be cryptographically signed using a S/MIME certificate....."

The whole thing just seems unnecessarily prescriptive to me.  Frankly I would rather ICANN be spending its time worrying about getting up the testing environment with the TMCH than with this, but that may just be me.

Jeffrey J. Neuman 
Neustar, Inc. / Vice President, Business Affairs

-----Original Message-----
From: James Mitchell [mailto:james.mitchell at ausregistry.com.au] 
Sent: Monday, July 08, 2013 11:15 PM
To: Neuman, Jeff; Mike O'Connor
Cc: John R.Levine; gtld-tech at icann.org
Subject: RE: [gtld-tech] gtld-tech URS technical requeriments

Do we need this? Yes.

A standard/specification is required if there is to be a consistent implementation across all registries. Seeking an update on URS technical/process issues was on our agenda for Durban - instead we can now discuss moving this forward (in whatever direction that may be). Thanks to Gustavo for getting this document out, and the discussion rolling.

James Mitchell / Product Owner
ARI Registry Services

> -----Original Message-----
> From: gtld-tech-bounces at icann.org [mailto:gtld-tech-bounces at icann.org]
> On Behalf Of Neuman, Jeff
> Sent: Tuesday, 9 July 2013 11:07 AM
> To: Mike O'Connor
> Cc: John R.Levine; gtld-tech at icann.org
> Subject: Re: [gtld-tech] gtld-tech URS technical requeriments
> 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.)
> >

More information about the gtld-tech mailing list