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

GA-DIGEST          Wednesday, June 11 2003          Volume 01 : Number 1720

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

Date: Tue, 10 Jun 2003 08:35:08 -0500
From: "Jim Fleming" <[email-masked]>
Subject: [ga] ?:? .TRAVEL

http://www.cavebear.com/cbblog-archives/000030.html
Posted by karl at May 23, 2003 08:14 PM 
"I have received several letters from people in the travel industry indicating their support for .travel"
====

Do you direct them to the existing .TRAVEL Proof-of-Concept TLD developments ?

http://root-dns.org/vuedig/vuedig_tld.php?record=NS&tld=travel&submit=Submit
NSpace : Name.Space : 209.48.2.11
VueDig Results : Answer = 6 : Authority = 0 : Additional = 6. 
travel. 1D IN NS NS10.AUTONO.NET.
travel. 1D IN NS ROOT3.AUTONO.NET.
travel. 1D IN NS NS10.ROOT-ZONE.NET.
travel. 1D IN NS A.TLD-SERVERS.NET.
travel. 1D IN NS B.TLD-SERVERS.NET.
travel. 1D IN NS NS.AUTONO.NET.

Nnet : New.net Inc : 206.132.100.42
VueDig Results : Answer = 4 : Authority = 0 : Additional = 4. 
travel. 2H IN NS tld1.newdotnet.net.
travel. 2H IN NS tld2.newdotnet.net.
travel. 2H IN NS tld3.newdotnet.net.
travel. 2H IN NS tld4.newdotnet.net.
=======================================================

Jim Fleming
http://www.IPv8.info
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
?:? .TRAVEL

- --
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, 10 Jun 2003 08:46:51 -0500
From: "Jim Fleming" <[email-masked]>
Subject: [ga] .LA...Does ICANNwatch...watch closely ?

Does ICANNwatch...watch closely ?

http://www.postel.org/people.html
http://www.icannwatch.org
LA Names Corporation Ltd. Launches .LA Domain Name Registration
posted by michael on Monday June 09 2003, @11:21AM
"Dublin, Ireland-based Afilias Ltd. has entered into an agreement to provide back-end registry services to LA Names in a manner
consistent with its agreements to manage the technical operation of .org, .vc, and other ccTLDs."
===
http://www.postel.org/people.html
http://root-dns.org/vuedig/vuedig_tld.php?record=NS&tld=la&submit=Submit
LRS : Legacy Root Servers : 198.41.0.4
VueDig Results : Answer = 2 : Authority = 0 : Additional = 2.
la. 2D IN NS TLD2.ULTRADNS.NET.
la. 2D IN NS TLD1.ULTRADNS.NET.
=====
http://www.postel.org/people.html
Does ICANNwatch...watch closely ?...where does the money really go ?

Jim Fleming
http://www.IPv8.info

- --
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, 10 Jun 2003 09:52:45 -0500
From: "Jim Fleming" <[email-masked]>
Subject: [ga] Fw: [ncdnhc-discuss] Registries statement on TLD filtering by ISPs

[1]From: "Milton Mueller" <[email-masked]>
> ·         New TLDs, added to the TLD list in Nov 2000, are not yet globally
> accepted by ISPs, web hosts and e-commerce sites.

The 32-bit DNS and the aging, legacy, IPv4 Internet is only useful for Proof-of-Concept market trials.
Once a TLD is proven, mature, etc. and there is a stable base of SLD.TLD names with working servers,
the new 128-bit DNS software will automatically locate the Best-of-Breed TLDs for users who demand
the higher quality services, which they obtain from the always-on InterNAT...

Jim Fleming
http://www.IPv8.info

[1]----- Original Message -----
From: "Milton Mueller" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 10, 2003 9:19 AM
Subject: [ncdnhc-discuss] Registries statement on TLD filtering by ISPs

