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

GA-DIGEST          Thursday, August 29 2002          Volume 01 : Number 1400

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

Date: Thu, 29 Aug 2002 00:39:48 -0700
From: Jeff Williams <[email-masked]>
Subject: [ga] Re: [atlarge-discuss] my comments to the WHOIS Task Force reports

Vittorio and all assembly members,

Vittorio Bertola wrote:

> Comments on the "Possible Recommendations" of the DNSO WHOIS Task
> Force Report
>
> Vittorio Bertola
> August 28, 2002
>
> This document exposes my comments to the "Possible Recommendations"
> section of the Report of the WHOIS Task Force of DNSO's Names Council.
> These comments are personal and do not reflect the view of any of the
> entities I am involved with (i.e. ISOC Italy, icannatlarge.com, or the
> At Large Organizing Committee). However, they have matured after
> careful reading of the discussions on the DNSO GA list and on other
> ICANN-related lists, mainly populated by users and individual domain
> name owners. So, while I do not claim that the following statements
> represent the opinions of these constituencies, I know that they are
> shared by a number of their members.
>
> A.      Accuracy of data contained in the WHOIS database
>
> The need of having accurate data listed in the WHOIS service is
> agreeable.

  Indeed accurate data in the Whois record for a Domain Name
is essential.  However "Accurate" should not be equated to
having personal and private information or the registrant as the
Draft Report suggests.

>
>
> First of all, I note that the only entity able to guarantee the
> freshness of the data is the registrant - so if accuracy has to be
> granted, the registrant must be deeply involved in the process.

  It is not necessary for the registrant to be deeply involved at all.
Rather the Admin for that Domain Name's whois or registration
listing is much more than adequate.

>
> However, if the registrant is to be required to keep its contact data
> updated - especially if failure to do so might mean getting penalties
> of any kind - then the registrar is to be clearly required to offer
> registrants a simple mechanism (ie Web and/or e-mail based) to check
> and update his contact data, as a provision in the RAA.

  Again no, it is not necessary or even advisable for every Registrant
to maintain themselves their Domain Name Whois data.  That is what
and Admin for a Domain Name is for.  This however does not preclude
some Registrants from doing os if they so choose.  (Opt-in option).

> Especially in
> ccTLDs, there are cases where, as a result of privacy protection
> measures, the registrant himself is unable even just to check the
> information currently listed for his domain.  However, to protect the
> registrant's privacy, such mechanism should be made available to the
> registrant only, via an authentication scheme established at the time
> of the domain registration.
>
> Also, I suggest that it is more likely that registrants keep their
> data updated if they are asked to give them in one and only one place.
> So, at least in the mid term, it should be established a system not to
> duplicate contact data across the various TLDs, for example in one of
> the following ways:
> ·       Creation of a centralized "Identity Registry" (for individuals
> and organizations) to which all WHOIS databases point with a standard
> identity handle, and which all registries use to store and retrieve
> the contact data;

  Again not necessary and a bit verbose as well.  The Admin contact
E-Mail address and Phone Number provides for this already in Whois.

>
> ·       Introduction of standard cross-TLD identity handles in all
> WHOIS databases, so that, when registering a domain, the registrant
> can point to his contact data as already provided to the
> registrar/registry of another TLD.

  Also not necessary, verbose, and easily subject to abuse's of various
types as has been vetted on the DNSO GA Forum to that Registrants
personal and private information.

>
> This of course requires complete standardization of the data set
> required to identify individuals and organizations in the DNS system.

  And that standard is already in place with the current Whois...

>
>
> Finally, I note that having an accurate WHOIS database under the
> registry's control does not imply that such database has to be made
> fully and easily available to whoever desires to read it. The Task
> Force Report should stress that this point deserves better
> consideration in all future agreements and policy-making processes. I
> will deal with more detail with privacy issues when commenting section
> C - but I have to note that the current, total lack of privacy about
> the registrants' personal information is a strong incentive for people
> and companies to purposedly provide invalid or incorrect contact data.
> Given the scale of the DNS and the difficulty in checking the
> veridicity of personal information for entities scattered around the
> whole world, I think that even the introduction of penalties of any
> kind will not particularly help to get better accuracy in WHOIS
> information if a certain degree of guaranteed privacy is not
> introduced. (And by the way, in many countries it is extremely dubious
> that a WHOIS system that does not offer such privacy guarantees abides
> by the privacy protection laws.)
>
> B.      Uniformity of data formats
>
> As already stated, I think that uniformity of data formats is a
> necessary precondition to get better accuracy in WHOIS data.

  Agreed.  We have this for gTLD Whois now.

>
>
> Especially for individuals and companies that own domains across a
> number of different TLDs, it is practically impossible to cope with
> the huge number of different data sets, input systems and local
> conventions that are currently used. So the agreement by all gTLD and
> ccTLD registries upon an uniform set of data to identify DNS entities
> is absolutely necessary. ICANN should try to foster such agreement,
> work with all gTLD and ccTLDs to reach it, and later force its
> adoption (with reasonable phase-in times) in its contracts with gTLD
> and ccTLD registries.

  Agreed here.

