[registrars] RE: EPP Informed Consent

["Tim Ruiz" <tim@godaddy.com>]

>I think if you look at my .US proposal and then the constructive comments
of
>Bruce based upon .au policy, I think EPP has everything we need.

Mike,

I would mostly agree. There are a few areas that some will take issue with,
but I don't see anything that can't be smoothed out to a workable solution.

Tim

-----Original Message-----
From: Michael D. Palage [mailto:michael@palage.com]
Sent: Tuesday, December 03, 2002 4:32 PM
To: Ross Wm. Rader; tim@godaddy.com; registrars@dnso.org
Subject: EPP Informed Consent


Ross,

I think if you look at my .US proposal and then the constructive comments of
Bruce based upon .au policy, I think EPP has everything we need.

Regarding informed consent based on the .au model:

(1) the registrant and/or admin contact can only get the auth code from his
registrar (losing registrar), thus adequate safeguards can be implement
here;

NOTE: Under the PIR (.ORG) agreement and my .US proposal, the registrar auth
codes must be unique (added security)

(2) the registrant and/or admin contact must then submit this to the gaining
registrar;

(3) gaining registrar must send and receive confirmation email;

Game, set, match - bye, bye apparent authority - hello expressed authority
with no ambiguity

Mike


-----Original Message-----
From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
Behalf Of Ross Wm. Rader
Sent: Tuesday, December 03, 2002 5:11 PM
To: tim@godaddy.com; registrars@dnso.org
Subject: Re: [registrars] Transfers TF Report


> I would like to suggest though that EPP HAS become an issue. It has been
> implemented by three gTLD registries, and soon to be four. True, EPP is no
> magic bullet. But, as you point out, it does help to solve the issue of
> authorization and that is no small issue from our perspective. Properly
> implemented, an auth-code type solution, EPP or otherwise, could
streamline
> and simplify the transfer process.

Agreed - my implication re: EPP is that a) there is a lot that we don't know
about it, practically speaking and b) that it only solves half the problem
(ie - "authentication" and not "informed consent")



                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog
----- Original Message -----
From: "Tim Ruiz" <tim@godaddy.com>
To: "Ross Wm. Rader" <ross@tucows.com>; <registrars@dnso.org>
Sent: Tuesday, December 03, 2002 4:39 PM
Subject: RE: [registrars] Transfers TF Report


