Subject: GA-DIGEST V1 #1035
From: [email-masked] (GA-DIGEST)
To: [email-masked]

GA-DIGEST          Sunday, February 10 2002          Volume 01 : Number 1035

----------------------------------------------------------------------

Date: Sat, 09 Feb 2002 12:48:53 +0100
From: Jefsey Morfin <[email-masked]>
Subject: Re: [ga] Future of sub-lists

On 18:25 09/01/02, Patrick Corliss said:
>William X. Walsh killed off the idea with a barrage of criticism.  This was
>part of the reason I resigned as Alt Chair.   The lists were very carefully
>set up to cover the main policy issues.  Danny added [ga-review] in the vain
>hope that he could kick start that initiative.

Untrue. You killed the idea as you kill it today.

The reason while it failed is that they were very carefully set-up. What is 
of interest is to have lists set-up and killed as the people wants them. 
The entire mistake Danny and you made in supporting the WG-Review "jefsey's 
proposition" was to kick our ass into your sub-lists. No one likes it.

The "jefsey's proposition" (cf. WG-Review archives and Joana Lane's site) 
was that if people wants to discuss a topic one of them or a group of them 
initiate a working site and list. The site to document position statements 
and the list to discuss them until we can aggregate them into a consensus. 
So anyone might pop-in/out a debate without loosing the thread and 
competences may  be self acknowledged.

A very different approach from your rigid, non site supported, rules 
enforced, debate reported, ga list separated artificial sub-lists.

I do not say the "jefsey's proposition" would work. But I say you never 
tried it.
Jefsey

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

------------------------------

Date: Sat, 09 Feb 2002 13:21:21 +0100
From: Jefsey Morfin <[email-masked]>
Subject: Re: [ga] FYI: NC Structure Taskforce: At Large Discussion Paper v3

Dear Alexander,
thank you for your copy of the TF review.

This draft seems to be the most short sighted document about ICANN I ever 
read. It does not take into account any aspect of the naming space global 
management, of the IP addressing concerns and of the protocol issues 
related to the Internet Participant system architecture, issues of far 
larger magnitude than the ICP-3 misunderstanding.

It does not even consider the issues related to stability and security 
depending from the ICANN. How can it conceivably discuss the ICANN @large 
structure without addressing the ccTLD/NICs issues, the international 
consumer organization representation, the relations between @large and GAC, 
the industries, content and developers representation, the balance at the 
BoD, the relations with the DoC and the USG, etc. etc. and also NEVER use 
the word which is the ICANN "raison d'être": IANA ....

I do feel that we should support it as much as possible as it will 
certainly lead to the deepest confusion in the ICANN part of the Internet 
governance. It does not actually take into account ANY other concern than 
trying to extend the NC efficiency and working method to the whole ICANN.

As such it will be considered by a) a smart BoD at the same value as the 
other past NC contributions b) by a dumb BoD as a master piece to approve 
as the complement of the ALSC report to lead ICANN to inaction, BoD to 
instability, Staff and VRSN to an anti-trust case and the IU/T to a final 
take-over of the IANA functions at the GAC demand. This will be an 
interesting test.

I can only applaud Joe Sims for his direct and indirect efforts in advising 
the different parties. The NC and ALSC aggregated positions - if adopted - 
will certainly insure JDRP a rewarding monthly bill . I only do regret that 
Joe's lack of understanding of a distributed network culture and structure 
makes him to waste so much his talents at a so huge cost for the world.

Jefsey

At 21:19 09/01/02, Alexander Svensson wrote:

>[3rd draft, 8-Jan-02, by Philip Sheppard, converted from Word doc
>at http://www.dnso.org/clubpublic/nc-str/Arc00/msg00072.html,
>for comment until January 15.  /// Alexander]
>
>=================================================================
>DNSO NC TF on Structure   Discussion paper
>=================================================================
>Draft outline analysis of and recommendations on the
>ALSC final report proposals -- draft version3
>=================================================================
>
>Record of input
>  Constituency  | version 1/2 | version 3   |
>  BC            | Yes         |             |
>  IPC           |             |             |
>  gTLDs         |             |             |
>  ccTLDs        |             |             |
>  Registrars    |             |             |
>  Non- coms     | Yes         |             |
>  ISP           | Yes         |             |
>  GA            | Yes         |             |
>
>
>1. Summary of key proposals within the ALSC November 2001 report
>     -- for information only
>
>-> Define potential electorate as individual domain name holders
>    (and outreach beyond in future)
>-> Establish an At-Large Supporting Organization (ALSC) to
>    organise that electorate
>-> Fund the ALSO via membership dues as a condition of voting
>-> Establish 6 ICANN regions (or give Asia-Pacific two seats)
>-> Elect 6 At-Large Board directors with 3 year term
>-> Elect one 12 member ALSO Council (two per region)
>-> Hold regional elections for 3 international posts and 3
>    regional posts
>-> Post no 1 (most votes) elected as At-Large Board director
>-> Post no 2 and 3 (second and third highest votes) elected to
>    ALSO Council.
>-> No 2 through no 6 regional winners form 5 member Regional
>    Council.
>-> Hold first elections in 2002.
>-> ALSO provides consensus-based policy advice within ICANN's
>    mission.
>-> Use Registrars as conduit to reach the potential electorate.
>-> Review after two election cycles (6 years or 2008).
>
>
>2. Evaluation against established criteria
>
>-----------------------------------------------------------------|
>Criteria                 |Evaluation                             |
>-----------------------------------------------------------------|
>a. the efficacy of policy making within the DNSO                 |
>-----------------------------------------------------------------|
>- degree of formal       |Uncertain. But compared with an        |
>interaction between      |individual domain name holders         |
>stakeholders             |constituency WITHIN the DNSO, the      |
>                          |degree of interaction between At-large |
>                          |and the DNSO is clearly lower.         |
>-----------------------------------------------------------------|
>- quantity of predicted  |Low. There will be high overlap between|
>unique issues of a new SO|issues discussed by an ALSO with those |
>outside the competence of|of the DNSO.                           |
>DNSO versus issues within|                                       |
>competence of DNSO       |                                       |
>-----------------------------------------------------------------|
>- mechanisms for cross-SO|Uncertain. No mechanisms are proposed. |
>communication            |There will be membership overlap and so|
>                          |informal cross communication. There    |
>                          |will probably be a need for formalised |
>                          |mechanisms.                            |
>-----------------------------------------------------------------|
>- effect on the DNSO     |High. The ALSO provides the            |
>consensus process.       |organisation of individuals and is an  |
>                          |enabler of consensus. The DNSO could   |
>                          |use this input as part of its consensus|
>                          |process but a mechanism is needed.     |
>-----------------------------------------------------------------|
>b. the efficacy of ICANN decision making                         |
>-----------------------------------------------------------------|
>- the ability of each    |Uncertain. The ALSO would be expected  |
>proposal to generate     |to enhance consensus within itself but |
>valid consensus-based    |not per se within the ICANN community. |
>policy making            |                                       |
>-----------------------------------------------------------------|
>- possibility of the     |High. Today the policy areas of the    |
>Board receiving          |three SOs are distinct. With an ALSO   |
>contradictory advice from|feeling able to comment on all ICANN   |
>its SOs and the impact on|policy areas they may conflict with    |
>resolution mechanisms    |each of the three existing SOs. What is|
>                          |required is a means of coherence for   |
>                          |policy input to the DNSO to make name- |
>                          |related policy input to the Board      |
>                          |coherent.                              |
>-----------------------------------------------------------------|
>- likely financial and   |Uncertain. The real test of individuals|
>representational         |interest in at-large will be when      |
>robustness of any SO     |members are asked to pay to vote. The  |
>                          |choice of fee and the degree of self-  |
>                          |funding will be a highly significant   |
>                          |determinant of success or failure of   |
>                          |the ALSO.                              |
>-----------------------------------------------------------------|
>- likelihood of the      |--> High. The proposed ALSO structure  |
>proposal to achieve      |    should produce better at-large     |
>adequate, balanced and   |    representation than the status quo |
>fair stakeholder         |    (subject to the financial question |
>representation on the    |    above.) There will be one          |
>Board                    |    additional at-large member than the|
>                          |    status quo. (But three less at-    |
>                          |    large members than envisaged in    |
>                          |    the by-laws).                      |
>                          |--> Setting up a sixth ICANN region    |
>                          |    uniquely for ALSO is not           |
>                          |    recommended. If a sixth region is  |
>                          |    needed then it should relate to all|
>                          |    ICANN activities.                  |
>                          |--> To avoid capture and ensure        |
>                          |    plurality there will need to be a  |
>                          |    minimum threshold for participation|
>                          |    in the ALSO before elections could |
>                          |    start.                             |
>-----------------------------------------------------------------|
>
>
>3. Recommendations of the Structure TF based on evaluation
>
>  1. Board directors. Against an objective to create a means of
>     electing ICANN at-large board directors the TF endorses the
>     ALSC proposals to create an ALSO.
>  2. Policy consensus. Against an objective to outreach and develop
>     policy consensus among individual domain name holders, the TF
>     endorses the structural proposals of the ALSC.
>  3. Policy support to the Board. Against an objective to provide
>     policy input to the Board, the TF recommends that the three
>     members of the proposed At-large administrative council are
>     given membership of the DNSO Names Council, and participate
>     within that body exercising voting and other policy-related
>     privileges in the same way as the three representatives of the
>     DNSO constituencies. (The three ALSO reps would have no vote
>     in the election of DNSO Board members).
>
>     This solves at a stroke three issues:
>     --> the likelihood of contradictory or confusing advise
>         reaching the Board from the DNSO and the ALSO
>     --> creating a clear mechanism for ALSO/DNSO policy
>         interaction.
>     --> avoiding duplication by DNSO constituencies in policy
>         work in both the DNSO and ALSO.
>
>Mechanistic details:
>  1. ALSO is formed and directly elects 6 Board members.
>  2. ALSO also elects 12 member Administrative Council (as ALSC
>     proposal but with an administrative role to organise the SO
>     and outreach downwards on policy)
>  3. ALSO Administrative Council selects 3 members (or the 3 top
>     geographically diverse of the directly-elected council
>     election list) appointed to Names Council to input on policy
>     matters.
>  4. The individuals petitioning for an individual domain name
>     holders constituency within the DNSO are encouraged to
>     participate in the ALSO and become AL Administrative Council
>     members and reps to the NC.
>  5. The GA reverts to its intended role of uniting all DNSO
>     constituencies (and expands to include the AL Administrative
>     Council and NC reps).
>
>
>4. Threshold for ALSO membership before elections could start.
>
>The ALSC report there were 143,789 on the first At-Large e-mail
>list, that 76,183 were validated to vote and that 34,035 voted.
>A threshold of 30,000 seems reasonable for the proposed ALSO
>membership before elections can begin.
>=================================================================
>
>--
>This message was passed to you via the [email-masked] list.
>Send mail to [email-masked] to unsubscribe
>("unsubscribe ga" in the body of the message).
>Archives at http://www.dnso.org/archives.html

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

------------------------------

Date: Sat, 09 Feb 2002 17:39:34 -0800
From: Jeff Williams <[email-masked]>
Subject: [ga] From Nanog - WLS/VGRS already a done deal?

All assembly members,

  Is WLS/VGRS a done deal?  Seem perhaps that Verisign
believes it is...

===============  Copy from Nanog follows ============
Subject: COM/NET/ORG/EDU Registry Informational Message
   Date: Thu, 07 Feb 2002 19:15:48 -0500
   From: Brad Verd <[email-masked]>
     To: [email-masked]

To All,

VeriSign GRS will be making several changes to the COM, NET, ORG and EDU

zone files. Their format will be modified to reduce the overall file
size by removing unnecessary text and extraneous records. Currently the
excess information causes an increase in the time required to generate
and distribute these files. In the interest of making timely updates and

meeting ICANN requirements for file distribution, the following changes
will be made:

1. Modify Zone File Format to Reduce Size

Using certain directives and shortcuts to replace recurring values will
significantly reduce the size of these zone files:

- - Records will contain unqualified, or relative, domain names whenever
possible.  The particular zone file’s origin will be specified with a
$ORIGIN directive and should be appended to unqualified domain names per

RFC 1035, section 5.1.

- - The $TTL directive will be used set the default time to live for
subsequent records in the zone file per RFC 2308, section 4.  Individual

records will no longer contain an explicit TTL.

- - The IN class will be specified in the SOA record but omitted in all
subsequent records, since a record’s class defaults to the previously
specified class.  See RFC 1035, section 5.1 for more information.

These format changes are currently scheduled to be implemented late Q2

2. Eliminate Orphan A Records

The current zone generation process publishes A (address) records (also
called glue records) regardless of whether the name server is referenced

by any NS (name server) records. Put another way, an A record is
published even if no zone delegations reference it. These A records are
called orphans, and their presence in the COM/NET/ORG zones is
undesirable for both administrative and technical reasons

The inclusion of these orphan A records can cause problems for
administrators of lower-level name servers. Even if the lower-level
servers are configured properly, orphan A records in the COM/NET/ORG
zones can interfere with normal resolution of lower-level zones and make

maintenance (especially changes) difficult and confusing. If the
lower-level name servers are configured improperly, the presence of
orphan A records may be the only reason that resolution is currently
working correctly. Therefore, it is important that all administrators of

COM/NET/ORG subzones have the correct information in their zones prior
to the removal of orphan A records from the COM/NET/ORG zones.

Verisign’s proposed resolution for achieving this is as follows:

Step 1 (by late February):  A report will be generated weekly for each
registrar indicating the orphan A records owned by that registrar.
VeriSign GRS will also include instructions describing the steps that
should be taken to ensure that lower-level name servers are properly
configured so that removal of the orphan A records will not cause
failures in resolution.

Step 2 (by late February):  A list of all orphan A records will be
posted to the VeriSign GRS web site and will be updated weekly. This
list will allow registrants to determine if they might be affected by
the elimination of orphan A records from the COM/NET/ORG zones and
provide instruction on resolving these issues

Step 3 (Currently scheduled for late Q2):  Approximately a week before
the modification to the zone generation process to remove orphan A
records is implemented, another email will be sent out as a reminder
with the exact date that the change will occur.

Regards,
Brad
- --------------------------------------
Brad Verd
Resolution Systems Operations Manager
Verisign Global Registry Services
Email - [email-masked]
- ---------------------------------------

==============  End of copy ==============

Regards,
- --
Jeffrey A. Williams
Spokesman for INEGroup - (Over 121k members/stakeholdes strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
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 [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Sat, 9 Feb 2002 15:45:15 -0800
From: William X Walsh <[email-masked]>
Subject: Re: [ga] From Nanog - WLS/VGRS already a done deal?

Saturday, Saturday, February 09, 2002, 5:39:34 PM, Jeff Williams wrote:

> All assembly members,

>   Is WLS/VGRS a done deal?  Seem perhaps that Verisign
> believes it is...

There is nothing in that email which has anything to do with the WLS.

Do you have something pertinent to the subject to contribute?

- -- 
Best regards,
William X Walsh <[email-masked]>
- --

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

------------------------------

Date: Sat, 09 Feb 2002 19:28:52 -0800
From: Jeff Williams <[email-masked]>
Subject: Re: [ga] Compiled WLS Questions

Alex and all Assembly members,

  Thank you for consolidating the two different set of questions
here Alex.  Well done!  Indeed I support that these questions should
be answer directly and unambiguously by whomever at Verisign.

  Perhaps a resolution Ballot for the GA members to officially
vote on these questions be provided for the record?

Alexander Svensson wrote:

> [The list has been sent to VeriSign Global Registry Services]
>
> Compilation of questions from the DNSO General Assembly
> about the proposed Waiting List Service for domain names
> --------------------------------------------------------
>
> Registry load issues
>
> 1. CIRA, the registry for dot-ca, was able to manage 100-times
>     scalability when it released expired names recently for re-registration
>     (see http://www.cira.ca/news-releases/63.html ). Given that this
>     non-profit registry did not require a wait-list system, nor a
>     surcharge, what are the technical flaws in Verisign systems that
>     prevent a similar system as CIRA?
>
> 2. Why has Verisign refused to implement various technical fixes to
>     reduce registry load issues, including "rate-limiting" technology and
>     "extended response codes"?
>
> 3. When does VGRS plan to solve her problems; the increased load on VGRS
>     systems, as mentioned in Montevideo, Uraguay in September 2001.
>
> 4. a) Verisign has highlighted that there are 80-100 million domain
>     "checks" per day. What is the number of checks per day on average,
>     broken down by each of the accredited registrars?
>     b) Which of the above registrars are performing these checks on
>     behalf of SnapNames?
>
> Legal issues
>
> 5. Can Verisign (registry) assure the community that registrars
>     offering this service on a world-wide basis are not going to face
>     legal problems?  In an earlier message (*) sent to the registrars'
>     list, Jim Archer raises some questions on this, arguing that
>     offering WLS subscriptions may be considered commodity trading.  If
>     such problems exist even in some (possibly obscure) jurisdictions,
>     this would introduce an unfair national bias into the system.
>     (*) <http://www.dnso.org/clubpublic/registrars/Arc01/msg01852.html>
>
> 6. If the WLS is deemed to be illegal (due to anti-trust law, and/or
>     relevant Commodity Futures law), will Verisign/ICANN indemnify affected
>     resellers, registrants and other market participants from all
>     liability, legal costs, and implementation costs associated with the
>     1-year test?
>
> 7. On what (contractual) grounds does VGRS propose the WLS, instead of
>     letting this part of the markt be a free operating system?
>     Where does VGRS base the sale of WLS upon, considering that it is her
>     contractual duty to return domains to the pool after 45 days, in which
> case
>     there would be nothing to sell
>
> 8. When does VGRS propose to settle with ICANN on a delete agreement pursuant
>     to 3.7.5 of the Registrar Accreditation Agreement (RAA).
>
> 9. Does this WLS not constitute a seperate contract between ICANN and VGRS
>     and as such, should an open "bid" period to allow other to "bid" for a
>     likewise system not be entertained?
>
> Prices, payment and costs
>
> 10.a) What is Verisign's proposed wholesale price for a variant of WLS
>     with zero (0) exchanges?
>     b) What are Verisign's proposed wholesale prices for a variant of
>     WLS with a two-stage  mechanism, where the WLS holder is charged $X for
>     their place in queue, and then and additional $Y if and only if the
>     domain is deleted, with no exchanges? (i.e. tell us X and Y)
>
> 11.What besides "willingness of the market" is the base for the extremely
>     high price of WLS? When will VGRS deliver a cost-based analyses to all
>     constituencies to determine a "fair" price for such services, if they
>     should be started?
>
> 12.How does the WLS system handle credit-card chargebacks by
>     registrants (and the associated chargeback fees) who fail to acquire a
>     name?
>
> 13.a) How much is Snapnames being paid per reservation? Why?
>     b) What are the relevant patent-pending registration numbers for any
>     intellectual property that is involved in the creation of the WLS, in
>     particular the "Parallel Registry" technology?
>
> Test success criteria
>
> 14.a) What are the success criteria that Verisign/ICANN intend to use
>     at the end of the 1-year WLS testing period (these should be specified
>     ex-ante, not ex-post)?
>     b) Do those criteria take into account the existing competitive
>     landscape that exists in the market?
>     c) If so, what market measurements has Verisign/ICANN made of the
>     current competitive landscape (NameWinner, eNom, AWRegistry,
>     ExpireFish, SnapNames, NicGenie, IARegistry, Signature Domains, and
>     other competitors), to serve as the basis for a comparison?
>     d) Under what metrics will the WLS test be considered a failure?
>
> 15.At: http://www.dnso.org/clubpublic/ga/Arc09/msg00081.html Chuck
>     Gomes wrote "The value to the Internet community therefore seems rather
>     obvious to me. But, if there is none as you suggest, then the service
>     will be a failure.  On the other hand, if there is demand and hence
>     value, it will succeed.  The level of success will depend on how much
>     demand and value there is.  The best way to test it is to let the
>     market prove it one way or other."
>     There currently exists a competitive market in the automotive industry
>     (as there is for the expired domain names industry). If it was replaced
>     by a single monopolistic seller for a 1-year test period, cars would
>     undoubtedly still be bought, as there is a intrinsic demand for cars
>     themselves. How does Verisign/ICANN intend to differentiate the demand
>     for WLS from the demand for the expired names themselves, when there
>     would be no alternative mechanism for securing those expired names for
>     which there is a basic demand already that is being satisfied in the
>     market?
>
> 16.Has Verisign considered implementing a 1-year test on the dot-TV
>     and dot-CC TLDs, instead of on dot-COM and dot-NET? Why wouldn't a test
>     on those two TLDs suffice, if it's merely a "test"? (rationale: a test
>     on dot-TV and dot-CC would not impact the existing competitive deleted
>     domains industry, and would also provide the further advantage of
>     comparison between the two alternative markets on the same time-scale)
>
> Abusive speculation
>
> 17. What is the definition of "abusive speculation"? In particular, do
>     any of the 55 examples from the SnapNames Hot 100 referenced at:
>     http://www.dnso.org/clubpublic/ga/Arc09/msg00085.html
>     constitute "abusive speculation"? (As of this writing,
>     the Hot 100 list on SnapNames' website is apparently no longer
>     available, although the mirror is available)
>
> Grandfathering
>
> 18.a) Will existing holders of SnapNames SnapBacks be grandfathered
>     into the WLS?
>     b) If not, what are the proposed Sunrise and Landrush mechanisms
>     for the WLS?
>
> 19.Since WLS subscriptions purchased in the final month of the "test"
>     will continue be honoured, doesn't this mean that the impact of this
>     "test" on the deleted domains market will be for 2 years and not merely
>     1 year?
>
> Consensus process
>
> 20.a) Under what metrics does Verisign plan to decide that there is a
>     stakeholders "consensus" for bringing forth this proposal to ICANN? In
>     particular, what level and nature of opposition must exist to abandon
>     the proposal?
>     b) Under what conditions do counter-proposals by other stakeholders
>     receive attention as viable alternatives to WLS?
>     c) Why is the "Status Quo" proposal not an option? (it seems to
>     have greater support and consensus at this time than the WLS) If it has
>     greater support than the WLS, why is the "Status Quo" not the best
>     option?
>
> WLS implementation
>
> 21.a) Will the WHOIS information for the WLS subscription holder be
>     made public?
>     b) If not, why not?
>
> 22.a) If a name is deleted "in error", does it go back to the original
>     registrant?
>     b) What are the exact conditions that constitute a deletion "in
>     error"?
>
> 23.Will WLS subscriptions be refused on names that expire after the
>     end of the WLS subscription?
>
> Secondary market
>
> 24.How will WLS enhance competition and innovation in the deleted
>     domain industry, when it will reduce the number of available business
>     models that presently exist in the marketplace?
>
> 25.Which of the existing business models that are active in the
>     deleted domains market (eNom, SnapNames, NameWinner, NicGenie,
>     Signature Domains, IARegistry, AWRegistry, ExpireFish, and others) are
>     inappropriate and/or violations of their respective registrar
>     agreements?
>
> 26.How does VGRS respond to the fact that WLS will put a number of operators
>     in a likewise service based on free market principles out of business?
>
> Bulk deletions
>
> 27.Will the process of BULK deletion remain in place?
>
> 28.Verisign has not had a batch deletion in about 4 weeks. Have batch
>     deletions been suspended pending the resolution of the WLS proposal?
>
> --------------------------------------------------------
> This list has been compiled from questions asked by members of the
> DNSO General Assembly list.
>
> --
> This message was passed to you via the [email-masked] list.
> Send mail to [email-masked] 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 121k members/stakeholdes strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
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 [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Sun, 10 Feb 2002 17:18:23 +0100
From: Jefsey Morfin <[email-masked]>
Subject: [ga] WLS test

As a test, I am subscribing to the WLS to take over the name of Chuck Gomez 
the day he does not pay his taxes.

Since some of his relatives may UDRP me at that time, I must show my good 
faith when naming myself Chuck Gomez.
1. from now on I will from time to time name myself and sign as "Chuck 
Gomez, 2nd".
2. I will systematically then oppose Chuck's positions to make clear I am 
no name squatter. (the more I sign as Chuck Gomez against Chuck Gomez the 
more this is known, the more my future good faith is established and the 
more I will be UDRP proof the day I inherit Chuck's name).
3. I will be very firm against any of you trying to UDRP Chuck to get his 
name with the support of the WIPO before I can get it.

I registered the domain names http://wls-chuck-gomez.com and 
http://chuck-gomez.name where I will explain why I am ready to pay around $ 
100 a year to get Chuck's name to host a porn site - what definitly shows 
that I do not want to use Chuck's image. I note that I do not want to 
impose that porn site to Chuck, so I commit not to show naked girls before 
I can plainly sign his name. However I expect all the Verisign colleagues 
of Chuck to quickly subscribe on my site.  BTW if Chuck wants to benefit 
from the publicity I am giving to our common name, he can buy me back my 
WLS for $ 500 and get his own legacy for very cheap.

If he does that I will get funded enough for the next WLS name I am at : 
"Straton Sclavos". I already registered http://sswls.com to explain my 
Straton Sclavos future.

Chuck Gomez (to be).

PS. If Chuck is investigated by the IRS, it could be it is not my entire 
fault. There are two other Members of the GA next in line after me.

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

------------------------------

End of GA-DIGEST V1 #1035
*************************