>
>
> C.      Better searchability of WHOIS databases
>
> Personally, I absolutely cannot see any need for better searchability
> of WHOIS databases, and especially for queries that might return more
> than one domain name at a time. In fact, I only see the need for
> reducing the access to WHOIS databases, to enforce a higher degree of
> privacy protection, and to avoid the current widespread use of WHOIS
> information for unsolicited e-mail and other unwanted marketing uses.
> Such higher degree of protection is clearly requested by the Internet
> community, as shown by the responses to the Task Force survey.

  No not requested, demanded...

>
>
> Registrants should be able to choose whether their personal data are
> to be publicly accessed through WHOIS queries, or not; they should
> have the option of accepting public distribution of their data, within
> a separate opt-in part of the registration agreement, when registering
> the domain

  Agreed.  And this is Key.

> . The implementation of this option should be required to
> registrars and registries; in fact, the absence of this option is very
> likely to make the whole WHOIS system illegal, at least under the laws
> of the European Union. The only exception to this should be the
> availability of a technical contact point e-mail (and, optionally,
> telephone and fax numbers), which should be made available via WHOIS
> queries on a per-domain basis; this can be justified (also in front of
> the law) as a necessary instrument for providing the DNS service.
> Also, the availability and functionality of the postmaster@domain
> e-mail address should be required in all domain registration
> agreements.
>
> In any case where access to other WHOIS data (for example, the
> identity of the registrant) is necessary for law enforcement purposes,
> there already are laws that give law enforcement agencies the
> necessary instruments to access such information even if it is not
> accessible via WHOIS queries. In fact, to speed this up, registries
> could be required to establish separate, private accesses, to be
> reserved to officers of the appropriate law enforcement bodies, that
> can offer full access and searchability to their databases.
>
> D.      Marketing use of WHOIS data
>
> Generally speaking (and as required by many national privacy laws),
> registrants have to be provided with options to opt in or out from any
> kind of usage, distribution and processing of their data that is not
> strictly necessary to supply the DNS service; these options must be
> clearly stated, separated from the core of the domain registration
> agreement, and it must be absolutely clear to customers that they can
> register the domain name even if they do not accept to provide their
> personal information for these additional uses.
>
> This means that, for example, all registrars should be required to
> structure their registration forms, either Web- or paper-based, with
> separate options for opting in to any kind of bulk access - even if
> not aimed at marketing purposes - or marketing usage of their data.
> Registrars and registries must not be able to refuse registrations due
> to the user's wish not to opt in to these additional uses.
> --
> vb.               [Vittorio Bertola - v.bertola [a] bertola.eu.org]<------
> ----------------------> http://bertola.eu.org/ <--------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email-masked]
> For additional commands, e-mail: [email-masked]

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: Thu, 29 Aug 2002 00:45:22 -0500
From: "Jim Fleming" <[email-masked]>
Subject: [ga] 2002 3:219 .INFO...."root servers for .biz"....??...do you mean .BIZ TLD servers ?

- ----- Original Message ----- 
From: "Allan Liska" <[email-masked]>
> JF> "root servers for .biz"....??...do you mean .BIZ TLD servers ?
> 
> JF> Are you familiar with the DNS and how it works ?
> 
> Yes I am.  Every TLD has a series of root nameservers.  These root
> nameservers maintain the database of domains within that TLD.  In
> addition, there are the root nameservers used by recursive nameservers
> to find information about various TLDs.
> 
> The root nameservers for the .BIZ TLD supported by ICANN are:
> 
> A.GTLD.biz.             315874  IN      A       209.173.53.162
> B.GTLD.biz.             466355  IN      A       209.173.57.162
> C.GTLD.biz.             460739  IN      A       209.173.60.65
> D.GTLD.biz.             471986  IN      A       213.86.51.129
> E.GTLD.biz.             476147  IN      A       209.173.58.65
> F.GTLD.biz.             464256  IN      A       209.173.58.66
> 

This appears to be one of the TLD Clusters set up on the "toy" 32-bit, IPv4, legacy Internet
as part of the Proof-of-Concept market trial development for the .BIZ TLD. Using the term
"root" can be confusing for people. Root servers may point at this TLD Cluster or they may
point at another TLD Cluster that provides a redundant "Mirror Registry" operation. That is
what .ORG will have shortly. .ORG will operate independent TLD Clusters in parallel. Many
of the TLDs do this for better reliability and to avoid having a single-point-of-corporate-failure.
http://vuesoft.net/zonexchange/rsc/AIRS.txt
"107 TLDs have multiple entries"