>
> Members:
>
> The following statement was prepared by the Registry constituency.
> It refers to how many ISPs are not implementing new TLDs by
> maintaining outdated lists of authorized TLDs. This is a serious
> issue for those of us who want to see name space expansion and
> flexibility. On the one hand, new TLDs are required to promote
> competition and diversified service. On the other hand, we want
> to maintain the Internet's status as a cooperative and voluntary
> endeavor and give different providers, countries, and regions
> flexibility and choice. I put this before the constituency as a
> discussion document; interested in hearing your views.
>
> ===
> FILTERING OF NEW TOP LEVEL DOMAINS BY THE ISP's
>
> Since new domain names (DNS) were first introduced, top-level domains (both
> gTLDs and ccTLDs) have been predominantly two or three characters.  Although
> one four letter TLD was initially created (.arpa), such domain has not been
> in use by the general public.  Prior to November 2000, the list of valid
> TLDs very seldom changed, and only a few ccTLDs were added to the list,
> including Palestine (.ps) and Afghanistan (.af).
>
> FILTERING NEW TOP LEVEL DOMAINS
>
> In November 2000, however, seven new TLDs were approved by ICANN and
> subsequently added to the root.  These included several TLDs with 4 or more
> characters (.aero, .coop, .info, .name, and .museum).  Although the
> implementation of these new TLDs began in 2001, they found considerable
> barriers for being accepted by most ISPs worldwide.  Even several of the
> three letter new TLDs, including .biz, ran into some difficulty in being
> accepted by many of the world's leading ISPs.
>
>  Some ISPs are using incomplete domain name lists for filtering e-mail and
> URL addresses [1] and it is obvious their systems that filter
> top-level domain names do not check and update the current validation list
> of TLDs ("generic" and country code-related) published by IANA at
> http://www.iana.org/domain-names.htm <http://www.iana.org/domain-names.htm>
> .
> This is critical because when an incomplete list is used, new TLDs will not
> be recognized as valid domains and the system may try to reach them via
> different domains.  For example, "entity.xxxx" is a valid name because it is
> included in the IANA list; however, if ISPs do not recognize "xxxx." as a
> valid TLD, this is turned into "entity.xxxx.com" and
> http://www.entity.xxxx.com" instead (and then fails or finds the wrong
> host).
>
> ICANN PLANS
>
> According to several recent reports, ICANN intends to expand the list of new
> gTLDs.  Such expansion may take place at regular intervals. Thus, it is
> essential that ICANN and its constituencies, in particularly the ISPs, are
> aware that at present this problem exists and, as a result, new gTLDs are
> not able to function adequately.
>
> New potential registry operators should be aware that this barrier exists
> and ICANN should consider coordinating these issues more closely.  Global
> acceptance of all valid domain names is an integral part of maintaining
> Internet stability.
>
> CONCLUSION
>
> It is important to note:
>
> ·         New TLDs, added to the TLD list in Nov 2000, are not yet globally
> accepted by ISPs, web hosts and e-commerce sites.
>
> ·         Security techniques, which have been designed to protect the DNS
> system, are creating barriers for non-accessibility (acting as filters).
>
> ·         ISPs, when rejecting valid forms of domain names, email addresses
> or URLs, effectively deny service to the user of those entities or cyber
> communities.
>
> ·         ICANN seeks to extend new TLDs to the current TLD list despite the
> above-described problem.
>
> ·         New potential TLDs should be made aware of this problem before
> submitting applications at the next opening.
>
> RECOMMENDATIONS
>
> As this problem is causing economical hardship to sponsors, registry
> operators and consumers, we recommend that the ISP Constituency along with
> the ICANN community collaborate more closely to minimize these problems.
>
> [1] Detailed description of the filtering issue is contained in a
> new I-D published here
>
> (http://www.ietf.org/internet-drafts/draft-klensin-name-filters-00.txt).
>
>

- --
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, 10 Jun 2003 12:32:57 -0400 (EDT)
From: Joe Baptista <[email-masked]>
Subject: [ga] [ppml] INADDR access should be axfr off all the INADDR DNS servers (WAS) A proposal to modify proposal 2003-9 (WHOIS and INADDR access)

Frankly I think restricting access to the INADDR zone is lunacy.  What if
all the INADDR servers are under attack and reverse resolution goes
offline.  Would it not be nice if ISP's had the option of slaving the
zone via axfr.

Of course the zone is now a mess.  And I did not give permission nor have
any of the legacy ipv4 allocations been given an opportunity to comment.

It was my understanding that our reverse resolution was IN-ADDR.arpa.  Now
I find out we no longer have our allocation listed in the IN-ADDR.arpa
zone.  Instead in one case we now are listed in the 199.IN-ADDR.arpa zone.
and so on and so forth.  It seems that arin has taken over our zones
without our permission, consent or knowledge.  I never agreed to this when
we applied for our direct allocations.  Does anyone know.  What are the
legal ramification of the RIR taking over legacy IN-ADDR.arpa zones.  Was
there a policy covering this?

In any case dividing the IN-ADDR.arpa into zones controlled by the RIR is
not in my opinion good policy.  In order to avoid disaster in case of
attack against the IN-ADDR.arpa zone it would be prudent for isp's to have
the ability to slave the zone.  but the way it's now divided up is a
nighmare to anyone since you have to slave bits and pieces of it and that
provided the RIR's have axfr turned on, and you know which zones you want
to slave and which RIR carries it.  What nonsense.

I personally used to slave IN-ADDR.arpa and now i can't anymore since it
no longer provides the security needed to avoid a potential attach againt
the IN-ADDR.arpa servers.  The RIR being in the middle have messed it up.

regards
joe baptista

Joe Baptista - only at www.baptista.god

another useless fact ....
A bolt of lightning can strike the Earth with a force as great as 100
million volts.

On Tue, 10 Jun 2003, Owen DeLong wrote:

> OK... I guess I'll throw my hat in the ring here...
>
> I think that the IN-ADDR data should be provided.  If ARIN staff feels
> a policy is needed, then I think two things have happened...
>
> 	1.	ARIN staff has become too policy focused.  IN-ADDR can
> 		be easily mapped by repeatedly hitting the DNS servers
> 		and there are no privacy issues with it.  The data should
> 		simply be made available.  As such, I hope this will provide
> 		the impetus for RichardJ to get whatever approvals are
> 		necessary from ARIN Management/BOD to make this happen without
> 		policy.
>
> 	2.	We have discovered the need for additional clarification to
> 		the ARIN staff of what should and should not require
> 		formal public policies to accomplish.
>
> Personally, I think that the ARIN IN-ADDR zone file(s) should be made
> available
> via FTP and/or HTTP and that should be the end of it.
>
> However, I am not diametrically opposed to applying the same AUP to WHOIS
> and IN-ADDR.  I think it is policy overkill, but, it's certainly better
> than not having the IN-ADDR information available at all.
>
> Owen
>
>
> --On Tuesday, June 10, 2003 4:39 AM -0600 John Brown <[email-masked]>
> wrote:
>
> > On Tue, Jun 10, 2003 at 12:44:26AM -0700, [email-masked] wrote:
> >>
> >> Fine, lets get ARIN to listen and provide the data for all other /8
> >> blocks!
> >
> > I think that is an over statment, and certainly not something I'm asking
> > for. ARIN was clearly specifide and not the other RIR's.  For them they
> > each have their proper venue, and its not here.
> >
> >
> >>
> >> Still the question is do we need a policy for this? If we do should it
> >> actually require authentication similar to bulk whois to get the data or
> >> is current system of getting it by ftp enough?
> >
> > Based on email from ARIN staff last fall, they used to provide the data
> > upon request, but started refusing the data until there was a policy in
> > place.
> >
> > The ARIN AC (post my resignation) did not feel it was something in their
> > scope as defined by the board.  THe board has said that the AC is to
> > deal with clear and crisp IP allocation policies only.   I think even
> > the whois is not within their view based on the direction from the board.
> >
> >
> >>
> >> In my opinion adding in-addr to bulk-whois proposal is both not
> >> approriate as whois data is a lot more complex and has rather specific
> >> privacy issues, its unnecessory and it sounds bad as far as you wrote it
> >> (i.e. what you  proposed - "arin whois inaddr aup").
> >
> > I agree, WHOIS is more complex and has privacy issues.  Hence the IN-ADDR
> > should be an easy issue to deal with.
> >
> > I don't believe I used those words you are attributing to me.  Please
> > correct or quote correctly....
> >
> > What I stated is that access to the whois  OR  inaddr carried with it the
> > same level of restrictions and conditions.  This would be more protection
> > for the IN-ADDR and continue to protect the whois data.
> >
> >
> >
> >> First I think we need to ask ARIN if they are willing to get all the
> >> inaddr data out on their ftp site on their own based on current polices
> >> and procedures (they do after all provide entire ASN list including all
> >> those ASNs they inherited from Internic, so why is it so different for
> >> inaddr?). If they do not want to do it, then propose a simple policy:
> >> "ARIN will provide public access to complete INADDR data for all ip
> >> blocks in its database for public download by ftp"
> >
> > Well todate ARIN has refused to provide IN-ADDR lacking a policy.  I can
> > dig up the email from ARIN staff issued last fall, if needed.
> >
> > Agreed they have the ASN data, the IN-ADDR seems easy as well since they
> > have to gen the zone for their NS set anyway.
> >
> > Personally I believe that ARIN should have an AUP for this data.
> >
> > John Brown
> >
> >>
> >> > > -----Original Message-----
> >> > > From: [email-masked] [mailto:[email-masked]] On
> >> > > Behalf Of [email-masked]
> >> > > Sent: Monday, June 09, 2003 11:44 PM
> >> > > To: John M. Brown
> >> > > Cc: [email-masked]
> >> > > Subject: Re: [ppml] A proposal to modify proposal 2003-9
> >> > > (WHOIS and INADDR access)
> >> > >
> >> > >
> >> > > Why do you need policy for providing in-addr data as bulk? I
> >> > > think ARIN
> >> > > already provides this all publicly as it, see
> >> > > ftp://ftp.arin.net/pub/zones
> >> > >
> >> > > Do you need something more then
> >> > > that?
> >> > >
> >> > > On Mon, 9 Jun 2003, John M. Brown wrote:
> >> > >
> >> > > > 3. A policy for bulk WHOIS and or ARIN INADDR access will
> >> > > be published
> >> > > > on
> >> > > >    ARIN website as follows:
> >> > > >
> >> > > > "Access to the entire WHOIS or ARIN INADDR database or
> >> > > large portion
> >> > > > of
> >> > > > it may be obtained by any organization or individual
> >> > > provided that this
> >> > > > organization or individual agrees in writing to ARIN WHOIS/INADDR
> >> > > > Acceptable
> >> > > > Use Policy. WHOIS or ARIN INADDR data provided under bulk
> >> > > WHOIS access
> >> > > > will not include any information that is marked as private.
> >> > > >
> >> > > > Access to WHOIS/INADDR data may be by way of:
> >> > > >
> >> > > > Individual WHOIS/DNS queries
> >> > > >
> >> > > > FTP or other type of download
> >> > > >
> >> > > > Hard media distribution (such as CDROM)
> >> > > >
> >> > > >
> >> > > > -----
> >> > > >
> >> > > > Given that ARIN now has policy  2002-1 Lame In-addr,
> >> > > providing access
> >> > > > to the in-addr view that ARIN has would be useful for the internet
> >> > > > operational and research community, and help reduce lame
> >> > > issues.  This
> >> > > > access would allow service providers access to the IN-ADDR tree
> >> > > > and  allow them to self verify what deligations they are listed as
> >> > > > authoritative for.  It would allow the research community a better
> >> > > > source of data for research and other activities.
> >> > > >
> >> > > >
> >> > > > respectfully,
> >> > > >
> >> > > > john brown
> >> > >
> >>
>
>
>

- --
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, 11 Jun 2003 09:16:15 -0500
From: "Jim Fleming" <[email-masked]>
Subject: [ga] 1:240 .DELAWARE...3:89 DE

As the InterNAT (North American Transport) overlays the Internet...
http://freestateproject.org
http://www.europeanfreestate.org/
"Caught up in the claws of the constantly growing monster state, our freedom is taken away piece by piece, day by day."
=====

http://www.ci.wilmington.de.us/
http://Wilmington.dot.DE
http://www.Wilmington.Delaware

See also http://www.DOT.de
...for free domain names...

DOT = Department of Transportation ???

1:240 .DELAWARE

http://Dover.dot.DE
http://Georgetown.dot.DE
http://Lewes.dot.DE
http://Milford.dot.DE
http://Newark.dot.DE
http://Seaford.dot.DE
http://Wilmington.dot.DE

Jim Fleming
http://www.IPv8.info

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