Copy Link
Add to Bookmark
Report
Netizens-Digest Volume 1 Number 210
Netizens-Digest Thursday, November 19 1998 Volume 01 : Number 210
Netizens Association Discussion List Digest
In this issue:
Re: [netz] Re: Is Netscape filtering sites?
[netz] Re: Do Internet Users exist?
Re: [netz] Re: Is Netscape filtering sites?
[netz] Name space
----------------------------------------------------------------------
Date: 19 Nov 1998 05:04:28 +0100
From: Carsten Laekamp <lakamp@capway.com>
Subject: Re: [netz] Re: Is Netscape filtering sites?
kerryo@ns.sympatico.ca (Kerry Miller) writes:
> Carsten,
> > Hmmm... this isn't taking into account the shortage of IP
> >numbers. Since that system needs to be reorganised, it would seem
> >sensible to reorganize the name system too.
>
> Isn't IP *expansion* sufficient, if 12 digits is not enough? It looks
> to me as though the practical way to do that is to start down the
> 'devolution' path, with distributed or partial servers, and or 'local'
> lookup tables.
What I was saying was that if a (whatever) change in the IP #s occurs,
this would mean reorganising a few things and would be a good
opportunity to modify the name system as well (on a psychological more
than on a technical basis).
> > The first thing would be to get rid of .com, .edu, etc..., domains,
> >which don't have any real justification in an international Internet
> >anyway. Introducing sub-domains like the British or Japanese *.co.*,
> >*.ac.* would then increase the number of possibilities.
>
> Those TLDs are simply one way of divvying up the implicit .us
> domain.
No. If they were, there wouldn't be any problem. But many European
sites now have .com or .org addresses. This also adds to the
confusion.
> > And this could be repeated several times in the future, when there
> >is a need for it. i.e. you could have a *.e-com.com.us for
> >e-commerce, a *.pa-local.com.us (or even pa.local.com.us) for local
> >businesses in Pa, and so on.
> >
> This is the crux: can the net be 'efficient' with wildcards? JP
> didnt (and GS doesnt) think so - but JP didnt forsee the rampant
> commercial takeover, and GS, with the takeover upon us, has yet to
> enunciate an alternative.
>
I'm not sure what ou mean with "wildcards", sorry. I just meant those
to be replaced by anything, just like I would write *.com for today's
situation. What I meant was introducing apparent "second-level"
(and maybe, later, "third-level") domains, as there are top-level
domains today.
As someone said, there is no shortage of available names, only of
those that make sense. This would be a way to increase the number
of those that make sense. Of course, this could be just a formal
(not structural) change, i.e. there need not be another
administrative layer. But it would also provide for the possibility
of introducing more layers, if needed.
> > The main problem I see with the menu system is that it will only
> >introduce *sort of* another "local" DNS, which will be further away
> >(physically) from the "final" host than in most cases today, thus
> >increasing connection failures.
> >
> Physical schmysical ;-) it'll simply look like one more hop to a
> trace router.
No. A "hop" would be "on" the route. What you have in mind, if I
understood you well, is more like what Monolith do today, just with
a choice of several IP #s per address (BTW: how would that
choice be made, if no physical person is available for that purpose ?)
> a) its not a local DNS, because *names are not looked up, only IPs;
I was talking of a "local" DNS on the server side (Greg Skinner said
approximately the same as I but much better). Whether you map an IP
number to an address or to the result of a choice isn't
*fundamentally* different. And, in both cases, you need to register
your server with the DNS respectively with the "IP-chooser".
Hence the analogy.
.
> b) nothing whatsoever stops a user from plugging in the IP number from
> the get-go -- then or now.
Sure. But, then, we're not talking DNS or your system anymore :)
BTW: what would happens if "someone" decided not to expand IP numbers
but to use dynamic ones for everyone ?
> The DNS was put together as a *convenience to users*. What has
> happened over the past 10 or 15 years is that modern commerce has
> determined to claim the right to define that convenience, and
> therefore wants a DNS which is convenient to *it*.
Sure. Let's just say: "random adresses for everyone" and the problem
is solved, *with* the current system, for a few decades. :)
- --
Carsten Läkamp
claekamp@mindless.com
------------------------------
Date: Thu, 19 Nov 1998 11:21:13 -0400
From: kerryo@ns.sympatico.ca (Kerry Miller)
Subject: [netz] Re: Do Internet Users exist?
Greg,
> It's very
> difficult to find people who:
>
> * know a lot about the Internet
> * do not stand to profit from this knowledge
> * can be unbiased and impartial when it comes to resolving critical
> issues
It's a shame that we can't come up with some way to communicate these
issues around the world, be able to dicker back and forth instantaneously,
get aquainted, learn to trust one another, isnt it?
I guess we might as well just go shopping. The Market (TM) knows what we
want.
kerry
------------------------------
Date: Thu, 19 Nov 1998 09:23:57 -0800 (PST)
From: Greg Skinner <gds@best.com>
Subject: Re: [netz] Re: Is Netscape filtering sites?
In article <19981119043845.AAA20298@LOCALNAME> Kerry Miller wrote:
>Revising the assumptions does not reduce access: each and every site
>remains *directly* accessible by IP number.
The point I was trying to make was that these assumptions come from
over 20 years of 'net usage.
>From the beginning of browserdom, the 'bookmark file' has been an integral
>part of net navigation: how often do you, yourself, *remember* a URL and
>type it in, compared to _looking it up_?
Actually, I do a variety of things, including use bookmarks, cut and
paste from other sources, and type in URLs.
One thing that you need to consider is that DNS names are not just
used for web browsing. They are used by a vast arsenal of software.
Requiring all of that software (and all of the people who use it) to
change everything to use IP addresses (and keep track of IP addresses
that change) would be cumbersome and expensive.
>Why do you say so? Registration can be as centralized as is practical.
The model that you have proposed effectively makes the web site that
represents a nickname or abbreviation for some set of sites a registry
for those sites.
>We may be looking at an era of *continual unmanageability* -- is there
>anything in the emerging information economy to suggest that it will
>settle down? In any case, as you have said yourself, host tables were
>not unmanageable, merely* inconvenient*.
No, I did say they were unmanageable, for a variety of reasons. For
one, their size became unmanageable. For another, hosts would change
their IP address. Furthermore, new applications were developed that
required more sophisticated resolution of names to network resources.
The DNS was created to address all of these issues (and more).
>Sure enough, you've driven a spike right through the heart of the proposal!
>Golly gee, many sites may find it more convenient to register *different
>names, just as they used to do with phone numbers! And you know how
>utterly, excruciatingly inconvenient it was, when one line was busy, to have
>to dial another one that might be as many as two digits different!
I'm not following this.
> Can you tell me more about MX?
MX (mail exchanger) records are used to resolve the host-specific part
of an email address to a set of sites that are willing to accept the
message for eventual delivery for its recipients. If I want to send
mail to you, I contact the DNS for the address of a host that will
recieve the mail. This feature allows organizations to consolidate
their mail processing in a small number of sites.
>Again, can't we keep number problems separate from name problems?
Unfortunately, no. Scalability is something that needs to be
considered when designing a system.
>Frankly, I do not see why a menu site should become 'popular';
>wouldn't you rather have a name shared by *fewer* parties than be
>tagged at the bottom of a long list?**
A menu site that hosts Columbia Broadcasting would become quite
popular, simply because there are a lot of people who want information
about them.
>Isnt it interesting that the fundamental conceptuial problem in all
>of this has to do with the knot that binds all the distributed
>net-links together? That organizationally speaking, this fantastic
>*net* doesnt begin to compare with the electricity transmission grid,
>or even your city water supply reticulation?
I'm not sure what point you're trying to make here.
>100% correct. Now it only remains to be explained what in the everloving
>packetized world popularity has to do with the *operation* of a virtual
>communications system.
Because the system has to continue to work no matter how many people
use it, the design must be scalable. If it is not scalable, it
becomes very difficult to manage and use, and therefore loses value
(not just economic, but personal as well).
>** Since alphabetization is moot (they're all www.cbs.com, remember),
>obviously menu entries will build by a first-come, first-listed basis. And as
>everybody knows, consumers find it remarkably inconvenient to look beyond
>the first page of any list of hits.
This is an example of how scalability affects use. In your model,
people would tire of looking for the CBS they wanted if it was not on
the first page. This would raise the sorts of objections we have now
to the current DNS model, because every CBS organization would demand
to be listed first. If it came down to $$$, Columbia Broadcasting
would win out, and be able to justify the expenditure because they
would be getting the bulk of the traffic. So this model does not
really solve any inherent fairness problems, and works less reliably
and is more difficult to manage than the existing system.
>It is also worth asking whether site names are half as important to
>net users as we've been assuming they are. The use of search engines
>-- unheard of 5 years ago -- is continually increasing, and I'm
>fairly sure they don't pop across to some name server to find out
>where to go.
Actually, they do. Search engines, like every other piece of code
that requires network access, use name servers to resolve network
names to network resources.
- --gregbo
------------------------------
Date: Thu, 19 Nov 1998 15:32:03 -0400
From: kerryo@ns.sympatico.ca (Kerry Miller)
Subject: [netz] Name space
I.
http://www.isi.edu/in-notes/rfc1480.txt
(1993)
1.1
The Domain Name System (DNS) provides for the translation between
hostnames and addresses. Within the Internet, this means translating
from a name such as "venera.isi.edu", to an IP address such as
"128.9.0.32". The DNS is a set of protocols and databases. The
protocols define the syntax and semantics for a query language to ask
questions about information located by DNS-style names. The
databases are distributed and replicated. There is no dependence on
a single central server, and each part of the database is provided in
at least two servers.
[...]
The reason for the development of the domain system was growth in the
Internet. The hostname to address mappings were maintained by the
InterNIC in a single file, called HOSTS.TXT, which was FTP'd by all
the hosts on the Internet. The network population was changing in
character. The time-share hosts that made up the original ARPANET
were being replaced with local networks of workstations. Local
organizations were administering their own names and addresses, but
had to wait for the NIC to make changes in HOSTS.TXT to make the
changes visible to the Internet at large. Organizations also wanted
some local structure on the name space. The applications on the
Internet were getting more sophisticated and creating a need for
general purpose name service. The idea of a hierarchical name space,
with the hierarchy roughly corresponding to organizational structure,
and names using "." as the character to mark the boundary between
hierarchy levels was developed. A design using a distributed
database and generalized resources was implemented.
The DNS provides standard formats for resource data, standard methods
for querying the database, and standard methods for name servers to
refresh local data from other name servers.
1.2 Top-Level Domains
The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT,
and NET, and all the 2-letter country codes from the list of
countries in ISO-3166. The establishment of new top-level domains is
managed by the Internet Assigned Numbers Authority (IANA). The IANA
may be contacted at IANA@ISI.EDU.
| Even though the original intention was that any educational
| institution anywhere in the world could be registered under the EDU
| domain, in practice, it has turned out with few exceptions, only
| those in the United States have registered under EDU, similarly with
COM (for commercial). In other countries, everything is registered
under the 2-letter country code, often with some subdivision. For
example, in Korea (KR) the second level names are AC for academic
community, CO for commercial, GO for government, and RE for research.
However, each country may go its own way about organizing its domain,
and many have.
| There are no current plans of putting all of the organizational
| domains EDU, GOV, COM, etc., under US. These name tokens are not
| used in the US Domain to avoid confusion.
Currently, only four year colleges and universities are being
registered in the EDU domain. All other schools are being registered
in the US Domain.
There are also concerns about the size of the other top-level domains
(especially COM) and ideas are being considered for restructuring.
[...]
| Should all the names be obvious? Trying to do this is desirable and
| also impossible. There will come a point when the obviously right
| name for an organization is already taken. As the system grows this
| will happen with increasing frequency. While ease of use to the end
| user is desirable, a higher priority must be placed on having a
| system that operates. This means that the manageability of the
| system must have high consideration.
|
| The reason the DNS was created was to subdivide the problem of
| maintaining a list of hosts in the Internet into manageable portions.
|
| The happy result is that this subdivision makes name uniqueness
| easier and promotes logical grouping. What is a "logical grouping"
| though, always depends on the viewer.
|
| Many levels of delegation are needed to keep the zone files
| manageable. Many sections of the name space are needed to allow
| unique names to be easily added.
[...]
4.4 Wildcards
The wildcard records are of the form "*.<anydomain>", where
<anydomain> is any domain name. The wildcards potentially apply to
descendents of <anydomain>, but not to <anydomain> itself.
For example, suppose a large company located in California with a
large, non-IP/TCP, network wanted to create a mail gateway. If the
company was called DWP.LA.CA.US, and the IP/TCP capable gateway
machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the
following RRs [resource records] might be entered into the .US zone.
dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV
*.dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV
The wildcard record *.DWP.LA.CA.US would cause an MX query for any
domain name ending in DWP.LA.CA.US to return an MX RR pointing at
ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host
dwp can be found.
In the US Domain, wildcard records are allowed in our zone files
under the organizational subdomain (and where noted otherwise) but no
wildcard records are allowed under the "City" or "State" domain.
| The authors strongly believe that it is in everyone's
| interest and good for the Internet to have each host
| explicitly registered (that is, we believe that wildcards
| should not be used), we also realize that not everyone
| agrees with this belief. Thus, we will allow wildcard
| records in the US Domain under groups or organizations.
| For example, *.DWP.LA.CA.US.
|
| The reason we feel single entries are the best is by the mere
| fact that if anyone wanted to find one of the hosts in the
| domain name system it would be there, and problems can be
| detected more easily. When using wildcards records all the
| hosts under a subdomain are hidden.
[...]
==============
II.
http://www.ntia.doc.gov/ntiahome/domainname/usrfc/dotusrfc.htm
On February 20, 1998, NTIA published "Improvement of Technical
Management of Internet Names and Addresses; Proposed Rule," 63 Fed.
Reg. 8825 (1998) (also posted at
http://www.ntia.doc.gov/ntiahome/domainname/domainname130.htm). The
notice analyzed issues of generic Top-Level Domains (gTLDs), including the
future of gTLD registries and the possible creation of new gTLDs. Section VII.
D. briefly addressed the national or "country-code" domain (ccTLD) for the
United States, .us as follows:
At present, the IANA (Internet Assigned Numbers Authority at the University
of Southern California) administers .us as a locality based hierarchy in which
second-level domain space is allocated to states and US territories. This
name space is further subdivided into localities. General registration under
localities is performed on an exclusive basis by private firms that have
requested delegation from IANA. The .us name space has typically been
used by branches of state and local governments, although some
commercial names have been assigned. Where registration for a locality has
not been delegated, the IANA itself serves as the registrar.
[...]
Many of the allocation and governance issues under .us and other country-
codes are ultimately analogous to the issues in gTLDs. The early availability
and extensive use of gTLDs by U.S. companies, however, allowed .us to
develop separately under a hierarchical geopolitical structure. By contrast,
other country-code TLDs typically offer second-level domains on a more or
less open and unrestricted basis or allow unrestricted third-level domains
under a few two-character sector codes, such as .co for commercial or .ac
for academic. To our knowledge, no other country-code domain is managed
under a geopolitically ordered regime similar to .us.
Some have suggested using domain space for purposes such as zoning or
credentialing. With respect to zoning for example, there have been
suggestions that creating a domain for adult entertainment could facilitate
filtering while reducing liability risk for those businesses that register under it.
Likewise, a wide range of credentialed domains are possible, i.e., domains in
which the registrant warrants that it meets some standard or in which a third
party authority (e.g., a trade organization, a licensing agency, a bank)
certifies the identity or characteristics of the registrant. It may be desirable to
delegate such domains to a certifying entity, or to an entity that sets and
maintains the standard in the case of self-certifying registrants. To our
knowledge, no national registry has attempted such a regime of industry
identifiers or other classifications at the second or lower levels.
[...]
Questions for Public Comment
While the public is free to comment on any issue related to the .us domain
space, the Department is
particularly interested in receiving input from the questions provided below:
[...]
3.Specifically, should special-purpose second-level domains be created
under .us? What are the benefits and costs of creating particular special-
purpose domains (e.g., industry-specific, credentialing, zoning)? How should
such domains be created and administered? [...]
4.Alternatively, should .us be treated as an unrestricted top-level domain like
.com or should one or more specific second-level domains such as .co.us or
.com.us be used for unrestricted assignment of domain names (as in .com)?
How should such unrestricted domains be administered and by whom?
5.How should conflicting proposals and claims to manage or use .us
subdomains be resolved? Who should have responsibility for coordinating
policy for .us over the long term? What public oversight, if any, should be
provided?
[...]
============
III
A response (Aug 5) that seems relevant to our discussion:
You should do it like we do here in Australia, where only commercial
enteties have access to .com.au they must prove conclusively they own the
name. This allows most companies access to a domain name, especially if
someone else has taken the .com varient.
Also, all US government bodies should convert their .gov to .gov.us domain
names to distinguish the US government bodies from those of the rest of the
world.
==========
kerry
------------------------------
End of Netizens-Digest V1 #210
******************************