.INFO is a good example. There is a Mirror Registry for the .INFO TLD[1]. In the end, with all of
the TLDs, the goal is to develop a large base of [SLD].TLD owners. Each of them have 2 or more
SLD nameservers which they should register in both of the Mirror Registries. Since it is all part of
the Proof-of-Concept phase of the expansion of the name space, people can use the IPv4 *sandbox*
to experiment before moving to the 128-bit DNS and full commercial deployment. As an aside, one
can see in the above .BIZ TLD Cluster several clues about why it is a Proof-of-Concept deployment.
For one reason, using the same 209.173 subnet for multiple servers does not impress reliability experts.
Another reason is that using the TLD itself, to name all the TLD servers makes for a chicken and egg
reliability problem. It is better to have diversity in naming so that other TLD Clusters can help to make
sure that the .BIZ TLD Cluster can be found. The above arrangement ties those servers too tightly to
what are called "root servers" and which are no longer necessary in modern DNS deployments. People
can find the TLD Clusters and point directly at them. Other TLD Clusters can tell people where all the
other TLD Clusters are located. Once found, any member of a TLD Cluster can report all the members
of the TLD Cluster. With the Mirrored Registry arrangement, each TLD Cluster operates as a unit, and
should one TLD Cluster fail, the other can handle the queries. The 128-bit DNS TLD Cluster front-ends
the 32-bit legacy back-end servers to add even more reliability and features. Having various TLD Clusters
allows for the companies running them to more easily change without service being interrupted. As an
example, there have been various companies operating the .INFO TLD Clusters as can be seen below.
The [SLD].INFO owners have to make sure they are Registered in both of the Mirrored Registries.

[1] 2002 3:219 .INFO
http://www.Name-Space.com
http://www.thepricedomain.com/index.php?domainlist=info

IN-ADDR.INFO is registered in both of the .INFO Registries
http://www.analogx.com/cgi-bin/cgidig.exe?DNS=204.74.113.1&Query=in-addr.info&Type=255&submit=Lookup
http://www.analogx.com/cgi-bin/cgidig.exe?DNS=209.48.2.11&Query=in-addr.info&Type=255&submit=Lookup

========================================

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
2002 3:219 .INFO

http://root-dns.org/vuedig/vuedig_tld.php?record=NS&tld=info
.info - NS Resource Records.

ANIC : AlterNIC : 160.79.129.192
Result = No Response

BORN : Business Oriented Root Network : 213.70.103.18
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 2D IN NS TLD2.ULTRADNS.NET.
info. 2D IN NS TLD1.ULTRADNS.NET.

CINICS : Common Interest Network Information Center Society : 216.15.192.130
Result = No Response

iDNS : i-DNS.net International : 208.184.174.7
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 2D IN NS TLD1.ULTRADNS.NET.
info. 2D IN NS TLD2.ULTRADNS.NET.

LRS : Legacy Root Servers : 198.41.0.4
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 2D IN NS TLD1.ULTRADNS.NET.
info. 2D IN NS TLD2.ULTRADNS.NET.

NSpace : Name.Space : 209.48.2.11
VueDig Results : Answer = 10 : Authority = 0 : Additional = 10. 
info. 1D IN NS ROOT8.AUTONO.NET.
info. 1D IN NS NS1.AUTONO.NET.
info. 1D IN NS NS11.AUTONO.NET.
info. 1D IN NS ROOT3.AUTONO.NET.
info. 1D IN NS C.TLD-SERVERS.NET.
info. 1D IN NS NS.AUTONO.NET.
info. 1D IN NS NS10.AUTONO.NET.
info. 1D IN NS MEDIAFILTER.ORG.
info. 1D IN NS NS12.AUTONO.NET.
info. 1D IN NS NS00.ROOT-ZONE.NET.

Nnet : New.net Inc : 206.132.100.42
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 1D IN NS TLD1.ULTRADNS.NET.
info. 1D IN NS TLD2.ULTRADNS.NET.

ONIC : The OpenNIC Project : 131.161.247.226
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. 
info. 2D IN NS tld2.ultradns.net.
info. 2D IN NS tld1.ultradns.net.

ORSC : Open Root Server Confederation : 199.166.24.1
VueDig Results : Answer = 10 : Authority = 0 : Additional = 10. 
info. 2D IN NS ROOT8.AUTONO.NET.
info. 2D IN NS C.TLD-SERVERS.NET.
info. 2D IN NS NS10.AUTONO.NET.
info. 2D IN NS B.TLD-SERVERS.NET.
info. 2D IN NS NS12.AUTONO.NET.
info. 2D IN NS NS.AUTONO.NET.
info. 2D IN NS NS1.AUTONO.NET.
info. 2D IN NS MEDIAFILTER.ORG.
info. 2D IN NS ROOT3.AUTONO.NET.
info. 2D IN NS NS00.ROOT-ZONE.NET.

ORSN : Open Root Server Network : 217.146.140.67
VueDig Results : Answer = 0 : Authority = 2 : Additional = 2. 
info. 2D IN NS TLD1.ULTRADNS.NET.
info. 2D IN NS TLD2.ULTRADNS.NET.

TINC : The Internet Namespace Cooperative : 64.6.65.10
Result = No Response

