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

GA-DIGEST         Wednesday, November 6 2002         Volume 01 : Number 1498

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

Date: Tue, 5 Nov 2002 13:42:22 -0800 (PST)
From: George Kirikos <[email-masked]>
Subject: [ga] Updated: How to steal a domain name.....

Hello,

Kudos to Richard Lau of MyDomain.com, for helping to get this fixed.
The NAACP has updated the admin email of the domains at risk, so that
they can't be hijacked the 'easy' way.

Hopefully this is a lesson ICANN and others can learn from, in
formulating policy regarding transfers policy, accurate WHOIS (scrubbed
to fix data errors, to protect innocent registrants) and transparent
WHOIS (to make it harder to commit cybercrimes, the average person can
identify a crime that might be about to happen).

Sincerely,

George Kirikos
http://www.kirikos.com/

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
- --
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: Wed, 6 Nov 2002 00:26:27 +0100 (CET)
From: Marc Schneiders <[email-masked]>
Subject: [ga] More Root-Servers?

Yesterday suggestions were made here for placing root-servers more
geographically spread around the world. The problem is that 13 is
the maximum.

Below an idea that RIPE (which operates K) is considering. In short:
there would be several machines with the same IP number in different
places using anycast. So there would in fact be more root-servers that
appear to be just one of the 13.

- ---------- Forwarded message ----------
Date: Tue, 05 Nov 2002 13:12:22 +0100
From: Daniel Karrenberg <[email-masked]>
To: RIPE DNS WG <[email-masked]>
Cc: RIPE Routing WG <[email-masked]>
Subject: Distributing K-Root Service by Anycast Routing

Dear Colleagues,

below you find the proposal to start distributing the service
of k.root-servers.net by using anycast. I welcome comments
and suggestions either privately or on the DNS WG list.
I would like to see a good discussion so that we can proceed
with support from the RIPE community. Can we have this
discussion on the DNS WG list too please? In particular
I would like to hear technical suggestions for Appendix A.

Thanks

Daniel

- ---------

     Distributing  K-Root Service by Anycast Routing of
                        193.0.14.129

                     Daniel Karrenberg
                <[email-masked]>

     $Id: k-any.ms,v 1.9 2002/11/05 12:03:32 dfk Exp $

                          ABSTRACT

          This memo proposes to distribute the DNS ser-
     vice  provided by k.root-servers.net across multi-
     ple locations in the Internet topology.   It  dis-
     cusses  the  motivation  for and the principles of
     implementation.  A  first  inventory  of  detailed
     issues is provided in an appendix.

1.  Introduction

DNS  root  name  servers  need  to be accessible by Internet
hosts in order for the DNS to function  properly.   Accessi-
bility  is determined by the ability of the server to handle
a given query load and by the connectivity of the server  to
the rest of the Internet.

The  RIPE  NCC  operates  k.root-servers.net (K-root) in the
RIPE region in order to help safeguard the  quality  of  the
DNS  in  the  Internet and in the RIPE region in particular.
The RIPE NCC obtains guidance from RIPE.

For K-root the connectivity  issue  has  been  addressed  by
placing  it at the LINX, a topologically very well connected
point.  The server load issue has been addressed by  deploy-
ing  successive  generations of hardware with increased pro-
cessing power and by distributing the load locally  among  a
number  of  machines  at different LINX sites.  A cold spare
system has been available in Amsterdam at all times to  pro-
vide continuity in case of catastrophic failures at the pri-
mary server location.  Over the years this set-up  has  pro-
vided very reliable service.

However issues about differences in connectivity to the ser-
vice across the RIPE region have been raised repeatedly.   A
more  distributed provision of the service is generally seen
as positive because of

  -  lower network  delays  due  to  shorter  paths  between
     clients and servers,

  -  less dependence on connectivity to a single location,

  -  better  load and DDoS attack resiliance because of dis-
     tributed servers,

  -  more overall redundancy.

For these reasons numerous  organisations  have  offered  to
host  additional  servers  operated  by the RIPE NCC. So far
this has not been considered because the number of unique IP
addresses  at which the service can be provided is exhausted
by currently assigned servers.

2.  Scope of this Memo

This memo proposes  to  deploy  multiple  servers  providing
k.root-servers.net name service across the RIPE region, each
using the same IP address.  This is  commonly  called  'any-
casting'.   A detailed description of one implementation can
be found in RFC3258.  The  intention  of  this  memo  is  to
establish  the  principles  of  this,  inventarise the major
issues and request comments  from  the  RIPE  community  and
other  interested parties.  An initial inventory of detailed
issues is provided as an appendix.

3.  Proposal

Simply put the RIPE NCC will provide K-root name service  at
multiple  locations dispersed over the Internet topology but
at the same IP address.  No DNS client/resolver changes  are
necessary.  The service will appear exactly the same for the
users.  Normal Internet routing will distribute the  traffic
among the different instances of K-root.

This  will  be  implemented by installing multiple copies of
the current server sets at different points  and  announcing
the current prefix 193.0.14/24 from these points.

The  main  challenge  with  this set-up is to ensure consis-
tency:

operation -
     All servers will be operated in a consistent way by the
     RIPE  NCC.   They  will  have  appropriate  out-of-band
     access path to ensure that the  operations  centre  can
     access them.