> Ross,
>
> You present some persuasive arguments.
>
> I would like to suggest though that EPP HAS become an issue. It has been
> implemented by three gTLD registries, and soon to be four. True, EPP is no
> magic bullet. But, as you point out, it does help to solve the issue of
> authorization and that is no small issue from our perspective. Properly
> implemented, an auth-code type solution, EPP or otherwise, could
streamline
> and simplify the transfer process.
>
> That said, I do agree that what we have to decide now is whether what has
> been proposed in the report truly solves any problems today. We have been
> reviewing the report in detail and comparing it to the current situation.
> Our decision will based on that analysis.
>
> Tim
>
>
> -----Original Message-----
> From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> Behalf Of Ross Wm. Rader
> Sent: Tuesday, December 03, 2002 2:28 PM
> To: registrars@dnso.org
> Subject: [registrars] Transfers TF Report
>
>
> Title: "Three or Four (or Six) Reasons Why We Should Support This
Report..."
> Summary: Please vote in favor of the motion that I just tabled.
>
>
> Reason #1 - "We have taken far too long in dealing with this issue." This
is
> simple. Its taken almost two years to get to this point. That is far too
> long. Further delay doesn't mean much more than "further delay". We should
> have had this cleared up more than a year ago, but we didn't. Let's not
> waste the opportunity that we have in front of us to clear the issue up
> *now*.
>
> Reason #2 - We will never have a perfect solution. As it currently stands,
> the perfect solution, in my books, is one that we can implement. These
> recommendations are implementable and therefore deserve our support.
Perfect
> solutions do not exist, but perfect solutions are more common than
practical
> ones that satisfy everyone's political sensibility. Let's not waste the
time
> and effort that has gone into this report. This solution is workable
without
> putting any registrar or registry out of business because of the attendant
> complexity.
>
> Reason #3 - Getting EPP working will create different problems. EPP isn't
a
> magic bullet. All EPP does is make it easier for registrars to figure out
> whether or not someone is authorized to request a transfer. EPP does not
> tell us if the person making that request is doing some from an informed
> perspective. In other words, EPP itself does not stop registrars from
> slamming through inappropriate marketing. In some respects, it almost
makes
> it easier. Let's deal with EPP when EPP becomes an issue. I fully believe
> that the recommendations of this report will allow us to avoid some of the
> "out-of-the-box" problems that EPP will pose, but if it doesn't, lets take
a
> look at the issue when we have some experience with EPP. Let's not defeat
> this report because of what we don't know about EPP, let's approve this
> report because of the problems that it will solve today.
>
> Reason #4 - This solution has buy-in outside the Constituency. Again very
> simple. Over the past two years, this is the only series of
recommendations
> that has buy-in from Registrars, Registries and Registrants. It is not
easy
> to get all of these parties to see eye-to-eye, lets not waste this
> opportunity to get what we all want. Voting to defeat this report would
> represent a sell-out of these groups to our own self-interest. Let's avoid
> the tremendous hit in credibility and vote to approve this report.
>
> Reason #5 - The recommendations can change after they are approved. The
> report advocates that ICANN take a look at how things are going every once
> in a while. If things aren't going well, the Constituency can always
change
> its mind and request that the NC take a second look at the policies. We
> don't have this opportunity now and we would stand to gain through some
> "learning by doing" policy development vs. the guess work that we are
doing
> now.
>
> Reason #6 - I take this directly from the report because it is important
and
> speaks for itself. " The recommendations contained in this report are the
> product of an open and transparent process that took place over the course
> of a year. Hundreds of hours of discussion were devoted to the topic, many
> proposals were considered, dozens of revisions were proposed and thousands
> of words debated the merits of specific recommendations and alternate
> approaches. In other words, a process took place by which the best
> recommendations were substantively discussed, clarified, compromised and
> eventually manifested themselves as the consensus recommendations
contained
> in this report.
>
> The Task Force believes that it is this approach, the process, which
> represents the single most compelling argument in favor of adopting these
> recommendations. The fact they do represent the best ideas of the
community,
> the ones upon which we most agree and perhaps most importantly, the ones
> with the most understood and refined impact. This is not to say that
> concepts and ideas that did not make it into this report were not good or
> well-considered, to the contrary, there were many that were. But, these
> bright ideas did not get the support of the community necessary to include
> them as a consensus recommendation of this report. Similarly there were
also
> many reasoned criticisms of these recommendations that were put forward.
> But, unless they were shared by a reasonable cross-section of the
community,
> it was equally impossible to put them forward as the consensus of the
> community. This is one of the features of the consensus policy development
> process - both the consensus support and consensus disagreement must be
> substantively dealt with. Again, the Task Force believes that it has
> fulfilled this required.
> However, we have no presumptions that new consensus ideas and dissent
won't
> emerge from the DNSO. Accordingly, we have attempted to temper these
> recommendations with very finite and predictable review mechanics that
will
> allow the DNSO to adjust or correct the policy over the short, medium and
> longer terms. We believe that a moderate approach of this nature ensures
> that the policy in effect will continue to reflect the will of the
community
> for the foreseeable future.
>
> The consensus policy development process is neither easy nor trivial. Nor
> should it be. Appropriate processes lead to appropriate results. Balanced
> processes lead to balanced results. The Task Force believes that the
> processes employed in the development of these recommendations are both
> balanced and appropriate, but to the extent that the results need to be
> adjusted, a similarly balanced and appropriate approach should be taken so
> as to ensure the continued integrity of the results."
>
> I remain available for questions or clarifications...
>
>                        -rwr
>
>
>
>
> "There's a fine line between fishing and standing on the shore like an
> idiot."
> - Steven Wright
>
> Got Blog? http://www.byte.org/blog
>
>