.US Update

["Jim Fleming" <JimFleming@ameritech.net>]

From: "Daniel Manley" <dmanley@tucows.com>
> In terms of other objects, the practical example of .us comes to mind --
> they restrict domain delegation to nameservers physically located in the
> US, right?


http://www.dnso.org/clubpublic/registrars/Arc01/msg03547.html
From: "Michael D. Palage" <michael@palage.com>
.US Update
====

As an attorney, you seem to miss the technical implications of what you propose.
If one looks at the operational aspects of real servers, the realities of DNS, etc.
then the simple string ".US" takes on a different shape. This is not an http://Toys.R.US
debate, but rather heads in the other direction to the bits and the messages the servers
have to send to each other to play well together.

You, like most people likely assume that .US will remain in the legacy root servers.
That is likely a valid assumption for the "toy" 32-bit DNS. That may not scale to the
Next Generation Internet. You might want to learn more about how the Next Generation
Internet is architected. .US is a good TLD to use for examples. For years it was artificially
restricted and manipulated by the late Jon Postel. It is now less so. That is progress.
It should be noted that this progress did not happen in ICANN, it was handled directly
by the U.S. Department of Commerce.

Fortunately, or unfortunately .US has to live in a much larger name-space and play well
with all of the various software solutions "toy" and otherwise. Since the .US Registry contract
from the U.S. Government is only for a few years, it would be prudent at this point to look
down the road to make sure that .US not only leads but also plays well with the likely
changes that are here and coming. Unfortunately, people can not predict the future, but it
is possible to make a good guess, now that the various factions are lined up and clearly will
not change.

Stepping back, one might approach this as if .US was *not* in the aging legacy root servers
controlled by the U.S. Government. How would it get in ? Over the years, there have been
several ways that people have found to route around the blockades and to get in somewhere
into the name-space. One way has been the DLD (Dash-Level-Domain) path. In that approach
the .COM and .NET TLDs are used as hooks to add an unlimited number of extensions to
the left, via dash-based names. -ONLINE.com is a good example and one of the most popular.
When faced with not being able to get .ONLINE into the legacy root, one alternative is to
use the .ONLINE DLD.
http://www.icann.org/comments-mail/icann-current/msg00342.html
9264 ONLINE - 45,049 matches for -ONLINE
http://www.domainsurfer.com/ssearch.cgi?dom=-online.com
If .US had been forced to use this approach, it would have been popular, but not as popular
as .USA. Some could argue that is because people are now in the more open .US, but that has
not always been the case. The previous dictatorship only ended in 1998. .USA was never given
a chance and still has not been given a fair chance. It is an embarassment to all Americans. The
Whitehouse will surely try to do something before the next elections.
=======
13,465 matches for -USA
http://www.domainsurfer.com/ssearch.cgi?dom=-usa.com
6,087 matches for -US
http://www.domainsurfer.com/ssearch.cgi?dom=-us.com

Looking beyond the DLD approach, we now see that a few new TLDs have been tested in
the legacy roots with no operational impact. The people making money from them will of course
cook up whatever claims they want about being under attack and under load. That type of FUD
of course plays well in the post-9/11 climate. The usual-suspects will of course now try to figure
out how to profit from the unfortunate events of the past years, which they helped to create.
http://www.markletaskforce.org/

Because of the operational claims about load, etc. and because of the clear agenda to cleanse
the legacy roots of all TLDs that do not fit the "image" of the I* society, it becomes clear that
many of the so-called ccTLDs will fall by the wayside. Other so-called ccTLDs have become
gTLDs with solid commercial marketing plans to sustain them. That gives people confidence in
using them. No matter what happens, change is coming and the result will be a smaller, more-
controlled, legacy root-server approach. That makes the DLD approach look better and better.
Unfortunately, some people do not like building out from the .COM and .NET nodes as roots.
They feel that monopoly situation is not healthy to use. They want the control spread around.

Another approach to growing the name-space would be to place 26 TLDs in the legacy roots
and anyone that wants to start a TLD would pick it, and apply for a name under the first letter
of the TLD. That might be a nice approach if people had open minds and thought it was possible
to get 26 new TLDs added. In the current climate, open minds and willingness to test 26 new TLDs
is obviously not an option. Instead, one sees that they can use some simple ranges of letters
AE...FM...NR...SZ to use as nodes to build out from the root. This of course opens the debates
about why 4 nodes ?....some then want only 2 nodes....AM...NZ....then the NZ people decide
they are not going to let people in....then the OZ people next door pop up...and want AN...OZ
in concert with their European friends. No matter how it all shakes out, .US begins with the letter
U and would fall under SZ, or NZ or OZ.

Given all of the above, software has to be written which does not know a .US from a .SU,
or maybe one should say it knows the difference, but it does not care about the nexus, lexus, or
the brand of server in the car. In summary, .US will have to ultimately be treated like all of the
other TLDs. Given an [SLD].US name, that may mean that the software first looks under the
.US TLD, and then to the -US.com DLD and then to the -US.net DLD and finally to the
US.OZ zone or the US.SZ zone or the US.NZ zone. It will find the servers for the [SLD].US
and that search may not take the simple approach you seem to assume.


Whitehouse Ready to Release Next Generation Internet Plan
http://news.com.com/2100-1023-958159.html?tag=politech
http://www.politechbot.com/p-03994.html
http://www.uscryptomail.org/cybersecurity/
Note: The new plan calls for the same architecture used with IPv8 and IPv16,
whereby, users do not have direct access to the (out-of-band) IPv16 network.

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


----- Original Message -----
From: "Daniel Manley" <dmanley@tucows.com>
To: "James M Woods" <jwoods@netstormit.com>
Cc: "'Rick Wesson'" <wessorh@ar.com>; <ietf-provreg@cafax.se>
Sent: Friday, November 15, 2002 8:08 AM
Subject: Re: last-verified-date


> In terms of other objects, the practical example of .us comes to mind --
> they restrict domain delegation to nameservers physically located in the
> US, right?
>
> Dan
>
>
> James M Woods a écrit:
>
> >Rick,
> >
> >I think this is an excellent inclusion to the specs. I support it, so
> >long as its adopted as being optional at the registry level. As an aside
> >I also see some third party business applications opportunities by
> >including this..but I digress.
> >
> >To stir the pot a bit... are contacts the only objects we'd care to have
> >optionally last verified?
> >
> >Thoughts?
> >
> >James
> >
> >-----Original Message-----
> >From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]
> >On Behalf Of Rick Wesson
> >Sent: November 14, 2002 4:05 PM
> >To: 'ietf-provreg@cafax.se'
> >Subject: last-verified-date
> >
> >
> >
> >One of the items on the agenda for tuesday is a proposal for an element
> >of contacts objects. I'd like to get some discussion going on this so we
> >can stay in the 10 minutes allocated to the topic in our session.
> >
> >2.9 Last Verified Date
> >
> >The date the contact had the opportunity to affirm that the information
> >associated with the contact is correct. Registries MAY set policy on how
> >checking is preformed and what if any procedure a registrar MUST apply
> >to ensure correct Registrant data.
> >
> >
> >The concept is to add some quality assurance mechanism to the registrant
> >data and to make available for the publishing of the data in WHOIS or a
> >CRISP protocol so that end-users can have an indicator as to the last
> >date the information was verified.
> >
> >I appreciate any thoughts the group has on this proposal.
> >
> >thanks,
> >
> >-rick
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Daniel Manley
> Tucows, Inc.
> Toronto, Canada
> dmanley@tucows.com
>
>
>
>