TPR : The PacificRoot : 204.107.129.2
VueDig Results : Answer = 3 : Authority = 0 : Additional = 3. 
info. 2D IN NS us.universalroot.com.
info. 2D IN NS uk.universalroot.com.
info. 2D IN NS hk.universalroot.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, 28 Aug 2002 23:47:11 -0700 (PDT)
From: Eric Dierker <[email-masked]>
Subject: Re: [ga] Re: [atlarge-discuss] my comments to the WHOIS Task Force reports

How can anyone buy into any of this load of crap?

The Whois in its' entirety stinks.

This is IP supterfuge and dead wrong!

Vittorio is wrong in engaging in this dialogue, it hurts privacy rights and 
is nothing but a ploy to deny privacy rights.

Sincerely,
Eric

- --
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: Thu, 29 Aug 2002 13:12:57 +0200
From: [email-masked]
Subject: Re: [ga] 2002 3:219 .INFO...."root servers for .biz"....??...do you mean .BIZ TLD servers ?

Jim,
your concept is only possible in the .pro name space.
There are different registrants e.g. for business.info from Afilias and
business.info from Name-Space. Same thing with .biz, .museum and .name.
Only in the .pro name space one could make sure that that e.g. smith.law.pro
is registered to the same person/company in BOTH REGISTRIES!

RegistryPro.com (REGISTRY 2)indroduces following SLD.TLD-strings:
law.pro
med.pro
cpa.pro

I have registered (reserved) these SLD.TLD-strings with REGISTRY 1 (Name
Space)
https://secure.name-space.com/cgi-bin/whois.pl?whois=LAW.PRO
https://secure.name-space.com/cgi-bin/whois.pl?whois=MED.PRO
https://secure.name-space.com/cgi-bin/whois.pl?whois=CPA.PRO

https://secure.name-space.com/cgi-bin/whois.pl?whois=NIC.PRO
more information about my SLD.TLD-string registry on http://nic.pro.xs2.net
(with "ICANN-DNS")

For NetScan Result Summary (VueDig Results) scroll down to the bottom of
this e-mail

Simon Steinle
Diplom-Betriebswirt (BA)
electronic commerce

- ----- Original Message -----
From: "Jim Fleming" <[email-masked]>
To: "Ga" <[email-masked]>
Sent: Wednesday, August 28, 2002 10:45 PM
Subject: [ga] 2002 3:219 .INFO...."root servers for .biz"....??...do you
mean .BIZ TLD servers ?

> ----- Original Message -----
> From: "Allan Liska" <[email-masked]>
> > JF> "root servers for .biz"....??...do you mean .BIZ TLD servers ?
> >
> > JF> Are you familiar with the DNS and how it works ?
> >
> > Yes I am.  Every TLD has a series of root nameservers.  These root
> > nameservers maintain the database of domains within that TLD.  In
> > addition, there are the root nameservers used by recursive nameservers
> > to find information about various TLDs.
> >
> > The root nameservers for the .BIZ TLD supported by ICANN are:
> >
> > A.GTLD.biz.             315874  IN      A       209.173.53.162
> > B.GTLD.biz.             466355  IN      A       209.173.57.162
> > C.GTLD.biz.             460739  IN      A       209.173.60.65
> > D.GTLD.biz.             471986  IN      A       213.86.51.129
> > E.GTLD.biz.             476147  IN      A       209.173.58.65
> > F.GTLD.biz.             464256  IN      A       209.173.58.66
> >
>
> This appears to be one of the TLD Clusters set up on the "toy" 32-bit,
IPv4, legacy Internet
> as part of the Proof-of-Concept market trial development for the .BIZ TLD.
Using the term
> "root" can be confusing for people. Root servers may point at this TLD
Cluster or they may
> point at another TLD Cluster that provides a redundant "Mirror Registry"
operation. That is
> what .ORG will have shortly. .ORG will operate independent TLD Clusters in
parallel. Many
> of the TLDs do this for better reliability and to avoid having a
single-point-of-corporate-failure.
> http://vuesoft.net/zonexchange/rsc/AIRS.txt
> "107 TLDs have multiple entries"
>
> .INFO is a good example. There is a Mirror Registry for the .INFO TLD[1].
In the end, with all of
> the TLDs, the goal is to develop a large base of [SLD].TLD owners. Each of
them have 2 or more
> SLD nameservers which they should register in both of the Mirror
Registries. Since it is all part of
> the Proof-of-Concept phase of the expansion of the name space, people can
use the IPv4 *sandbox*
> to experiment before moving to the 128-bit DNS and full commercial
deployment. As an aside, one
> can see in the above .BIZ TLD Cluster several clues about why it is a
Proof-of-Concept deployment.
> For one reason, using the same 209.173 subnet for multiple servers does
not impress reliability experts.
> Another reason is that using the TLD itself, to name all the TLD servers
makes for a chicken and egg
> reliability problem. It is better to have diversity in naming so that
other TLD Clusters can help to make
> sure that the .BIZ TLD Cluster can be found. The above arrangement ties
those servers too tightly to
> what are called "root servers" and which are no longer necessary in modern
DNS deployments. People
> can find the TLD Clusters and point directly at them. Other TLD Clusters
can tell people where all the
> other TLD Clusters are located. Once found, any member of a TLD Cluster
can report all the members
> of the TLD Cluster. With the Mirrored Registry arrangement, each TLD
Cluster operates as a unit, and
> should one TLD Cluster fail, the other can handle the queries. The 128-bit
DNS TLD Cluster front-ends
> the 32-bit legacy back-end servers to add even more reliability and
features. Having various TLD Clusters
> allows for the companies running them to more easily change without
service being interrupted. As an
> example, there have been various companies operating the .INFO TLD
Clusters as can be seen below.
> The [SLD].INFO owners have to make sure they are Registered in both of the
Mirrored Registries.
>
> [1] 2002 3:219 .INFO
> http://www.Name-Space.com
> http://www.thepricedomain.com/index.php?domainlist=info
>
> IN-ADDR.INFO is registered in both of the .INFO Registries
>
http://www.analogx.com/cgi-bin/cgidig.exe?DNS=204.74.113.1&Query=in-addr.inf
o&Type=255&submit=Lookup
>
http://www.analogx.com/cgi-bin/cgidig.exe?DNS=209.48.2.11&Query=in-addr.info
&Type=255&submit=Lookup
>
> ========================================

