Re: [Re: [Re: [Re: [ga] Re: Transfers: Apparent Authority Discussion]]]

[Jeff Williams <jwkckid1@ix.netcom.com>]

Loren and all assembly members,

Loren Stocker wrote:

> Dear Ross,
>
> Good comments, Grasshopper. This is "research," I believe.
>
> Ross, your comments and mine from a different point of view. I'm a vulnerable
> Registrant and you an eager-to-grow Registrar. We both have good ideas but
> where I want FAILSAFE you want EASY transfers.

  Good point here Loren.  And again one that has been made many
times in the past over more than a years period, from time to time.
I don't see why fail-safe transfers can't also be easy if the Registrant
can control such a transfer themselves.

>
>
> You make a dangerous assumption when you say the, "Gaining registrar is a
> representative of the registrant." How can you really know this?

  Well of course Ross nor any other registrar can accurately make such
a statement in fact.  As you recall Loren, Chuck Gomes made this
inference in his comments/presentation last week in the Phone
Conference on Tuesday I believe...  And of course such a
thought is not realistic.

> This is the
> essence of the problem and the 80/20 fix. What you are really supporting is
> one-party consent with NO fail-safes. What good are published guidelines when
> mistakes lead to disasters?

  A very good question, and why this subject area along with Deleats is
so important and even being discussed and debated...

>
>
> Having the losing Registrar validate is essentially a double check, or a
> two-party consent model. Inherently, the gaining Registrar validates that they
> are working with who they think is the Registrant, or they wouldn't process
> the transfer. Do you agree? The motivation is that they want to remain
> accredited, so they play by the rules.
>
> Then, under my proposal, the losing Registrar agrees to the domain being
> released. Of course they check with me. And they don't get to vote! This is
> Two-party consent. It also has a failsafe in that the losing Registrar, KNOWN
> to be my agent, has a duty to me. I can also ensure that I have legal recourse
> -- domestic legal recourse -- when I use Bulk Register as my Registrar as I
> did in this recent fraud (I use and love Tucows too!).
>
> Under the absurd system of today, Registrars have the ungodly powers to take
> my domain when they THINK they represent the real Registrant. You must
> understand that makes me vulnerable to theft from anywhere on Earth
> -- most of which I have no practical legal recourse!

  This also is and has been a key point.  Jurisdiction is a serious problem
with some Domain Names should a dispute arise or a inadvertent
or purposeful transfer/modification occur...

>
>
> In my real-world, real-time example: how am I now to sue someone in
> Copenhagen, DK -- the phony Registrant? Or the Canadian Registrar who's system
> allowed a "deep link," thus bypassing the validation software? Then, once the
> domain was "whitewashed," the current Registrar processed the third transfer
> for the current "Registrant of record," and is so motivated to ignore my
> problem. Possession rules! There are no Subscriber Rights. Just possession.

  Yes and this is a vehicle for thieves, regardless of their status...

