ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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

Re: [registrars] Transfers TF Report


So then what is the process for requesting a vote on any proposition?

                       -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: "Michael D. Palage" <michael@palage.com>
To: "Ross Wm. Rader" <ross@tucows.com>; <registrars@dnso.org>
Sent: Tuesday, December 03, 2002 4:35 PM
Subject: RE: [registrars] Transfers TF Report


> Ross,
>
> The Executive Committee is going to be working on the formal ballot in
> connection with the Whois & Transfer Task Force. Although I see how your
> points are relevant toward getting people to make a decision. I thought a
> more appropriate ballot would be along the lines of:
>
> [ ] I support the Transfer's Task Force report in whole;
> [ ] I support most of the principles contained within the Transfer's Task
> Force, but believe that addition clarification needs to be addressed by a
> registrar/registry implementation committee, i.e. dispute resolution
> procedures, standardize language, etc.
> [ ] I cannot support the principles contained within the Task Force
report.
>
> This is just a proposed ballot that I just typed up. This succinct ballot
> gives our names council representatives much more clear guidance, IMHO.
>
> Again, the exact format of the ballots will be discussed during the next
> Exec Call.
>
> Mike
>
>
>
>
>
> -----Original Message-----
> From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> Behalf Of Ross Wm. Rader
> Sent: Tuesday, December 03, 2002 3: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
>



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