.pro - NS Resource Records.
Click on any NS RR link below to do a ServerScan.

ANIC : AlterNIC : 160.79.129.192
VueDig Results : Answer = 2 : Authority = 0 : Additional = 0.
pro. 2h36m47s IN NS b.iana-servers.net.
pro. 2h36m47s IN NS a.iana-servers.net.

BORN : Business Oriented Root Network : 213.70.103.18
VueDig Results : Answer = 0 : Authority = 1 : Additional = 0.
.pro not found.

iDNS : i-DNS.net International : 208.184.174.7
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2.
pro. 2D IN NS A.IANA-SERVERS.NET.
pro. 2D IN NS B.IANA-SERVERS.NET.

LRS : Legacy Root Servers : 198.41.0.4
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2.
pro. 2D IN NS B.IANA-SERVERS.NET.
pro. 2D IN NS A.IANA-SERVERS.NET.

NSpace : Name.Space : 209.48.2.11
VueDig Results : Answer = 10 : Authority = 0 : Additional = 10.
pro. 1D IN NS MEDIAFILTER.ORG.
pro. 1D IN NS NS12.AUTONO.NET.
pro. 1D IN NS NS00.ROOT-ZONE.NET.
pro. 1D IN NS ROOT8.AUTONO.NET.
pro. 1D IN NS NS1.AUTONO.NET.
pro. 1D IN NS NS11.AUTONO.NET.
pro. 1D IN NS ROOT3.AUTONO.NET.
pro. 1D IN NS NS7.AUTONO.NET.
pro. 1D IN NS NS.AUTONO.NET.
pro. 1D IN NS NS10.AUTONO.NET.

Nnet : New.net Inc : 206.132.100.42
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2.
pro. 1D IN NS A.IANA-SERVERS.NET.
pro. 1D IN NS B.IANA-SERVERS.NET.

ORSC : Open Root Server Confederation : 199.166.24.1
VueDig Results : Answer = 10 : Authority = 0 : Additional = 10.
pro. 2D IN NS MEDIAFILTER.ORG.
pro. 2D IN NS ROOT3.AUTONO.NET.
pro. 2D IN NS NS00.ROOT-ZONE.NET.
pro. 2D IN NS ROOT8.AUTONO.NET.
pro. 2D IN NS C.TLD-SERVERS.NET.
pro. 2D IN NS NS10.AUTONO.NET.
pro. 2D IN NS B.TLD-SERVERS.NET.
pro. 2D IN NS NS12.AUTONO.NET.
pro. 2D IN NS NS.AUTONO.NET.
pro. 2D IN NS NS1.AUTONO.NET.

ORSN : Open Root Server Network : 217.146.140.67
VueDig Results : Answer = 0 : Authority = 2 : Additional = 2.
pro. 2D IN NS B.IANA-SERVERS.NET.
pro. 2D IN NS A.IANA-SERVERS.NET.

TPR : The PacificRoot : 204.107.129.2
VueDig Results : Answer = 9 : Authority = 0 : Additional = 9.
pro. 2D IN NS root3.autono.net.
pro. 2D IN NS ns00.root-zone.net.
pro. 2D IN NS mila.ljudmila.org.
pro. 2D IN NS ns.re-lab.lv.
pro. 2D IN NS ns7.autono.net.
pro. 2D IN NS root8.autono.net.
pro. 2D IN NS ns.autono.net.
pro. 2D IN NS ns1.autono.net.
pro. 2D IN NS mediafilter.org.

