Re: [registrars] Proposed Ballots

["Ross Wm. Rader" <ross@tucows.com>]

> I propose a friendly amendment to that part of the ballot so it
> would simply read:
>
> "- that delegants and operators be encouraged to leverage existing
registry
> protocols"

I could back that. Not sure what the process is for accepting friendlies,
but if this is it, then I am (will?) :)

At the very least, the amendment has my support.

                     -rwr




Got Blog? http://www.byte.org

"People demand freedom of speech as a compensation for the freedom of
thought which they seldom use."
 - Soren Kierkegaard



----- Original Message -----
From: "Tim Ruiz" <tim@godaddy.com>
To: <ross@tucows.com>
Cc: <michael@palage.com>; <registrars@dnso.org>
Sent: Thursday, April 03, 2003 6:44 AM
Subject: RE: [registrars] Proposed Ballots


> I don't have a problem with the concept of accrediting registry providers.
> I just have a hard time imaging anyone going to the trouble and expense
> without a solid deal in place. So if a delegant must have an accredited
> provider on board to apply, I still see it only being the existing
> providers. And if the delegant wants to be their own provider it shouldn't
> be a two step process: 1) become an accredtied provider; 2) propose the
> gTLD. As long as that's not what is intended here, I'll be on board with
it.
>
> On the protocols statement, it's the "not create new ones" phrase that
> bothers me. I propose a friendly amendment to that part of the ballot so
it
> would simply read:
>
> "- that delegants and operators be encouraged to leverage existing
registry
> protocols"
>
> Tim
>
>  -------- Original Message --------
>    Subject: RE: [registrars] Proposed Ballots
>    From: "Ross Wm. Rader" <ross@tucows.com>
>    Date: Wed, April 2, 2003 8:06 pm
>    To: "'Tim Ruiz'" <tim@godaddy.com>, "'Michael D. Palage'"
> <michael@palage.com>,
>          <registrars@dnso.org>
>
>    > I understand the purpose, but in practice, will this require
>    > gTLD applicants to have a prior arrangement with an
>    > accredited provider? Or only that if approved, they must
>    > either become or use an accredited provider? I'm not sure I'm
>    > getting how this will facilitate competition. It seems a
>    > little like the chicken or the egg issue.
>
>    It simply builds incentives for prospective delegants to choose from
>    operators other than the Neulevel, Afilias or Verisign. If every
>    single new delegant chooses an existing operator, then we don't see
>    the real benefits of competition - we end up creating a bunch of new
>    TLDs, as you point out, that each of us care about to differing
>    degrees. Registrars saw a lot of benefits that were created when
>    Neulevel and Afilias pushed the envelope. Verisign has mostly caught
>    up now and we've stopped seeing a lot of the benefits. We need more
>    players - technical and otherwise.
>
>    >
>    > >- that delegants and operators be encouraged to leverage existing
>    > registry
>    > >protocols and not create new ones
>    >
>    > This seems to imply that the best protocols already exist. I
>    > agree that life would be much easier if we had a single
>    > protocol to deal with. On the other hand I would not want to
>    > stifle innovation and potential future benefits to save a
>    > little time today. Besides, so far, even with EPP, each
>    > implementation has been different. I don't think we could
>    > support this ballot with this comment as part of it.
>    >
>
>    No, it implies that new operators should be encouraged to use existing
>    protocols unless they have demonstrably better ideas. These are the
>    same rules that we played by in the last round and instead of creating
>    a bunch of new RRP registries, we ended up with a bunch of players
>    that worked together and settled on a better idea. We should continue
>    to encourage this spirit of cooperation.
>
>    If you have a better way to get these points across, please put
>    forward an amendment - positive criticism is always a useful tool for
>    change.
>
>    -rwr
>
>
>
>