ICANN/DNSO
DNSO Mailling lists archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

[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



<<< Chronological Index >>>    <<< Thread Index >>>