- --
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: Thu, 29 Aug 2002 07:37:54 -0500
From: "Jim Fleming" <[email-masked]>
Subject: Re: [ga] 2002 3:219 .INFO...."root servers for .biz"....??...do you mean .BIZ TLD servers ?

Simon,

When discusssions about the expansion of the TLD name space were started in earnest
in 1995, people recognized the need to have a place for people to test. Some people are
concerned that a TLD will start and fail. The "toy" 32-bit IPv4 Internet is a perfect place to
test new TLDs, before they mature and are supported by 128-bit DNS services. All the
128-bit DNS providers will care about is the list of [SLD].[TLD] owners who make it
past the Proof-of-Concept test phase. How many are there in .BIZ ? (80,000?). How
about .INFO ? (50,000?). Have you seen many .BIZ or .INFO names in use yet ? Do
the economics warrant investments in .BIZ or .INFO when .COM and other TLDs
have to be completed ?

What are your favorite TLDs  besides .PRO ?
3:146     PRO
Who owns IN-ADDR.PRO ?

2002 0:201 .COM
http://www.thepricedomain.com/index.php?domainlist=com
2002 1:158 .CLUB 
2002 2:143 .FAMILY
http://www.New.Net
2002 3:219 .INFO
http://www.Name-Space.com
http://www.thepricedomain.com/index.php?domainlist=info
2002 4:58 .LLC
2002 5:194 .INC
http://www.New.Net
2002 6:171 .TV
http://www.TV
2002 7:186     GOD
http://www.dot-god.com
http://www.dot.god

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
0:203     ONLINE

- ----- Original Message ----- 
From: <[email-masked]>
To: "Jim Fleming" <[email-masked]>; "Ga" <[email-masked]>
Sent: Thursday, August 29, 2002 6:12 AM
Subject: Re: [ga] 2002 3:219 .INFO...."root servers for .biz"....??...do you mean .BIZ TLD servers ?