monitoring -
     The  availability  and  responses  will be monitored by
     dedicated  monitoring  systems  installed  at  multiple
     locations.   Also  the  BGP  propagation  of the prefix
     193.0.14/24 will be monitored constantly by the  exist-
     ing remote route collectors.  [http://www.ripe.net/ris]
     Users will be able to identify the particular  instance
     they  are using by published methods using DNS queries.
     [draft-ietf-dnsop-serverid]

correctness -
     The correctness and authenticity of the root zone  data
     will  eventually be guaranteed using DNSSEC. Until this
     can be deployed the current  method  will  need  to  be
     employed:  ISPs will need to closely monitor where they
     route traffic to 193.0.14/24 and from where they accept
     traffic  from  that address.  The RIPE NCC will publish
     and maintain a list with the locations  of  the  k-root
     instances,  the  BGP autonomous system numbers of their
     immediate neighbors and any other information that  can
     help  ISPs  and  others  to  ensure  that they reach an
     authentic instance of K-root.  This list will be  main-
     tained until appropriate routing security technology is
     widely deployed.

The RIPE NCC and K-root itself are well suited for this mode
of  operation.   IANA  asked the RIPE NCC to operate K-root,
the geographic and topological location of  K-root  was  not
specified  in  any  way  other  than  "somewhere in the RIPE
region". The RIPE NCC was chosen because it is  neutral  and
professional  but above all directly accountable to RIPE and
its membership.

The location at the LINX was subsequently  chosen  based  on
evaluation of the Internet topology in the region and a rec-
ommendation by the RIPE DNS working group.  Distributing  K-
root  over  a  number of places is a natural continuation of
this policy.

In addition to operating K-root at  a  remote  location  the
RIPE  NCC  has  considerable  experience  in  operating dis-
tributed services.  The Test  Traffic  Measurements  Service
operates more than 80 machines all over the world to collect
performance measurements.  Some of these can be used to mon-
itor  the DNS service of K-root as well.  The Routing Infor-
mation  Service  operates  9  remote  route  collectors   at
exchange  points  all  over the world to collect BGP routing
information.  These route collectors will be used to monitor
the routing of 193.0.14/24.

At  any point in time there is a trade-off between the added
benefit of adding more servers and the difficulty of operat-
ing  them  consistently.   The  optimal  number  of  servers
depends on a large number of  constantly  changing  factors.
It needs to be evaluated continuously as things progress.

4.  Operational & Funding Models

For  the purpose of stability and for gaining experience all
instances of K-root will be operated by the RIPE NCC.   This
ensures  smooth  transitions, consistency and correctness of
root zone data.

After the initial deployment there are a number of  possible
operational and funding models.

4.1.  Traditional

Traditionally  K-root  operations  have been part of general
RIPE NCC activities and thus have been  collectively  funded
by  the RIPE NCC membership.  This is an appropriate funding
model as all members benefit from stable root name  service.
It  is also easy to administer.  Difficulties may arise when
the number of locations is such that the  operational  costs
increase  very significantly.  Another important drawback of
this model is that the number of additional  sites  will  be
limited  by  available  funds  and the sites will have to be
determined  by  a  selection  procedure  based  on  criteria
including

     - position in Internet topology,

     - position relative to existing K-root instances,

     - local operations support,

     - operational requirements [rfc2870],

     - commitment to fund operations at a later stage.

4.2.  Location Fees

The  drawbacks of the traditional model can be largely over-
come by charging the organisations hosting K-root  instances
a  fee  that  covers  the  operational costs. This obviously
scales better and requires less of a beauty contest, because
the  funds available will more closely match the operational
costs.  It is quite possible that the initial demand will be
higher than the operational capabilities of the RIPE NCC.

Also  it  should  be observed that in funding and some other
aspects this is exactly  the  opposite  of  the  traditional
model: In the traditional model the RIPE NCC pays facilities
management fees to the hosts whereas in this model the hosts
pay.

Transition should be planned carefully.

4.3.  Operated and Funded Decentrally

In  this  model anyone who wishes would be able to operate a
K-root instance.  This model has such serious problems  with
guaranteeing  stability  and  consistency  that it cannot be
implemented today  or  in  the  near  future.   The  minimum
requirement  for  this  operational  mode  is a zone signing
mechanism that ensures consistency and authenticity of  root
zone  data.  Implementing this also requires a changed model
of service responsibility as it is obviously  impossible  to
hold any one entity responsible for the service.  While this
may ultimately scale the best, it is extremely premature  at
this point.

We  propose  to  continue with the traditional model for now
and explore other models while gaining  operational  experi-
ence.   The associated selection procedures will be executed
by the RIPE NCC and guided by the relevant requirements RFCs
and the RIPE DNS working group.

5.  Implementation Plan

5.1.  Initial BGP change

The  routing  announcements  of  the  current  server prefix
193.0.14/24 will change from AS5459 (LINX) to the  dedicated
new K-root autonomous system number AS25152.

ISPs  need  to be aware of this and adapt their routing fil-
ters accordingly.  It is recommended that ISPs  who  do  not
already  do  so,  take  precautions,  safeguaring  that they
receive this prefix from an authentic K-root via  a  trusted
path  and that they route traffic to it via trusted paths as
far as possible.  At the same time an initial set of BGP and
DNS service monitors will be deployed.

5.2.  Move the Cold Standby to Service

The  current  cold  standby  server  at the RIPE NCC will be
activated as a regular server.  AS25152  will  be  announced
also  by  the  RIPE  NCC  at  the  AMS-IX.  As the server is
already available and configured this  can  be  done  fairly
rapidly.  The distribution of the load, BGP routing informa-
tion and other operational data will be gathered and  evalu-
ated.   ISPs  will  have the opportunity to test this set-up
and provide feedback.  In case  of  problems  the  RIPE  NCC
instance of K-root will be deactivated quickly, returning to
the previous service level.

5.3.  Implement Further Instances

While monitoring continuously a number of further  instances
of  K-root will be deployed.  Currently we expect this to be
about 5 additional instances.  This  number  is  limited  by
operational and monitoring capacity.  It is important not to
deploy more instances than can safely be operated and  moni-
tored.   Especially the capacity to detect and correct prob-
lems in this distributed set-up needs to be carefully  moni-
tored.

5.4.  Spreading Further

Planning further than this is currently difficult because of
lack of experience with distributed  K-root  operations  and
possible funding models.

Acknowledgements

The author would like to thank Joao Silva Damas for comments
on an earlier draft as well as Andrei Robachevsky  and  Henk
Uijterwaal who provided comments on recent drafts.

Appendix A - Detailed Issues

Using a router or having a server speak BGP?

Withdrawing BGP announcements based on service availability?

Distributed service monitoring: Using current RIPE NCC oper-
ated  machines  all  over the world is an easy option. Maybe
distributing automatic monitoring software to be run by vol-
unteers  is  another. What is essentially needed is to try a
small number of queries  periodically  including  the  query
identifying  the  instance  of the server. Then transmitting
the results back to a (set of) collection point(s).

Distributed BGP Monitoring: The RIS can be  used  for  this.
Coverage should be sufficient.

Information  Campaign: What is needed to reach all ISPs that
need to know? How long a lead time do they need for the var-
ious stages of the deployment?

- --
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: Tue, 05 Nov 2002 18:04:29 -0800
From: Jeff Williams <[email-masked]>
Subject: Re: [ga] More Root-Servers?

Marc, Daniel, and all assembly members, stakeholders or other interested
parties,

  It would seem more logical to fix the protocol to allow for more Root
servers than to use Anycast to piggyback additional Root servers.
Even better would be a SROOTS or MultiRoot structure.  But of course
ICANN is strongly against that...  :(  None the less, Bind 9.0+ has
been modified in our [INEG. INC] version to allow for up to 255
root servers.  We call this fix or improved/inhanced version, BindPlus,
and have been quietly deploying it for some time now..

  I do believe that Anycast or Multicast can and has been tested a number
of times to be used for linking/stacking of Root servers under existing
Bind restrictions.  One might consider asking Paul Vixie about some of
this if I recall correctly.

Marc Schneiders wrote:

> Yesterday suggestions were made here for placing root-servers more
> geographically spread around the world. The problem is that 13 is
> the maximum.
>
> Below an idea that RIPE (which operates K) is considering. In short:
> there would be several machines with the same IP number in different
> places using anycast. So there would in fact be more root-servers that
> appear to be just one of the 13.
>
> ---------- Forwarded message ----------
> Date: Tue, 05 Nov 2002 13:12:22 +0100
> From: Daniel Karrenberg <[email-masked]>
> To: RIPE DNS WG <[email-masked]>
> Cc: RIPE Routing WG <[email-masked]>
> Subject: Distributing K-Root Service by Anycast Routing
>
> Dear Colleagues,
>
> below you find the proposal to start distributing the service
> of k.root-servers.net by using anycast. I welcome comments
> and suggestions either privately or on the DNS WG list.
> I would like to see a good discussion so that we can proceed
> with support from the RIPE community. Can we have this
> discussion on the DNS WG list too please? In particular
> I would like to hear technical suggestions for Appendix A.
>
> Thanks
>
> Daniel
>
> ---------
>
>      Distributing  K-Root Service by Anycast Routing of
>                         193.0.14.129
>
>                      Daniel Karrenberg
>                 <[email-masked]>
>
>      $Id: k-any.ms,v 1.9 2002/11/05 12:03:32 dfk Exp $
>
>                           ABSTRACT
>
>           This memo proposes to distribute the DNS ser-
>      vice  provided by k.root-servers.net across multi-
>      ple locations in the Internet topology.   It  dis-
>      cusses  the  motivation  for and the principles of
>      implementation.  A  first  inventory  of  detailed
>      issues is provided in an appendix.
>
> 1.  Introduction
>
> DNS  root  name  servers  need  to be accessible by Internet
> hosts in order for the DNS to function  properly.   Accessi-
> bility  is determined by the ability of the server to handle
> a given query load and by the connectivity of the server  to
> the rest of the Internet.
>
> The  RIPE  NCC  operates  k.root-servers.net (K-root) in the
> RIPE region in order to help safeguard the  quality  of  the
> DNS  in  the  Internet and in the RIPE region in particular.
> The RIPE NCC obtains guidance from RIPE.
>
> For K-root the connectivity  issue  has  been  addressed  by
> placing  it at the LINX, a topologically very well connected
> point.  The server load issue has been addressed by  deploy-
> ing  successive  generations of hardware with increased pro-
> cessing power and by distributing the load locally  among  a
> number  of  machines  at different LINX sites.  A cold spare
> system has been available in Amsterdam at all times to  pro-
> vide continuity in case of catastrophic failures at the pri-
> mary server location.  Over the years this set-up  has  pro-
> vided very reliable service.
>
> However issues about differences in connectivity to the ser-
> vice across the RIPE region have been raised repeatedly.   A
> more  distributed provision of the service is generally seen
> as positive because of
>
>   -  lower network  delays  due  to  shorter  paths  between
>      clients and servers,
>
>   -  less dependence on connectivity to a single location,
>
>   -  better  load and DDoS attack resiliance because of dis-
>      tributed servers,
>
>   -  more overall redundancy.
>
> For these reasons numerous  organisations  have  offered  to
> host  additional  servers  operated  by the RIPE NCC. So far
> this has not been considered because the number of unique IP
> addresses  at which the service can be provided is exhausted
> by currently assigned servers.
>
> 2.  Scope of this Memo
>
> This memo proposes  to  deploy  multiple  servers  providing
> k.root-servers.net name service across the RIPE region, each
> using the same IP address.  This is  commonly  called  'any-
> casting'.   A detailed description of one implementation can
> be found in RFC3258.  The  intention  of  this  memo  is  to
> establish  the  principles  of  this,  inventarise the major
> issues and request comments  from  the  RIPE  community  and
> other  interested parties.  An initial inventory of detailed
> issues is provided as an appendix.
>
> 3.  Proposal
>
> Simply put the RIPE NCC will provide K-root name service  at
> multiple  locations dispersed over the Internet topology but
> at the same IP address.  No DNS client/resolver changes  are
> necessary.  The service will appear exactly the same for the
> users.  Normal Internet routing will distribute the  traffic
> among the different instances of K-root.
>
> This  will  be  implemented by installing multiple copies of
> the current server sets at different points  and  announcing
> the current prefix 193.0.14/24 from these points.
>
> The  main  challenge  with  this set-up is to ensure consis-
> tency:
>
> operation -
>      All servers will be operated in a consistent way by the
>      RIPE  NCC.   They  will  have  appropriate  out-of-band
>      access path to ensure that the  operations  centre  can
>      access them.
>
> monitoring -
>      The  availability  and  responses  will be monitored by
>      dedicated  monitoring  systems  installed  at  multiple
>      locations.   Also  the  BGP  propagation  of the prefix
>      193.0.14/24 will be monitored constantly by the  exist-
>      ing remote route collectors.  [http://www.ripe.net/ris]
>      Users will be able to identify the particular  instance
>      they  are using by published methods using DNS queries.
>      [draft-ietf-dnsop-serverid]
>
> correctness -
>      The correctness and authenticity of the root zone  data
>      will  eventually be guaranteed using DNSSEC. Until this
>      can be deployed the current  method  will  need  to  be
>      employed:  ISPs will need to closely monitor where they
>      route traffic to 193.0.14/24 and from where they accept
>      traffic  from  that address.  The RIPE NCC will publish
>      and maintain a list with the locations  of  the  k-root
>      instances,  the  BGP autonomous system numbers of their
>      immediate neighbors and any other information that  can
>      help  ISPs  and  others  to  ensure  that they reach an
>      authentic instance of K-root.  This list will be  main-
>      tained until appropriate routing security technology is
>      widely deployed.
>
> The RIPE NCC and K-root itself are well suited for this mode
> of  operation.   IANA  asked the RIPE NCC to operate K-root,
> the geographic and topological location of  K-root  was  not
> specified  in  any  way  other  than  "somewhere in the RIPE
> region". The RIPE NCC was chosen because it is  neutral  and
> professional  but above all directly accountable to RIPE and
> its membership.
>
> The location at the LINX was subsequently  chosen  based  on
> evaluation of the Internet topology in the region and a rec-
> ommendation by the RIPE DNS working group.  Distributing  K-
> root  over  a  number of places is a natural continuation of
> this policy.
>
> In addition to operating K-root at  a  remote  location  the
> RIPE  NCC  has  considerable  experience  in  operating dis-
> tributed services.  The Test  Traffic  Measurements  Service
> operates more than 80 machines all over the world to collect
> performance measurements.  Some of these can be used to mon-
> itor  the DNS service of K-root as well.  The Routing Infor-
> mation  Service  operates  9  remote  route  collectors   at
> exchange  points  all  over the world to collect BGP routing
> information.  These route collectors will be used to monitor
> the routing of 193.0.14/24.
>
> At  any point in time there is a trade-off between the added
> benefit of adding more servers and the difficulty of operat-
> ing  them  consistently.   The  optimal  number  of  servers
> depends on a large number of  constantly  changing  factors.
> It needs to be evaluated continuously as things progress.
>
> 4.  Operational & Funding Models
>
> For  the purpose of stability and for gaining experience all
> instances of K-root will be operated by the RIPE NCC.   This
> ensures  smooth  transitions, consistency and correctness of
> root zone data.
>
> After the initial deployment there are a number of  possible
> operational and funding models.
>
> 4.1.  Traditional
>
> Traditionally  K-root  operations  have been part of general
> RIPE NCC activities and thus have been  collectively  funded
> by  the RIPE NCC membership.  This is an appropriate funding
> model as all members benefit from stable root name  service.
> It  is also easy to administer.  Difficulties may arise when
> the number of locations is such that the  operational  costs
> increase  very significantly.  Another important drawback of
> this model is that the number of additional  sites  will  be
> limited  by  available  funds  and the sites will have to be
> determined  by  a  selection  procedure  based  on  criteria
> including
>
>      - position in Internet topology,
>
>      - position relative to existing K-root instances,
>
>      - local operations support,
>
>      - operational requirements [rfc2870],
>
>      - commitment to fund operations at a later stage.
>
> 4.2.  Location Fees
>
> The  drawbacks of the traditional model can be largely over-
> come by charging the organisations hosting K-root  instances
> a  fee  that  covers  the  operational costs. This obviously
> scales better and requires less of a beauty contest, because
> the  funds available will more closely match the operational
> costs.  It is quite possible that the initial demand will be
> higher than the operational capabilities of the RIPE NCC.
>
> Also  it  should  be observed that in funding and some other
> aspects this is exactly  the  opposite  of  the  traditional
> model: In the traditional model the RIPE NCC pays facilities
> management fees to the hosts whereas in this model the hosts
> pay.
>
> Transition should be planned carefully.
>
> 4.3.  Operated and Funded Decentrally
>
> In  this  model anyone who wishes would be able to operate a
> K-root instance.  This model has such serious problems  with
> guaranteeing  stability  and  consistency  that it cannot be
> implemented today  or  in  the  near  future.   The  minimum
> requirement  for  this  operational  mode  is a zone signing
> mechanism that ensures consistency and authenticity of  root
> zone  data.  Implementing this also requires a changed model
> of service responsibility as it is obviously  impossible  to
> hold any one entity responsible for the service.  While this
> may ultimately scale the best, it is extremely premature  at
> this point.
>
> We  propose  to  continue with the traditional model for now
> and explore other models while gaining  operational  experi-
> ence.   The associated selection procedures will be executed
> by the RIPE NCC and guided by the relevant requirements RFCs
> and the RIPE DNS working group.
>
> 5.  Implementation Plan
>
> 5.1.  Initial BGP change
>
> The  routing  announcements  of  the  current  server prefix
> 193.0.14/24 will change from AS5459 (LINX) to the  dedicated
> new K-root autonomous system number AS25152.
>
> ISPs  need  to be aware of this and adapt their routing fil-
> ters accordingly.  It is recommended that ISPs  who  do  not
> already  do  so,  take  precautions,  safeguaring  that they
> receive this prefix from an authentic K-root via  a  trusted
> path  and that they route traffic to it via trusted paths as
> far as possible.  At the same time an initial set of BGP and
> DNS service monitors will be deployed.
>
> 5.2.  Move the Cold Standby to Service
>
> The  current  cold  standby  server  at the RIPE NCC will be
> activated as a regular server.  AS25152  will  be  announced
> also  by  the  RIPE  NCC  at  the  AMS-IX.  As the server is
> already available and configured this  can  be  done  fairly
> rapidly.  The distribution of the load, BGP routing informa-
> tion and other operational data will be gathered and  evalu-
> ated.   ISPs  will  have the opportunity to test this set-up
> and provide feedback.  In case  of  problems  the  RIPE  NCC
> instance of K-root will be deactivated quickly, returning to
> the previous service level.
>
> 5.3.  Implement Further Instances
>
> While monitoring continuously a number of further  instances
> of  K-root will be deployed.  Currently we expect this to be
> about 5 additional instances.  This  number  is  limited  by
> operational and monitoring capacity.  It is important not to
> deploy more instances than can safely be operated and  moni-
> tored.   Especially the capacity to detect and correct prob-
> lems in this distributed set-up needs to be carefully  moni-
> tored.
>
> 5.4.  Spreading Further
>
> Planning further than this is currently difficult because of
> lack of experience with distributed  K-root  operations  and
> possible funding models.
>
> Acknowledgements
>
> The author would like to thank Joao Silva Damas for comments
> on an earlier draft as well as Andrei Robachevsky  and  Henk
> Uijterwaal who provided comments on recent drafts.
>
> Appendix A - Detailed Issues
>
> Using a router or having a server speak BGP?
>
> Withdrawing BGP announcements based on service availability?
>
> Distributed service monitoring: Using current RIPE NCC oper-
> ated  machines  all  over the world is an easy option. Maybe
> distributing automatic monitoring software to be run by vol-
> unteers  is  another. What is essentially needed is to try a
> small number of queries  periodically  including  the  query
> identifying  the  instance  of the server. Then transmitting
> the results back to a (set of) collection point(s).
>
> Distributed BGP Monitoring: The RIS can be  used  for  this.
> Coverage should be sufficient.
>
> Information  Campaign: What is needed to reach all ISPs that
> need to know? How long a lead time do they need for the var-
> ious stages of the deployment?
>
> --
> 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 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
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 [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: Tue, 05 Nov 2002 21:12:59 -0800
From: Jeff Williams <[email-masked]>
Subject: [ga] Re: Does that mean you will not be the new ICANN CEO ?

Jim and all assembly members or other interested parties,

  I got a real laugh of of this part the Oct 31 Preliminary report:
"Whereas, the ICANN CEO, Stuart Lynn, has advised the Board of his
desires to retire from service to ICANN in the first quarter of 2003;"

  Retire?  Yeah right!  ROFLMAO!

  More accurate statement here would be:
"Whereas the stakeholders/users are completely tired of Stuart Lynn's
inept and poor "Stuart-ship" as CEO of ICANN and a replacement
is badly needed post haste;"

  Now that the niceties have adequately been dispensed of, and
Stuart. like his errant predecessor Mike Roberts is tankfully
leaving, although without enough haste, a more appropriate
and thoughtful CEO can be brought on board.  However I,
and I am sure most of us here in the DNSO GA are quite
sure that such is unlikely, I would like to suggest that
Jim Fleming, Joe Baptista, Karl Auerbach, or Andy Mueller-Maguhn
 be given serious consideration for the CEO position.

  Naturally in that Mike Roberts is tentatively on the search
committee, the fix will again be in and a already predetermined
candidate will be ascended to the ICANN CEO postiion and of course
an appropriately timed announcement or leak as to whom that is to be
shall be provided for...  As usual and has been the history thus far of
ICANN, the "Club" mentality and practice shall likely continue...

Jim Fleming wrote:

> http://www.fitug.de/atlarge-panel/0211/msg00076.html
> On 17:14 05/11/03, James Love said:
>
>   Or, coming from me, does it get automatically dismissed as "not constructive," the phrase that you and Esther like so much?
>
> sons of Mike Roberts. It was considered as a priviledge to receive such a comment from Mike Roberts. Meant your proposition was
> adequate, well construed and dangerous for ICANN.
>
> =====
>
> Does that mean you will not be the new ICANN CEO ?
>
> http://www.icann.org/minutes/prelim-report-31oct02.htm
> It is therefore resolved [02.120] that Helmut Schink and Michael Roberts are appointed as additional members of the Committee;
>
> Further resolved [02.121] that expenditures not to exceed US$ 250,000 are authorized for total costs of search and transition costs
> for the next CEO of ICANN;
>
> ==================================
>
> Jim Fleming
> 128-bit DNS is closer than you think...
> COM...DE...NET...ORG...INFO...BIZ...US...ONLINE
> http://ipv8.dyndns.tv
> http://ipv8.dyns.cx
> http://ipv8.no-ip.com
> http://ipv8.no-ip.biz
> http://ipv8.no-ip.info
> http://ipv8.myip.us
> http://ipv8.dyn.ee
> http://ipv8.community.net.au

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 [email-masked]
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 [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: Wed, 6 Nov 2002 05:03:53 +0100
From: Patrick Mevzek <[email-masked]>
Subject: Re: [ga] who are the root server operators?

On Tue, Nov 05, 2002 at 10:53:03AM +0100, Stephane Bortzmeyer took time to write:
> * with DNSSEC (cryptographical signatures in the DNS replies) and IDN
>   (long labels), the DNS will have to move to TCP anyway,

Not true, necessarily. EDNS exists and permits larger UDP segments.

> * there is never a DNS query for the root name servers: they are
>   hardwired in the hints file (/etc/bind/db.root or something like

Not true at all.
The first things bind does is query root servers (one I believe) to
obtain the current list with current IP.
This is why the thing is called a ``hint'' zone.
Otherwise it would just be a master zone in bind's configuration.

>   that). Unlike the TLD name servers (which ICANN limit to 13 per
>   TLD), there is no good technical reason to limit the number of root
>   name servers.

This is starting to be caricatural.

Patrick Mevzek.
- --
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: Wed, 6 Nov 2002 05:07:46 +0100
From: Patrick Mevzek <[email-masked]>
Subject: Re: [ga] who are the root server operators?

On Tue, Nov 05, 2002 at 10:27:21AM +0100, Stephane Bortzmeyer took time to write:
> > Are there any plans to expand the list of root-servers, maybe to 26
> > from 13, for greater internet stability?
> 
> Technically, it would be a very good thing. Politically, I do not
> believe that ICANN/USA would accept to relinquish its control. The
> rest of the world is not trustworthy.

Control of what ? Adding a nameserver in the current root set, does
not change anything in that way, and does not give any less control at all.
The only thing (control) that means is the one of the A root-server.
The others are just copies ;-)

> I'm not aware of such criteria at ICANN. Do they have public criteria?
> Do they document the process of decision?

I believe that the current 13 nameservers existed far before ICANN.
So can you please stop putting all mysery in the world on ICANN's
shoulders ? This is really caricatural...

Patrick Mevzek.
- --
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: Tue, 5 Nov 2002 23:24:42 -0500
From: "Cade,Marilyn S - LGA" <[email-masked]>
Subject: [ga] ensuring that your voice and input is heard on open comment sites

Dear Mike, Jeff and others

This  is a reminder: the WHOIS TF public comment period closes 11/8. 
We welcome your postings to the site.  You can post at www.icann.org, click on Announcements, or on www.dnso.org -- you'll see the site to click on for WHOIS comments.

We can make one comment: the TF members have noted that they will turn to the public comment site for the "authoritative" input. If you are unable to post to that site, please let Marilyn or Tony know, or better yet, communicate with your reps on the TF. They will help you.

That way, we can ensure that your inputs and comments are reviewed by the full TF.

Marilyn Cade			Antonio Harris
- -----Original Message-----
From: Antonio Harris [mailto:[email-masked]]
Sent: Tuesday, November 05, 2002 1:26 PM
To: Jeff Williams; Michael D. Palage
Cc: Cade,Marilyn S - LGA; [email-masked]; Don Evans; Nancy J. Victory;
cathy Handley; Robin Layton
Subject: Re: [ga] Michael Palage's Proposed Whois Task Force
Recommendations

Jeff,

If the term "noise" bothers you, the solution is simple:

Send your comments to:
http://www.dnso.org/dnso/notes/20021015.NCWhoisTF-interim-report.html

Attacking people who do volunteer work (a lot of it, by the way),
would not appear to serve any useful purpose. If you have better
ideas, then submit them ! What more would we want as a task
force than to receive them ? As far as what, as co-chair, I "want to
hear or read about" thats simply hilarious ! Just try this for an
exercise: read the 3300 responses to the Whois survey and
see what you can come up with...

Tony Harris

- ----- Original Message -----
From: "Jeff Williams" <[email-masked]>
To: "Michael D. Palage" <[email-masked]>
Cc: "Cade,Marilyn S - LGA" <[email-masked]>; <[email-masked]>; "Antonio Harris
(E-mail)" <[email-masked]>; "Don Evans" <[email-masked]>; "Nancy J.
Victory" <[email-masked]>; "cathy Handley" <[email-masked]>;
"Robin Layton" <[email-masked]>
Sent: Tuesday, November 05, 2002 4:10 PM
Subject: Re: [ga] Michael Palage's Proposed Whois Task Force Recommendations

> Michael and all assembly members,
>
>   Michael, you again bring up yet another good point of concern
> that has and continues to plague and discredit the "ICANN Process".
>
>   As you likely know, I amongst a number other GA participants
> have long worried and been frankly quite aware that the "TF method"
> of determining policy is a poor one for a number of reasons of which
> you again have brought up one.
>
>   As you also likely also know anything I as spokesman for INEGroup
> have put forward to the Whois, and Transfer Task Force has by
> Marilyn been, as she herself has stated only considered "Noise"
> in her opinion, which is questionable at best.  Hence any public input
> through these skewed Task Force Methods or processes is
> only what the members or chair's of those task forces WANT to
> hear or read about, nothing else.  Hence no good or reasonable
> policy can be derived adequately.
>
>   So unless as you indicate in your comments and observations below,
> Michael, a transparent and open discussion and debate for specific
> issues such as Whois can be entertained or "Allowed" we as
> stakeholders/users will continue to see inadequate or inappropriate
> policy for these issues to continue.  For the life of me, I cannot
> understand such utter nonsensical approaches of dealing with
> issues to policy.
>
>   I guess this is why just last friday AT&T announced a 5 for 1 Reverse
> stock split, Worldcom is in deeper trouble than first even imagined,
> and ICANN seeks to choose its BoD members now by and election
> committee.
>
> Michael D. Palage wrote:
>
> > Dear Marilyn:
> >
> > After three years I think we have moved beyond the formality of
addressing
> > each other on a last name basis :-)
> >
> > As you can see from my email header below, I did submit these comments
on
> > the "record" to the Whois Task Force on Friday, November 1st. The fact
that
> > they were not received raises the question of what other submissions may
> > have also been lost in the mail.
> >
> > Best regards,
> >
> > Mike
> >
> > -----Original Message-----
> > From: Michael D. Palage [mailto:[email-masked]]
> > Sent: Friday, November 01, 2002 4:18 PM
> > To: [email-masked]
> > Subject: Michael Palage's Proposed Recommendations
> >
> > Attached please find my proposed recommendations for the Whois Task
Force
> > based upon my earlier comments to the Task Force,
> > http://www.dnso.org/dnso/dnsocomments/comments-whois/Arc01/msg00012.html
> >
> > Best regards,
> >
> > Michael D. Palage
> >
> > -----Original Message-----
> > From: Cade,Marilyn S - LGA [mailto:[email-masked]]
> > Sent: Tuesday, November 05, 2002 12:08 AM
> > To: Michael D. Palage; [email-masked]
> > Cc: Antonio Harris (E-mail)
> > Subject: RE: [ga] Michael Palage's Proposed Whois Task Force
> > Recommendations
> >
> > Dear Mr. Palage,
> >
> > May we have your permission to post this particular email to the WHOIS
TF?
> >
> > Also, as you are aware there is an open comment site. We urge you, IF
you
> > are interested in having your comments included in the TF documentation,
to
> > post to that site. It can be found at dnso.org, or icann.org, click on
> > announcements.  While we post to the WHOIS TR site, WHEN requested, we
make
> > it pretty clear that individuals should take responsibility for their
own
> > postings, to open sites.  We urge you to follow the procedures to ensure
> > that your comments are included and available to others.  The TF is
> > committed to reading the open comments site.  We have and will continue
to
> > advise that we cannot guarantee reading of other lists. We know that you
> > understand the need to ensure a centralized posting site.
> >
> > We also wish to thank you for attending the public meeting with the
> > Registrars/Registries, Sunday in Shanghai. As committed in that meeting,
the
> > TF is working toward follow up with the registrars, especially, shortly.
> >
> > We hope that you will join that call, as well.
> >
> > Your thoughtful insights should be part of the "record". We hope you
will
> > chose to submit your comments [below]  through the formal comment
process.
> > And, we look forward to your further participation.
> > Best Regards, Marilyn Cade                      Antonio Harris=
> > -----Original Message-----
> > From: Michael D. Palage [mailto:[email-masked]]
> > Sent: Friday, November 01, 2002 4:25 PM
> > To: [email-masked]
> > Subject: [ga] Michael Palage's Proposed Whois Task Force Recommendations
> >
> > On October 23rd I submitted my personal comments to the Whois Task
Force,
> > see
> >
http://www.dnso.org/dnso/dnsocomments/comments-whois/Arc01/msg00012.html.
> > Listed below are my personal recommendations for the Whois Task Force
based
> > upon my earlier comments.
> >
> > Any comments or suggestions would be greatly appreciated.
> >
> > Best regards,
> >
> > Michael D. Palage
> >
> > Recommendations Preamble
> >
> > The current Whois system fails to adequately meet the needs and concerns
of
> > governments, intellectual property owners, domain name registration
> > authorities, as well as consumer and privacy advocacy groups. Although
one
> > can attempt to solve certain aspects of the current problems in a
piecemeal
> > fashion, only a comprehensive bottoms-up review and overhaul is likely
to
> > succeed.
> >
> > ICANN's role in this and other potential global policy issues should be
to
> > identify and bring to the table those individuals and parties
potentially
> > impacted by its processes, particularly those in developing countries
that
> > may not have their voices and concerns heard in the current structure,
as
> > well as registration authorities that are signatories to bi-lateral
> > contracts with ICANN. ICANN's role is not, nor should it be, to
artificially
> > manufacture consensus under the auspices of Task Forces.
> >
> > The ICANN Names Council Whois Task Force (Task Force) should be
commended
> > for its pioneering efforts in starting a constructive dialogue on some
of
> > the complex issues surrounding Whois.  However, the Task Force's failure
to
> > address certain fundamental issues directly bears upon the validity of
the
> > Task Force's ultimate recommendations. In light of these shortcomings,
the
> > following recommendations are submitted.
> >
> > Recommendation 1
> >
> > Whereas, the Task Force has endeavored over the last twenty (20) months
to
> > undertake an analysis of various Whois issues;
> >
> > Whereas, the Task Force has published an interim report dated October
14,
> > 2002 in which four (4) interim recommendations were put forth for public
> > comment;
> >
> > Whereas, despite the best efforts undertaken by the Task Force volunteer
> > members, there are certain fundamental aspects that were not properly
> > addressed and which directly bear upon the validity of the Task Force's
> > recommendations, including but not limited to, applicability of natural
and
> > local law and their impact on registration authorities that are
signatories
> > to bi-lateral contracts with ICANN; new market conditions (.NAME);
evolving
> > technical standards (CRISP); international domain name considerations;
and
> > ICANN's Evolution and Reform  Committee calling for more input from the
> > public sector (governments).
> >
> > Therefore, it is resolved that the Names Council:
> >
> > Extend it heartfelt appreciation to the members of the Task Force for
their
> > diligent and tireless efforts to date;
> >
> > Immediately dissolve the Task Force;
> >
> > Reject implementing the proposed recommendation at this time until
further
> > review can be conducted incorporating those data points not properly
> > considered by the Task Force;
> >
> > Respectfully submit to the ICANN Board that it create a Blue Ribbon
Global
> > Whois Panel (Panel) to ensure that the viewpoints and concerns of all
> > Internet stakeholders are addressed, with such Panel ideally being
composed
> > of the following representatives:
> >
> > GAC Representative: This representative shall provide the Panel with the
> > various viewpoints (consensus if possible) regarding governmental
positions
> > regarding access and accuracy of Whois data (i.e. data privacy, law
> > enforcement, consumer protection, etc.)
> >
> > ITU Representative: Although the ITU is currently a participating member
in
> > the GAC, their experience in two areas would be of particular value to
the
> > Panel: (i) in the area of soliciting and representing the viewpoints of
> > emerging countries and economies that may not have a representative
voice in
> > the current process and (ii) in the area of promoting the role of ITU
Member
> > States in the internationalization of domain names and addresses of
their
> > respective languages.
> >
> > ICANN Registry Representative: This representative would be tasked with
> > soliciting input from all ICANN accredited registry operators to provide
the
> > Panel with firsthand operational considerations.
> >
> > ICANN Registrar Representative: This representative would be tasked with
> > soliciting input from all ICANN accredited registrars to provide the
Panel
> > with a better understanding of the legal and technical dynamics of the
> > domain name registration marketplace.
> >
> > ccTLD Registry Operator/Administrator: This representative would be
tasked
> > with soliciting input from the ccTLD registry operator/administrator
> > regarding Whois policies and national laws.
> >
> > Civil Libertarian: This representative would be tasked with representing
the
> > interests of individual domain name registrants, specifically with
regard to
> > a wide range of privacy issues.
> >
> > IETF/IAB Technical Representative: This representative would be able to
> > provide the Panel with insight regarding standards efforts currently
> > underway in connection with Whois (CRISP) and international domain
names.
> >
> > Multi-National Business Representative: This individual would be tasked
with
> > soliciting input from large multi-national businesses regarding concerns
> > about diverse and divergent Whois practices and the importance of Whois
in
> > law enforcement and intellectual property rights.
> >
> > SME Business Representative: This representative would be required to
> > solicit and provide the viewpoint of small and medium enterprises
regarding
> > Whois considerations.
> >
> > Respectfully submit to the ICANN Board that ICANN extend invitations to
> > potential Panel participants to prevent any partisan politics that may
exist
> > within the various ICANN constituencies. In the alternative, ICANN
should
> > also consider outsourcing the coordination of this Panel to a neutral
third
> > party organization with expertise in this subject matter similar to the
work
> > undertaken by the World Intellectual Property Organization in connection
> > with the initial draft of the Uniform Dispute Resolution Policy (UDRP).
One
> > potential neutral third party with expertise in this area would be the
> > Organization for Economic Co-operation and Development (OECD).
> >
> > Recommendation 2
> >
> > Whereas, the Task Force has endeavored over the last twenty (20) months
to
> > undertake an analysis of various Whois issues;
> >
> > Whereas, the Task Force has published an interim report dated October
14,
> > 2002 in which four (4) interim recommendation were put forth for public
> > comment;
> >
> > Whereas, despite the best efforts undertaken by the Task Force volunteer
> > members, there are certain fundamental aspects that were not properly
> > addressed and which directly bear upon the validity of the Task Force's
> > recommendations, including but not limited to, applicability of natural
and
> > local law and their impact on registration authorities that are
signatories
> > to bi-lateral contracts with ICANN; new market conditions (.NAME);
evolving
> > technical standards (CRISP); international domain name considerations;
and
> > ICANN Evolution and Reform  Committee calling for more input from the
public
> > sector.
> > Whereas, notwithstanding the aforementioned shortcoming of the Task
Force's
> > efforts, there were several concepts would could be implemented in the
short
> > term that would increase the accuracy of the Whois data.
> >
> > Therefore, it is resolved that the Names Council respectfully request
that
> > the ICANN Board take the following actions:
> >
> > ICANN approve a standardize Whois Accuracy Inquiry Notice (WAIN)
prepared by
> > ICANN accredited registrars in consultation with domain name
representatives
> > regarding inquires about false or inaccurate Whois data;
> >
> > ICANN assist in translating the WAIN into as many languages as possible;
> >
> > ICANN require that registrars shall send the standardized WAIN to their
> > domain name registrant after receiving a notification of potentially
false
> > or inaccurate Whois data from ICANN's Internic.net whois portal (or
> > equivalent);
> >
> > ICANN accredited registrars shall be required to send any WAIN in the
> > language(s) of the registration agreement, along with links to
translations
> > of the WAIN in other languages;
> >
> > The current 15 day time frame for registrants to respond to inquiries
> > regarding the accuracy of the Whois data shall be extended to 30 days to
> > provide the registrant and registrar adequate time to investigate and
> > respond to inquiries;
> >
> > Registrars shall be required to comply with ICANN instructions regarding
the
> > docketing software maintained in connection with the Internic.net whois
> > portal (or equivalent);
> >
> > Registrars that are unable to verify the accuracy of the Whois data or
fail
> > to receive instructions from the registrant within thirty (30) days
shall
> > place the domain name of hold (i.e. the name is removed from the zone
file
> > and it will not resolve) indefinitely;
> >
> > Registrar shall not remove the domain name from hold status or renew the
> > domain name until registrant has provided documented proof which the
> > registrar shall be required to retain;
> >
> > In the situation where the registrar receives a secondary inquiry
regarding
> > the accuracy of Whois data for a specific domain name, the Registrar
shall
> > require documented proof from the domain name registrant within the 30
day
> > time frame or have the domain name places on indefinite hold in
accordance
> > with the process described above;
> >
> > ICANN shall immediately modify the Internic.net Whois portal to require
> > third parties submitting Whois accuracy inquiries to acknowledge that
the
> > submission is not intended to interfere with the lawful operations of
the
> > domain name registrant or registrar;
> >
> > ICANN shall immediately modify the Internic.net Whois portal to require
that
> > third parties provide additional contact information to allow the domain
> > name registrant or registrar to initiate legal action against the third
> > party if such submission was designed to tortuously interfere with their
> > legal activity.
> >
> > ICANN's General Counsel and Staff are instructed to move forward with
> > implementation of the above referenced recommendations as follows:
> >
> > Option 1:
> >
> > A bi-lateral amendment to the ICANN Registrar Accreditation Agreement
(RAA)
> > executed by ICANN and every accredited registrar. However, if one or
more
> > registrars fail to execute this bi-lateral amendment proceed to Option 2
> > below.
> >
> > Option 2:
> >
> > Establish a dialog with the registrar community to see if consensus
exists
> > among the accredited registrars about adopting the above referenced
> > recommendations within the context of a Code of Conduct. If there is
> > consensus among the registrars about adopting this proposal as a Code of
> > Conduct, this Code of Conduct would then be unilaterally enforced
against
> > all ICANN accredited registrars in accordance with the terms of the RAA.
If
> > the registrars refuse or are unable to adopt a Code of Conduct, then
proceed
> > to Option 3 below.
> >
> > Option 3:
> >
> > If ICANN is unable to implement the above referenced recommendations
under
> > either Option 1 or 2, ICANN General Counsel and Staff are instructed to
> > enter into individual bi-lateral amendments to the RAA with registrars
> > incorporating these procedures.
> >
> > For those registrars that execute the bi-lateral amendment to the RAA,
ICANN
> > will provide that domain name registrar and its registrants with an
extend
> > time window (30 days total) to investigate and respond to Whois data
> > accuracy inquires. ICANN also agrees to not publicly disclose any
> > statistical information on that registrar's compliance with Internic,net
> > Whois portal inquiries.
> >
> > For those registrars that refuse not to enter into a bi-lateral
amendment to
> > the RAA, ICANN will continue to enforce the shorter 15 notice and
deletion
> > policy instead of the more flexible 30 day notice and hold policy.
> > Additionally, ICANN will publicly disclose statistical information on
that
> > registrars' compliance with Internic.net Whois portal inquiries.
> >
> > --
> > 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
>
> 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 [email-masked]
> 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 [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 #1498
*************************