ICANN/DNSO
DNSO Mailling lists archives

[ga]


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

Re: [ga] WLS Suggestion


karl and all assembly members,

Karl Auerbach wrote:

> On Thu, 22 Aug 2002, Kristy McKee wrote:
>
> > If this WLS process must be implemented, why not offer the Domain Name
> > Registrant the "opportunity" to pay more money per year to ensure that they
> > also have claim to their domain(s) within the WLS database.
>
> Presumably under WLS they have that - they simply buy into WLS.
>
> I have a question for you (and everyone on the GA list):
>
> I've been wrestling back and forth on the WLS issue.  I don't like giving
> NSI/Verisign yet another boon but I also don't like ICANN being a
> regulator of ever increasing size.

  I have no problem personally with Verisign getting a boon on anything
as long as it is not at the unfair expense of the stakeholders/users.
If Verisign or any other company has a "Better Idea" and can
effectively sell it as such, than more power to them.

  I do agree with you Karl that ICANN should not become
what it already has, an over imposing regulator and any 
further modify the registrar contract to include WLS 
as a Defacto standard for dealing with Deletes. 
ICANN should stay away from WLS all together.  On 
that biases alone the ICANN BoD should not vote in 
favor of WLS...

>
>
> This is a tough question and there are equities on all sides.
>
> My feeling is that I at the board meeting tomorrow morning that I will
> vote in favor of WLS but only on the condition that there are provisions
> that require the current registrant to know of the existance (and
> identity) of WLS entries placed on his/here domain name.  That, to my
> mind, helps restore the balance of information and lets all parties to the
> registration agreement attempt to optimize their actions.

  I would agree that the provision you suggest here Karl, would
help balance the interests of the registrants with the
Registrars/Registries.
My personal concern though is that can we trust Verisign to
insure this suggestion of yours takes place and can we also
be sure that the oversight of ICANN to insure that they do?
I say no we cannot...  ICANN has no provisions in the
current Registrar and Registry contracts to even enforce them
As-Is.  With the modification to encompass WLS we would
have an even potential and likely worse situation for 
the Registrant and other Registrars...

  Hence Karl, I would advise/ask that you vote against
Louis's suggestion and WLS...

>
>
> (It may not be black letter contract law, but I do feel that those who are
> parties to a contract ought not to be unreasonably manipulative of one
> another - particularly when the contracts are of an adhesive quality [and
> more particularly when the public isn't allowed onto the regulatory body
> that establishes many of the contractual terms].  And in the case of WLS I
> have always found it distasteful that the registry, who has an indirect
> contractual relationship with the registrant, might hold back information
> from the registrant that could be of value to the registrant.)
>
> This condition on the casting of my vote in favor is in addition to things
> like the pre-existance of the grace period mechanisms for at least 6
> months, etc etc.)
>
> Any comments?
>
>                 --karl--
>
> --
> 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 127k 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: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
--
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



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