> Jim,
> your concept is only possible in the .pro name space.
> There are different registrants e.g. for business.info from Afilias and
> business.info from Name-Space. Same thing with .biz, .museum and .name.
> Only in the .pro name space one could make sure that that e.g. smith.law.pro
> is registered to the same person/company in BOTH REGISTRIES!
> 
> RegistryPro.com (REGISTRY 2)indroduces following SLD.TLD-strings:
> law.pro
> med.pro
> cpa.pro
> 
> I have registered (reserved) these SLD.TLD-strings with REGISTRY 1 (Name
> Space)
> https://secure.name-space.com/cgi-bin/whois.pl?whois=LAW.PRO
> https://secure.name-space.com/cgi-bin/whois.pl?whois=MED.PRO
> https://secure.name-space.com/cgi-bin/whois.pl?whois=CPA.PRO
> 
> https://secure.name-space.com/cgi-bin/whois.pl?whois=NIC.PRO
> more information about my SLD.TLD-string registry on http://nic.pro.xs2.net
> (with "ICANN-DNS")
> 
> For NetScan Result Summary (VueDig Results) scroll down to the bottom of
> this e-mail
> 
> 
> Simon Steinle
> Diplom-Betriebswirt (BA)
> electronic commerce
> 
> 
> ----- Original Message -----
> From: "Jim Fleming" <[email-masked]>
> To: "Ga" <[email-masked]>
> Sent: Wednesday, August 28, 2002 10:45 PM
> Subject: [ga] 2002 3:219 .INFO...."root servers for .biz"....??...do you
> mean .BIZ TLD servers ?
> 
> 
> > ----- Original Message -----
> > From: "Allan Liska" <[email-masked]>
> > > JF> "root servers for .biz"....??...do you mean .BIZ TLD servers ?
> > >
> > > JF> Are you familiar with the DNS and how it works ?
> > >
> > > Yes I am.  Every TLD has a series of root nameservers.  These root
> > > nameservers maintain the database of domains within that TLD.  In
> > > addition, there are the root nameservers used by recursive nameservers
> > > to find information about various TLDs.
> > >
> > > The root nameservers for the .BIZ TLD supported by ICANN are:
> > >
> > > A.GTLD.biz.             315874  IN      A       209.173.53.162
> > > B.GTLD.biz.             466355  IN      A       209.173.57.162
> > > C.GTLD.biz.             460739  IN      A       209.173.60.65
> > > D.GTLD.biz.             471986  IN      A       213.86.51.129
> > > E.GTLD.biz.             476147  IN      A       209.173.58.65
> > > F.GTLD.biz.             464256  IN      A       209.173.58.66
> > >
> >
> > This appears to be one of the TLD Clusters set up on the "toy" 32-bit,
> IPv4, legacy Internet
> > as part of the Proof-of-Concept market trial development for the .BIZ TLD.
> Using the term
> > "root" can be confusing for people. Root servers may point at this TLD
> Cluster or they may
> > point at another TLD Cluster that provides a redundant "Mirror Registry"
> operation. That is
> > what .ORG will have shortly. .ORG will operate independent TLD Clusters in
> parallel. Many
> > of the TLDs do this for better reliability and to avoid having a
> single-point-of-corporate-failure.
> > http://vuesoft.net/zonexchange/rsc/AIRS.txt
> > "107 TLDs have multiple entries"
> >
> > .INFO is a good example. There is a Mirror Registry for the .INFO TLD[1].
> In the end, with all of
> > the TLDs, the goal is to develop a large base of [SLD].TLD owners. Each of
> them have 2 or more
> > SLD nameservers which they should register in both of the Mirror
> Registries. Since it is all part of
> > the Proof-of-Concept phase of the expansion of the name space, people can
> use the IPv4 *sandbox*
> > to experiment before moving to the 128-bit DNS and full commercial
> deployment. As an aside, one
> > can see in the above .BIZ TLD Cluster several clues about why it is a
> Proof-of-Concept deployment.
> > For one reason, using the same 209.173 subnet for multiple servers does
> not impress reliability experts.
> > Another reason is that using the TLD itself, to name all the TLD servers
> makes for a chicken and egg
> > reliability problem. It is better to have diversity in naming so that
> other TLD Clusters can help to make
> > sure that the .BIZ TLD Cluster can be found. The above arrangement ties
> those servers too tightly to
> > what are called "root servers" and which are no longer necessary in modern
> DNS deployments. People
> > can find the TLD Clusters and point directly at them. Other TLD Clusters
> can tell people where all the
> > other TLD Clusters are located. Once found, any member of a TLD Cluster
> can report all the members
> > of the TLD Cluster. With the Mirrored Registry arrangement, each TLD
> Cluster operates as a unit, and
> > should one TLD Cluster fail, the other can handle the queries. The 128-bit
> DNS TLD Cluster front-ends
> > the 32-bit legacy back-end servers to add even more reliability and
> features. Having various TLD Clusters
> > allows for the companies running them to more easily change without
> service being interrupted. As an
> > example, there have been various companies operating the .INFO TLD
> Clusters as can be seen below.
> > The [SLD].INFO owners have to make sure they are Registered in both of the
> Mirrored Registries.
> >
> > [1] 2002 3:219 .INFO
> > http://www.Name-Space.com
> > http://www.thepricedomain.com/index.php?domainlist=info
> >
> > IN-ADDR.INFO is registered in both of the .INFO Registries
> >
> http://www.analogx.com/cgi-bin/cgidig.exe?DNS=204.74.113.1&Query=in-addr.inf
> o&Type=255&submit=Lookup
> >
> http://www.analogx.com/cgi-bin/cgidig.exe?DNS=209.48.2.11&Query=in-addr.info
> &Type=255&submit=Lookup
> >
> > ========================================
> 
> 
> 
> .pro - NS Resource Records.
> Click on any NS RR link below to do a ServerScan.
> 
> ANIC : AlterNIC : 160.79.129.192
> VueDig Results : Answer = 2 : Authority = 0 : Additional = 0.
> pro. 2h36m47s IN NS b.iana-servers.net.
> pro. 2h36m47s IN NS a.iana-servers.net.
> 
> BORN : Business Oriented Root Network : 213.70.103.18
> VueDig Results : Answer = 0 : Authority = 1 : Additional = 0.
> .pro not found.
> 
> iDNS : i-DNS.net International : 208.184.174.7
> VueDig Results : Answer = 2 : Authority = 0 : Additional = 2.
> pro. 2D IN NS A.IANA-SERVERS.NET.
> pro. 2D IN NS B.IANA-SERVERS.NET.
> 
> LRS : Legacy Root Servers : 198.41.0.4
> VueDig Results : Answer = 2 : Authority = 0 : Additional = 2.
> pro. 2D IN NS B.IANA-SERVERS.NET.
> pro. 2D IN NS A.IANA-SERVERS.NET.
> 
> NSpace : Name.Space : 209.48.2.11
> VueDig Results : Answer = 10 : Authority = 0 : Additional = 10.
> pro. 1D IN NS MEDIAFILTER.ORG.
> pro. 1D IN NS NS12.AUTONO.NET.
> pro. 1D IN NS NS00.ROOT-ZONE.NET.
> pro. 1D IN NS ROOT8.AUTONO.NET.
> pro. 1D IN NS NS1.AUTONO.NET.
> pro. 1D IN NS NS11.AUTONO.NET.
> pro. 1D IN NS ROOT3.AUTONO.NET.
> pro. 1D IN NS NS7.AUTONO.NET.
> pro. 1D IN NS NS.AUTONO.NET.
> pro. 1D IN NS NS10.AUTONO.NET.
> 
> Nnet : New.net Inc : 206.132.100.42
> VueDig Results : Answer = 2 : Authority = 0 : Additional = 2.
> pro. 1D IN NS A.IANA-SERVERS.NET.
> pro. 1D IN NS B.IANA-SERVERS.NET.
> 
> ORSC : Open Root Server Confederation : 199.166.24.1
> VueDig Results : Answer = 10 : Authority = 0 : Additional = 10.
> pro. 2D IN NS MEDIAFILTER.ORG.
> pro. 2D IN NS ROOT3.AUTONO.NET.
> pro. 2D IN NS NS00.ROOT-ZONE.NET.
> pro. 2D IN NS ROOT8.AUTONO.NET.
> pro. 2D IN NS C.TLD-SERVERS.NET.
> pro. 2D IN NS NS10.AUTONO.NET.
> pro. 2D IN NS B.TLD-SERVERS.NET.
> pro. 2D IN NS NS12.AUTONO.NET.
> pro. 2D IN NS NS.AUTONO.NET.
> pro. 2D IN NS NS1.AUTONO.NET.
> 
> ORSN : Open Root Server Network : 217.146.140.67
> VueDig Results : Answer = 0 : Authority = 2 : Additional = 2.
> pro. 2D IN NS B.IANA-SERVERS.NET.
> pro. 2D IN NS A.IANA-SERVERS.NET.
> 
> TPR : The PacificRoot : 204.107.129.2
> VueDig Results : Answer = 9 : Authority = 0 : Additional = 9.
> pro. 2D IN NS root3.autono.net.
> pro. 2D IN NS ns00.root-zone.net.
> pro. 2D IN NS mila.ljudmila.org.
> pro. 2D IN NS ns.re-lab.lv.
> pro. 2D IN NS ns7.autono.net.
> pro. 2D IN NS root8.autono.net.
> pro. 2D IN NS ns.autono.net.
> pro. 2D IN NS ns1.autono.net.
> pro. 2D IN NS mediafilter.org.
> 
> 
> 

