Re: [registrars] EPP Informed Consent

["Joyce Lin" <joyce@007names.com>]

I like the EPP auth_code idea, it eliminates lots of side issues that we are
currently facing.  The burden is more on the losing registrar who has to
make sure that the code is given to the party with authority.

Joyce Lin
007names.com


----- Original Message -----
From: "Michael D. Palage" <michael@palage.com>
To: "Ross Wm. Rader" <ross@tucows.com>; <tim@godaddy.com>;
<registrars@dnso.org>
Sent: Tuesday, December 03, 2002 5:32 PM
Subject: [registrars] 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
> >
> >
>
>