>
>
> Today we have one-party consent with no fail-safes. Sure, those of us who are
> in-the-know will use "locks" and enable "transfer-aways," but the vast
> majority will have to get screwed first to know to do this. The system should
> fail-safe... no just fail the Registrant as it does today.
>
> Put another way, when the vast majority of inmates on death-row are guilty,
> those with a "vested interest in .... portability" might say the system is
> good and efficient. But, I say when 3% of the inmates are innocent, the system
> MUST be changed. This is not an option. We can not allow this crazy system to
> harm end users for convenience of the Registrars. Two-party consent works fine
> in the SMS/800 toll-free database and we do transfer consent by Fax!
>
> I do not believe that a confirmation e-mail from Verisign is "unintended
> benefit." It is partly due to rampant fraud that they too have had to deal
> with. NSI created two-party consent within the insane system in place today.
> What's the big deal with confirming a transfer? If I get peace of mind, it's
> worth it. Why make this safe-guard into an "anti-competitive" villain?
>
> In fact, the real problem here is that bulk transfers -- which I do each month
> -- lead to dozens of individual confirmations. It's not the confirmation but
> the inconvenience of the confirmation that I have an issue with. Also the
> speed and accuracy. It seems to take a week or so between submission and
> confirmation. I always confirm twice, because it seems 10% of the
> confirmations get lost. This process can be mandated to be efficient and safe.
> Within the SMS/800, for example, toll-free numbers are transfer within 48
> hours, given a clean request.
>
> Incidentally, Tucows's does not provide "transfer-away" notice by default. I
> was walked through the step-by-step procedure to set up "transfer away," as
> noted in the e-mail I sent Ross off-list. Bulk for sure didn't provide any
> notice. My domain simply vanished.
>
> Keep in mind that one-party consent and "notice" are not as safe as two-party
> consent. It's an improvement, but not as safe. "Locks" are in most cases
> overkill, and inhibit transfer by requiring manual unlocking (see "Domain Lock
> Downside" on the Opensrs discussion list, today 01:05 PM PDT, 05/27/2002).
>
> What we proposed is a two-party consent model, no exceptions. Today's system
> is one-party consent, with manual "notice" and "locks" enabled by those in the
> know. Ideally, why can't we have a two-party consent that is fast, accurate,
> and BULK enabled? I don't see how any gaining Registrars would be hurt by a
> confirming e-mail (between the losing Registrar and Registrant). Registrants
> will still move their domains for all the reasons mentioned, whether the
> losing Registrar likes it or not! Clearly, some Registrants are being harmed
> by the existing system when it fails. So why hang on to a failed experiment?
>
> Finally, this piecemeal path to Nirvana is nuts! It is hard to believe that a
> "Redemption Grace Period" proposal -- although helpful -- is as comprehensive
> as conferring "Subscriber Rights," which offers vision and purpose for the
> re-design of the transfers, deletions, and wholesale pricing policies. If all
> rights are derived from the subscriber, then all policies are easily designed
> to support those rights.
>
> Baby-steps are not what's needed here. It is the health of the forest -- not
> the few sick trees we've happened to notice -- that's at stake!
>
> Best Regards,
>
> Loren Stocker
> www.800.net
>
> "Ross Wm. Rader" <ross@tucows.com> wrote:
> > Hi Ross,
> >
> > Unforunatly, like many Registrant's I can only jump on occasion. My ideas
> > and
> > limited time are all I can contribute. Would love a summary off-list of
> the
> > existing proposals, if availble (Maybe a link to an article?).
>
> http://www.dnso.org/clubpublic/nc-transfer/Arc00/msg00152.html
>
> >
> > Yet, for us the issue of WHO does transfer validations is 80/20 question.
> > Move
> > this to my agent and you've solved 80% of the problem! The rest may be
> give
> > and take details. Also, it's important not to let NSI's behavior be a
> > distraction. A good policy with compel them to behave in the best interest
> > of
> > the Registrant.
>
> But what you forget is that the Gaining registrar is a representative of the
> registrant. The transfer issue is not about hijackings - some may choose to
> paint it as such, but the core of the problem are those registrars that
> ignore the wishes of the registrant. Further to this, the IRDX document very
> clearly spells out how and to whom verification must be obtained prior to a
> transfer request being filed.
>
> > Few recognize that NSI's double-check proceedure is really for the
> > protection
> > of the Registrant -- given today's crazy system.
>
> With all due respect, this is a position adopted by VRSN to draw attention
> away from the fact that they are reacting to the effects of healthy
> competitive. This reaction was necessary because they are failing to compete
> in a number of ways. The easiest way for them to stop the bleeding to other
> registrars was to simply not let customers leave. Their reaction to this
> economic imperative is, at best an unintended benefit, and at worst, an
> anti-competitive move made strictly with the intent of disrupting the
> business' of their competition and limiting the free market rights of tens
> of thousands of registrants.
>
> As you mention, "Thief's, of course, use NSI's back-door fax process to
> avoid being detected.". A default n'ack policy does not solve this reality.
> Given that VRSN is a world-leader in trust services, one would think that
> this would be a trivial exercise for them to solve. They haven't - and
> instead, have forced tens of thousands of registrants to suffer in turn.
>
> > Neither Bulk nor Tucows had -- be default -- any
> > communication
> > to the Registrant when a domain was stolen! I don't actually know if other
> > domains have been stolen of my accounts.
> >
>
> I can't speak for Bulk, but our clients receive notice of any transfer
> requests that we receive.
>
> > As to recovery, Subscriber Rights are essential. Without them we are faced
> > with a cost prohibitive "court intervention." If anyone hsn't seen the
> > "Impvle
> > Propoals for Subscriber Rights it is now posted on WWW.EVIL.BIZ.
> >
>
> Responsible use of registrar lock as well as the current "Redemption Grace
> Period" proposal appropriately address what you are trying to solve. To
> restrict the portability of domains because of the bad security practices of
> a precious few registrars is something that I can't imagine would be well
> received by the tens of thousands of other registrants that do have a vested
> interest in true registrar to registrar portability.
>
>                        -rwr
>
> "If we knew what we were doing, it wouldn't be called research, would
> it?" -- Albert Einstein
>
> Please review our ICANN Reform Proposal
> Old Skool DNS Address: http://www.byte.org/heathrow
>
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 124k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-244-3801 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html