- --
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: Thu, 29 Aug 2002 07:47:56 -0500
From: "Jim Fleming" <[email-masked]>
Subject: Re: [ga] Re: [atlarge-discuss] my comments to the WHOIS Task Force reports

Each user controls the "content" of their whois information, on a name-by-name basis...
They do not have to have a web-based result...

http://whois.cavebear.com

They can control what they put into the DNS whois...name by name...
http://www.analogx.com/cgi-bin/cgidig.exe?DNS=205.214.45.10&Query=whois.cavebear.com&Type=255&submit=Lookup

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

- ----- Original Message ----- 
From: "Eric Dierker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, August 29, 2002 1:47 AM
Subject: Re: [ga] Re: [atlarge-discuss] my comments to the WHOIS Task Force reports

> How can anyone buy into any of this load of crap?
> 
> The Whois in its' entirety stinks.
> 
> This is IP supterfuge and dead wrong!
> 
> Vittorio is wrong in engaging in this dialogue, it hurts privacy rights and 
> is nothing but a ploy to deny privacy rights.
> 
> Sincerely,
> Eric
> 
> --
> 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: Thu, 29 Aug 2002 08:13:41 -0500
From: "Jim Fleming" <[email-masked]>
Subject: [ga] "...no one -- absolutely no one -- really understands the behavior of DNS in the large..."

http://www.icann-ncc.org/pipermail/discuss/2002-August/002766.html
[email-masked] [email-masked] 

"...no one -- absolutely no one -- really understands the behavior of DNS in the large..."

=========================================================================

People with DNS laboratories do....also, people who write DNS software understand how the DNS works...

1. Does ICANN have a DNS Laboratory ?

2. Does ICANN have any people who write DNS software ?

3. Do ICANN employees have offices and report to work each day ?

4. What do ICANN employees do each day ?

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

http://www.icann-ncc.org/pipermail/discuss/2002-August/002766.html
[ncdnhc-discuss] Names Council agenda item request: discussionof wholesale price for names 
[email-masked] [email-masked] 
Wed, 28 Aug 2002 23:39:12 -0700 
- --------------------------------------------------------------------------------

On Wed, Aug 28, 2002 at 09:32:04PM -0700, Dave Crocker wrote:
> At 11:26 PM 8/28/2002 -0400, Milton Mueller wrote:
> >Until we add more than 500 TLDs a year there is
> >no issue with BIND and DNS. None.
> 
> BIND, no.  DNS root access? Maybe no, maybe yes.  The effect of traffic 
> patterns on root access is a matter of continuing debate among the DNS 
> technical community, as recently as the past few weeks.

Yes, that has been a most interesting discussion.  It has reinforced my
belief that no one -- absolutely no one -- really understands the
behavior of DNS in the large.  One thing seems fairly clear -- the root
zone really is different than a TLD zone. 

In any case, it's moot: the issue isn't what the software will support;
the issue is the far more complex matter of the procedures of the
registry/registrar.  Verisign and most other registrars, for example,
have largely automated procedures, and those procedures are not perfect
- -- there are many horror stories about lost domains, customer service
screwups, and the like.  The idea that the root zone should be run under
a similar model is entertaining, but it is simply never going to happen,
regardless of the most fervent libertarian fantasies.

This has nothing to do with ICANN, per se -- any agency with serious
pretentions of management of the root zone would inevitably be drawn
into the same position. 

Kent
=============================================================================

- --
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 #1400
*************************