[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
TLDs must be born from the womb of a registry
with the help of the ISPs and their customers.
Once gestation occurs, a registry presents
a formal proposal to ALL of the root name
server operators fro their consideration and
discussion. These root name server operators
help to facilitate the discussion along with
the registries and ISPs in OPEN forums.
At some point in time, the registry making
the proposal must decide based on the
discussion and any consensus reached
whether to "advance" the top level domain
for a vote by the root name server operators.
They vote it up or down by including it in
their collection of top level domains they
support.
There is checks and balance in the system
because ISPs still get to decide which root
name servers they want to use to provide
service. The customers of an ISP can decide
which ISP to use, based on the ISP's choice
of root name servers. All of this should be
done in the open and ISPs should make an
active choice, as opposed to the current
approach of having them bLindLY follow
their O/S vendors suggestion.
A public accounting of who is using what
servers and which roots support which
top level domains and which registries handle
a top level domain will help everyone see
the complete picture and market forces
can be allowed to steer this thundering
mass of economic infrastructure.
Because this approach follows the "natural"
lines of a free market and capitalism, no
one individual or company will be able to
control the decision making process.
Furthermore, because of the various levels
of organisms in the system, (roots, trunks,
branches, leaves) it will be extremely
difficult for casual or foolish entries to be
made to the collection of top level domains.
Some people have expressed concern to
me that this last point may not ALLOW
them to easily get into this game. I feel
that is a feature, because any system as
large as the Internet should not support
the introduction of change at such a
critical point as TLDs without many voices
being heard.
Even though this started as a discussion
about the IAHC, we should all keep in
mind that there are MANY more voices
on the Internet than those represented by
the ISOC. There are also more to come.
The ISOC and IAHC are just small voices
in the above "tree". If the system is designed
properly, they will take their place in the
tree and progress will quickly be made.
As I have suggested before, the ISOC
is an excellent candidate to help with the
thankless task of providing a root name
server. If they do that then they have ONE
vote in the forum of world root name
servers. They would also have to accept
proposals from registries (new or old) and
help with the deliberations.
I hope that the ISOC looks at the big
picture and realizes that the system is
evolving and there is a natural place to
fit into the "tree". I also hope that registries
and ISPs study the big picture and work
themselves into the market place and
the Internet Tree. If everyone does this
then customers (leaves) can flourish
on the Internet Tree and all will be well.
...enjoy the Internet Tree of Life...
...without it...we will perish...
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa29019; 7 Nov 96 16:45 EST
Received: from [204.250.49.14] by ietf.org id aa28751; 7 Nov 96 16:44 EST
Received: from mail.coupon.net (204.250.49.77) by mail.higgs.net
with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 7 Nov 1996 13:42:40 -0800
Received: from [204.250.49.20] by mail.coupon.net
with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 7 Nov 1996 13:42:36 -0800
Message-Id: <v03007800aea8057bf675 at [204.250.49.20]>
In-Reply-To: <199611071922.OAA25726 at ns1.vrx.net>
References: Message of Thu, 7 Nov 1996 08:43:48 -0600 from
<JimFleming at unety.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 7 Nov 1996 13:42:26 -0800
To: Jon Postel <postel at isi.edu>
Sender:ietf-request at ietf.org
From: Simon Higgs <simon at higgs.com>
Subject: [Question] IAHC = IDNB ???
Cc: ietf at ietf.org, newdom at vrx.net, newdom at ar.com
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Source-Info: From (or Sender) name not authenticated.
Hi all,
I'm trying to update draft-higgs-tld-cat for the IAHC committee's
review and have a protocol question. What is the difference between the
Internet Domain Name Board (IDNB) mentioned in some older RFC's and the
IAHC? They both appear to be performing the same executive domain name
functions.
Thanks,
Simon
--
Madness takes its toll. Please have exact change.
Received: from ietf.org by ietf.org id aa29024; 7 Nov 96 16:45 EST
Received: from [207.32.128.130] by ietf.org id aa28796; 7 Nov 96 16:44 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id PAA25567; Thu, 7 Nov 1996 15:34:54 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCCC1.7C657940 at webster.unety.net>; Thu, 7 Nov 1996 15:36:47 -0600
Message-ID: <01BBCCC1.7C657940 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Hank Nussbacher' <HANK at vm.biu.ac.il>, "ietf at ietf.org" <ietf at ietf.org>
Cc: 'New Newdom' <newdom at vrx.net>
Subject: RE: More iTLD thread
Date: Thu, 7 Nov 1996 15:36:45 -0600
Encoding: 27 TEXT
Source-Info: From (or Sender) name not authenticated.
On Thursday, November 07, 1996 4:06 PM, Hank Nussbacher[SMTP:HANK at VM.BIU.AC.IL] wrote:
@ On Thu, 7 Nov 1996 13:57:35 -0600 you said:
@ >I do not think that you 4 months. Have you read Paul Vixie's
@ >postion statement giving you a January 15, 1997 deadline
@ >before he goes "ballistic" (whatever Paul means by that).
@
@ Once you see our timetable you will understand why we need
@ 4 months to solicition proposals, create or adopt the official
@ one, place it in the public for review, solicit comments,
@ modify the doc, have the award process, get the submissions,
@ judge them and assign the new iTLDs. That entire process cannot
@ be condensed to 2 months. But wait 72 hours to see the milestones
@ and I believe you will agree. We have been talking to Paul.
What exactly do you think that you are awarding...?
Why haven't the discussions with "Paul" been in
an open forum...?
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa29961; 7 Nov 96 16:59 EST
Received: from ns2.harborcom.net by ietf.org id aa29670; 7 Nov 96 16:54 EST
Received: from swoosh.dunn.org (swoosh.dunn.org [206.158.7.243]) by ns2.harborcom.net (8.7.6/8.6.12) with SMTP id QAA21804; Thu, 7 Nov 1996 16:53:28 -0500 (EST)
Date: Thu, 7 Nov 1996 16:51:27 -0500 ()
Sender:ietf-request at ietf.org
From: Bradley Dunn <bradley at dunn.org>
To: Phill Kelley <Phill.Kelley at aspect.com.au>
cc: ietf at ietf.org
Subject: Re: The price of chatter
In-Reply-To: <v03007806aea7343c55f8 at [137.76.60.51]>
Message-ID: <Pine.WNT.3.95.961107164746.-273261B-100000 at swoosh.dunn.org>
X-X-Sender: bradley at harborcom.net
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Wed, 6 Nov 1996, Phill Kelley wrote:
> I have been out of my home town for the past week and have just called
> long-distance to clear my email. There were some 170 messages which the
> wonderful "check your own bill" service on the hotel TV tells me cost $US35
> to download.
Four letters for you:
IMAP
-BD
Received: from ietf.org by ietf.org id aa01212; 7 Nov 96 17:03 EST
Received: from [207.32.128.130] by ietf.org id aa00962; 7 Nov 96 17:02 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id PAA25651; Thu, 7 Nov 1996 15:53:14 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCCC4.0C4F4AC0 at webster.unety.net>; Thu, 7 Nov 1996 15:55:07 -0600
Message-ID: <01BBCCC4.0C4F4AC0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Hank Nussbacher' <HANK at vm.biu.ac.il>, "ietf at ietf.org" <ietf at ietf.org>
Cc: 'New Newdom' <newdom at vrx.net>
Subject: RE: More iTLD thread
Date: Thu, 7 Nov 1996 15:55:06 -0600
Encoding: 138 TEXT
Source-Info: From (or Sender) name not authenticated.
On Thursday, November 07, 1996 4:06 PM, Hank Nussbacher[SMTP:HANK at VM.BIU.AC.IL] wrote:
@ On Thu, 7 Nov 1996 13:57:35 -0600 you said:
<snip>
@
@ >Can you provide people with your background
@ >and expertise in this area ?
@
@ It will be in the announcement. What you won't find there is
@ that I set the existing policy for the Israeli domain name
@ space, I selected the TLDs, and I still arbitrate cases when
@ the registrar has a question. You can find more about it
@ at www.isoc.org.il.
@ Hank
That really worries me. You seem to have a bias already
that one person or a small group can make important
decisions.
That happened in Australia and they are not allowed
to use "dictionary" words below COM.AU.
Have you followed that situation ?
You might want to consider a BIGGER picture.
It might be good if you develop a plan that gets
many people involved and focuses on the people
that own and operate the equipment.
I offer the following as help in looking at a broad
picture. You will note that you are listed twice.
That is more than can be said for anyone else.
As a participant for the IAHC, all you have to do
is help the ISOC deploy a root name server to
allow them to become part of the critical Internet
Infrastructure. Once they do that then they can
become actively part of the support of top level
domains, by their additions and deletions to
THEIR data base. They will participate as an
equal with the other root name server operators.
@@@@@
0 - Legacy Internet, R&D, Education, Etc.
0 - IANA - U.S.- Southern California - NS1.ISI.EDU - 128.9.0.107
1 - InterNIC - U.S. - Virginia - NS.INTERNIC.NET - 198.41.0.4
2 - NANOG - ???
3 - ISP/C - ???
4 - MERIT - ???
5 - IETF - U.S. - California - NS.ISC.ORG - 192.5.5.241
6 - ISOC - Contact Don Heath - heath at linus.isoc.org
IAHC - Contact ???
1 - Perry Metzger - perry at piermont.com
2 - David Crocker -
IAB
3 - Geoff Huston
4 - Hank Nussbacher - HANK at VM.BIU.AC.IL
5 - David Maher
6 - Sally Abel
7 - Robert Shaw
8 - WIPO representative
9 - ???
7 - WIA - ???
1 - North America (U.S., Mexico, Canada)
0 - U.S. - Northwestern - AlterNIC - MX.ALTERNIC.NET - 204.94.42.1
1 - U.S. - Illinois - MCS Net - ROOT-NS.MCS.NET - 192.160.127.86
2 - U.S. - Michigan - AGN Net - SIMBA.AGN.NET - 160.79.1.3
3 - U.S. - Wisconsin - SPARKNET.NET - ROOT-NS.THENIC.NET - 207.67.22.81
4 - U.S. - Maryland - TERP.UMD.EDU - 128.8.10.90
5 - Canada - Ontario - TORONTO.ALTERNIC.NET - 207.107.232.106
6 - Mexico - http://www.nic.mx ???
7 - U.S. - Southeastern - C.PSI.NET - 192.33.4.12
2 - South America, Central America and the Caribbean
0 - U.S. Virgin Islands - USVI.NET - 204.199.0.4
1 - British Virgin Islands - ???
2 - Brazil - ???
3 - Argentina ???
4 - Venezula - Contact Peter de Blanc - pdeblanc at usvi.net
5 - Bolivia ???
6 - Costa Rica???
7 - Panama ???
3 - England, Europe, Scandanavia and Russia
0 - RIPE - Netherlands - http://www.eu.net ???
1 - Sweden - NIC.NORDU.NET - 192.36.148.17
2 - England - Contact Keith Mitchell - keith at linx.org
3 - France - Contact Laurent BERNARD - lbernard at artinternet.fr
4 - Germany - ???
5 - Switzerland - ???
6 - Italy - ???
7 - Ukraine - NS.WW.NET - 193.124.73.100
4 - Japan, Korea, China and The Pacific Rim
0 - APNIC - http://www.apnic.net ???
1 - Japan - http://www.nic.ad.jp ???
2 - Korea - http://www.krnic.net ???
3 -
4 - Taiwan - http://www.twnic.net ???
5 - China - http://www.cnc.ac.cn ???
6 - Philippines - http://www.ph.net ???
7 - Hong Kong - http://www.cuhk.hk/hkwww.html ???
5 - Asia, Africa and the Middle East
0 -
1 - India - http://www.iisc.ernet.in/innic.html ???
2 - Pakistan - http://www.ar.pk/public/pknic.html ???
3 - Bangladesh - http://www.bangla.org/bdinet ???
4 - Israel - ??? Hank Nussbacher - HANK at VM.BIU.AC.IL ???
5 - Saudi Arabia - ???
6 - South Africa - ???
7
6 - Australia, New Zealand, Southeast Asia and the South Pacific
0 - Australia - Contact Andrew Khoo - andrew at aussie.net
1 - New Zealand - http://servius.waikato.ac.nz/isocnz ???
2 - Singapore - http://www.nic.net.sg ???
3 - Thailand - http://www.thnic.net ???
4 - Indonesia - http://www.iptek.net.id/ipteknet_eng.html ???
5 - Guam - http://ns.gov.gu ???
6 - Malaysia - NS.ALPHAQUE.COM - 202.185.254.12
7 -
7 - Vehicles, Boats, Spaceships, Ham Radio, etc.
0 - NS.NASA.GOV - 192.203.230.10
1 - NS.NIC.DDN.MIL - 192.112.36.4
2 - AOS.ARL.ARMY.MIL - 128.63.2.53
3 - NS.UNETY.NET - 207.32.128.1
4 -
5 -
6 -
7 -
@@@@
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa02829; 7 Nov 96 17:26 EST
Received: from mail.his.com by ietf.org id aa02635; 7 Nov 96 17:24 EST
Received: from 205.252.80.251 (tiernojo.his.com [205.252.80.251]) by mail.his.com (8.6.9/8.6.12) with SMTP id RAA23126; Thu, 7 Nov 1996 17:17:29 -0500
Message-ID: <328260F4.3BB4 at his.com>
Date: Thu, 07 Nov 1996 17:22:42 -0500
Sender:ietf-request at ietf.org
From: "Tierno S. Bah" <tiernojo at his.com>
Reply-To: tiernojo at his.com
Organization: AfriQ*Access, Inc.
X-Mailer: Mozilla 3.01 (Macintosh; I; 68K)
MIME-Version: 1.0
To: HANK at vm.biu.ac.il
CC: newdom at ns1.vrx.net, ietf at ietf.org
Subject: Re: More iTLD thread
References: <9611070428.aa10502 at ietf.org> <32824D67.5DD0 at his.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Hank Nussbacher wrote:
>
> There should be 4-5 [true root nameservers] in
> Europe, 2-3 in the Far East and about 6-7 in North America all funded
> via new iTLDs.
What about Central, South America? What about Africa?
> As a former American who moved to Israel 15 years ago I have to agree
> with you. Americans are very geo-centric and have a hard time understanding
> the mentalities of other countries.
Judging by your deliberate way of shrinking the world by excluding
Africa and C-S America, one might think that the above diagnosis
(geo-centrism & narrow-mindedness) applies to you. Either you caught
them in the USA, or you developed them on you own.
However, at the risk of becoming a shadow of itself, the Internet shall
span and integrate the entire planet Earth, i.e., all five (5)
continents. Otherwise, it may suffer the same fate that has discredited
previous threshold technologies, which fell short of their initial
universal promise, becoming instead tools of arrogance and hegemony...
Already, Internet engineers and multinationals, not unlike the 19th
century European explorers (Livingston, Cecil Rhodes, de Sanderval
etc.), are crusing Africa, tricking or colluding with complacent PSTN
offcials, and surrepticiously taking over functions that are arguably
sovereign attributes of States, such as country registration with the
InterNIC, DNS and IP addresses management ...
As the saying goes, "The more things change, the more they remain the
same". When all the hype and excitement have subsided, the continents,
countries and people you so flagrantly rule out may well see in the
Internet something deja vu and questionable, because it will have left
them more disenfranchised than ever before.
- Tierno Bah
--
Voice: 301-680-1971 Fax: 301-680-0567
*************************************************************************
Midho yhawi e tulde gandun am On my little knowledge I stand
No mi yheewira nibhe majjere am. To gauge the depth of my ignorance.
(T.S. Mombeya)
*************************************************************************
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCPAzHtEI4AAAEEANx5MlMCbiXdbWCJq9PsuL9zEBwJ+4LUQwn6BjWO/0pQ05iv
gNsUeZiG2YfepjrH0ZJTjaJ89JESQThpjvwi1F/4e7ZuVQuYaRxHhV6nsSVJ9c3p
rjk0kD++sT3esvxd9KK/B64DhNov5rl4lzMLcMmBrmB8YgL+G832steTFXWBABEB
AAGwAYe0IFRpZXJubyBTLiBCYWggPHRpZXJub2pvQGhpcy5jb20+sAED
=ZPmR
-----END PGP PUBLIC KEY BLOCK-----
Received: from ietf.org by ietf.org id aa03211; 7 Nov 96 17:29 EST
Received: from vm.biu.ac.il by ietf.org id aa03141; 7 Nov 96 17:28 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 1507; Thu, 07 Nov 96 22:23:37 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 3015; Thu, 7 Nov 1996 22:23:38 +0200
Date: Thu, 07 Nov 96 22:20:11 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: Re: The cartel begins to crumble?
To: karl at mcs.net, Hank Nussbacher <HANK at taunivm.tau.ac.il>
cc: ietf at ietf.org
In-Reply-To: Message of Thu, 7 Nov 1996 14:04:54 -0600 (CST) from
<karl at Mcs.Net>
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611071728.aa03141 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
On Thu, 7 Nov 1996 14:04:54 -0600 (CST) you said:
>(1) You have to have operational nameservers for the domain you are
> requesting. That is ALREADY a requirement of many of the eDNS
> registries (ours included). The check for those authoritative NS
> lines is automatic.
>
> We have stopped *hundreds* of attempted grabs in the eDNS tlds we
> run ALREADY, and doing so took no manpower. The computer did the
> work for us.
So you discriminate between those with the technical knowledge
to be able to set up a NS and add a few SOAs vs those who don't
have a clue and simply call up and want to grab a name?
>
>(2) You have to pay (presumably) for the registrations you file. This
> is a check and balance in and of itself.
$50 per domain is nothing for a valuable DN.
Hank
Received: from ietf.org by ietf.org id aa04472; 7 Nov 96 17:46 EST
Received: from ietf.org by ietf.org id aa03925; 7 Nov 96 17:40 EST
To: IETF-Announce: ;
Subject: 37th IETF - List of Registered Attendees
Date: Thu, 07 Nov 1996 17:40:12 -0500
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9611071740.aa03925 at ietf.org>
*******Early Registration Cut-off is TOMORROW, Friday, November 8, 1996*****
If you register ON or BEFORE November 8, your registration fee will
be $250.00, if you register AFTER November 8, your registration fee
will be $270.00.
The following is a list of registered attendees as of Thursday,
November 7 at 5:00pm (EST).
1 Aboba, Bernard Microsoft Corporation
2 Adam, Daniel Microsoft Corporation
3 Adams, Robert Cisco Systems
4 Agbleze, Mawuse FTP Software, Inc.
5 Ahmed, Masuma Terayon Corporation
6 Ahuja, Ratinder Cisco Systems
7 Aibara, Reiji Hiroshima University
8 Alaettinoglu, Cengiz Information Sciences Institute
9 Alden, Roland
10 Alexander, Steve Silicon Graphics, Inc.
11 Allen, Edward Bay Networks, Inc.
12 Allen, Jeff Bunyip Information Systems
13 Allen, Terry Fujitsu Software Corp.
14 Allocchio, Claudio National Institute for Nuclear Physics, Italy
15 Almes, Guy Advanced Network and Services, Inc.
16 Alterman, Louise Lucent Technologies
17 Amano, Akira Hiroshima City University
18 Ambler, Christopher Image Online Design, Inc.
19 Amidon, Keith Hewlett-Packard
20 Anatov, Vadim Pluris, Inc.
21 Andersson, Loa Eriksson
22 Angelopoulos, Spiros Sterling Software
23 Aprille, Thomas Lucent Technologies, Bell Laboratories
24 Arango, Jesus Supernet S.A.
25 Ariaans, J.L. Unisource Business Networks Netherlands B.V.
26 Armitage, Grenville Bellcore
27 Armstrong, Susie Qualcomm Inc.
28 Arneson, David Digital
29 Aronson, Jules National Library of Medicine
30 Arunkumar, Nagaraj 3Com Corporation
31 Asano, Kazuo Fujitsu Laboratories Ltd.
32 Aspinwall, Russell Calyx UK Ltd.
33 Atkinson, Randall Cisco Systems
34 Audet, Francois Nortel
35 Auerbach, Karl Precept Software, Inc.
36 Austein, Robert Epilogue Technology Corporation
37 Back, Nigel BT Laboratories
38 Bailey, Chase Cisco Systems
39 Bailey, Ed IBM Corporation
40 Baker, Fred cisco Systems
41 Bakker, Steven DANTE
42 Balenson, David Trusted Information Systems
43 Bannister, Joseph USC/ISI
44 Bantel, Richard Lucent Technologies
45 Bare, Ballard Hewlett-Packard
46 Barnes, Jim Bay Networks
47 Barrett, Alan UUNET Internet Africa
48 Bates, Tony Cisco Systems
49 Bathina, Raghu Trancell Systems, Inc.
50 Beaulieu, Marcia Corporation for National Research Initiatives
51 Bedell, J. Patrick
52 Behrle, Jeremy Cisco Systems
53 Bellovin, Steven AT&T Research
54 Berger, Lou FORE Systems
55 Berkhout, Vincent DANTE
56 Bernardi, Marco CSELT
57 Berson, Steven Information Sciences Institute
58 Beyer, Mark Netmanage, Inc.
59 Bhoajaraj, Sandya Hewlett-Packard
60 Bhogavilli, Suresh Information Sciences Institute
61 Bierman, Andy Cisco Systems, Inc.
62 Billau, Roger Re/Spec Inc.
63 Binder, Richard Corporation for National Research Initiatives
64 Bird, Lester Novell, Inc.
65 Blake, Steven IBM Corporation
66 Blanchet, Marc Viagenie inc.
67 Blondel, P.F.C. S.A.R.A.
68 Blumenthal, Uri IBM Corporation
69 Bolot, Jean-Chrysostome INRIA Sophia Antipolis
70 Borden, Marty Bay Networks, Inc.
71 Borinski, Stan Realogic, Inc.
72 Borman, David Berkeley Software Design, Inc.
73 Boroumand, Javad USC-ISI
74 Boroumand, Sepideh NASA GSFC/HSTX
75 Bos, Erik-Jan SURFnet bv
76 Bosch, Brad Computer Associates
77 Boudreaux, John Daleen Technologies, Inc.
78 Boulianne, Luc McGill University
79 Bound, Jim Digital Equipment Corporation
80 Bowen, Rich NetEdge Systems, Inc.
81 Boyle, Jim The MITRE Corporation
82 Braden, Robert Information Sciences Institute
83 Bradescu, Roxana Sun Microsystems, Inc.
84 Bradner, Scott Harvard University
85 Breed, Charles Pretty Good Privacy, Inc.
86 Breslau, Lee Xerox PARC
87 Briceno, Marc DigiCash, Inc.
88 Bridgham, David Epilogue Technology Corporation
89 Brim, Scott Cornell University
90 Brochu, Alain Plaintree Systems
91 Brockners, Frank University of Cologne - ZPR
92 Brody, Lawrence AT&T
93 Brown, Anne Nortel Technology
94 Brown Klinger, Sheila Lucent Technologies
95 Brownlee, Nevil University of Auckland
96 Buchko, Steven Newbridge Networks Inc.
97 Buclin, Bertrand AT&T International
98 Burgan, Jeffrey Bay Networks, Inc.
99 Burke, Robert NetSpeed
100 Burle, Marlene Conferon, Incorporated
101 Bush, Randy NSRC
102 Cabeca, Linda Bay Networks, Inc.
103 Cai, Yiqun Northern Telecom
104 Cain, Patrick BBN Corporation
105 Cajano, Alessandro Telecom Italia
106 Calcari, Susan InterNIC/University of Wisconsin
107 Calhoun, Pat US Robotics Access Corporation
108 Callaghan, Brent Sun Microsystems, Inc.
109 Callon, Ross Cascade Communications
110 Calvert, Kenneth Georgia Institute of Technology
111 Cansever, Derya GTE Laboratories, Inc.
112 Caradec, Jean-Philippe Hewlett-Packard France
113 Card, James Nokia Telecommunications
114 Carlos, Sennen Network General Corporation
115 Carlson, John University of Washington
116 Carlson, Richard Argonne National Laboratory
117 Carney, Michael Sun Microsystems, Inc.
118 Carpenter, Brian CERN
119 Carrel, David Cisco Systems
120 Carter, Stephen Novell, Inc.
121 Carugo, Marco CNET France Telecom
122 Casner, Stephen Precept Software, Inc.
123 Caswell, Peter US Robotics
124 Cerveny, William Advanced Network and Services, Inc.
125 Chambliss, Warren Hewlett-Packard
126 Chandika, Naga Apple Computer
127 Chang, Shu-jen NIST
128 Chang, Sunny Apple Computer
129 Chefurka, Paul Plaintree Systems Inc.
130 Chen, Yao-Min Fujitsu Laboratories of America
131 Cherenson, Andrew Liquid Audio, Inc.
132 Chiotasso, Chris BGS Systems, Inc.
133 Chiu, Alex Sun Microsystems
134 Cho, Young-So E.T.R.I.
135 Chokhani, Santosh CynaCom Solutions, Inc.
136 Chon, Kilnam KAIST
137 Chong Fong, Yoshiko Asia Pacific Network Information Center
138 Choresh, Eyal LanOptics Ltd.
139 Chow, Jeff AMD
140 Christy, Greg Cisco Systems
141 Chu, H. K. Jerry SunSoft
142 Chung, Shiyun Fujitsu Business Communication Systems
143 Civanlar, Reha AT&T Research
144 Clark, Cynthia Corporation for National Research Initiatives
145 Clark, David Massachusetts Institute of Technology
146 Clark, Henry BBN Corporation
147 Clauberg, Axel University of Cologne
148 Clement, Taryn NCCOSC, San Diego
149 Cobo, Luis Pontificia Universidad Catolica del Peru
150 Cohen, Danny Myricom, Inc.
151 Cohen, Josh Netscape Communications
152 Cole, Robert Hewlett-Packard Laboratories
153 Colella, Richard America Online
154 Collins, John Rutgers University Computing Services
155 Comay, David Sun Microsystems, Inc.
156 Compton, Kip Continental Cablevision, Inc.
157 Conklin, Jim CREN
158 Cook, Gordon Cook Report on Internet
159 Copeland, Ken U.S. Dept. of Veterans Affairs
160 Corbato, Steven University of Washington
161 Corson, Scott University of Maryland
162 Corwin, BPS Inc.
163 Coya, Stephen Corporation for National Research Initiatives
164 Craren, Michael 3COM
165 Crawford, Matt Fermilab
166 Crawley, Eric Bay Networks, Inc.
167 Crowe, David NERO Network
168 Curran, John BBN Corporation
169 Curtin, Bill DISA
170 Dabbous, Walid INRIA
171 Dacuycuy, LaVergne Fujitsu Business Communication Systems
172 Daigle, Leslie Bunyip Information Systems
173 Dam, Tru Network Systems Corporation
174 Dang, Winston University of Hawaii
175 Daniel, Ron Los Alamos National Laboratory
176 Daoud, Edward Fujitsu
177 Davie, Bruce Cisco Systems
178 Dawkins, Spencer Nortel
179 de la Salle, Pierre Compuware
180 De Winter, Jack Wildbear Consulting, Inc.
181 Del Torto, Dave PGP, Inc.
182 Delagi, Bruce Apple Computer, Inc.
183 DeMatteis, Cheryl The Aerospace Corporation
184 Demirtjis, Ann Sprint
185 Demizu, Noritoshi Sony Computer Science Lab, Inc
186 Dinha, Francis NewCom Technologies,Inc.
187 Diot, Christophe INRIA
188 Dittler, Hans Braintec Network Consulting
189 Doi, Yuusuke KEIO University
190 Donelan, Sean Data Research Associates, Inc.
191 Donner, Paul
192 Doraswamy, Naganand FTP Software, Inc.
193 Dosedal, Anke Cisco Systems
194 Doyle, Robert Berkeley Networks
195 Dreyer, Jon Sun Microsystems
196 Droms, Ralph Bucknell University
197 Droz, Patrick IBM Research Laboratory
198 Dumitru, Don Microsoft Corporation
199 Duncan, Ian Newbridge Networks Inc.
200 Duniho, Michael National Security Agency
201 Dunn, Jeffrey Hewlett-Packard
202 Dunstan, Adam Bay Networks, Inc.
203 Dupont, Francis INRIA Rocquencourt
204 Durand, Alain Institut de Mathmatiques Appliquees de Grenoble
205 Duros, Emmanuel INRIA
206 Dyer, John Terena
207 Earhart, Rob Carnegie Mellon University
208 Eastlake, Donald CyberCash, Inc.
209 Eisler, Mike Sun Soft Inc.
210 Elkins, Michael Trusted Information Systems, Inc.
211 Ellehauge, Peter Dansk Data Elektronik A/S
212 Ellerbee, Jeff ichat Inc.
213 Ellesson, Ed IBM Corporation
214 Ellis, Gehrett Corporation for National Research Initiatives
215 Elz, Robert University of Melbourne
216 Emery, Nick AltaVista Internet Software
217 Engel, David Optical Data Systems, Inc.
218 England, Kent Six Sigma Networks
219 Erickson, Rodger Wall Data
220 Eriksson, Johnny KTHNOC
221 Erlinger, Michael The Aerospace Corporation
222 Estrin, Deborah Information Sciences Institute
223 Fair, Erik Apple Computer, Inc.
224 Fajman, Roger National Institutes of Health
225 Falk, Bennett Sybase
226 Fang, Hsin National Institute of Standards and Technology
227 Farinacci, Dino Cisco Systems, Inc.
228 Fasano, Paolo CSELT
229 Faynberg, Igor Lucent Technologies
230 Ferenz, David Price Waterhouse LLC
231 Ferguson, Dennis Juniper Networks
232 Ferguson, Paul Cisco Systems
233 Fernandez, Antonio Bellcore
234 Ferracin, Joseph SITA/ITS
235 Fink, Robert Lawrence Berkeley Laboratory
236 Finkelstein, David Xcert Software Inc.
237 Firenze, Mary NetManage, Inc.
238 Flanigan, William Defense Information Systems Agency
239 Fleshman, Michael Clearview Systems, Inc.
240 Ford, Warwick
241 Forster, James Cisco Systems
242 Forsythe, Margaret Epilogue Technology Corp.
243 Fowler, Dave Newbridge Networks Inc.
244 Fox, Barbara Microsoft Corporation
245 Fox, Craig Cisco Systems
246 Fox, Daniel Bay Networks
247 Francis, Paul NTT Software Lab
248 Frankhauser, Martine SITA
249 Fraser, Barbara CERT Coordination Center
250 Frei, Randy Com21
251 Fritz, Thomas barili systems limited
252 Fu, James Nokia Telecommunications Inc.
253 Fujikawa, Kazutoshi Boston University
254 Fujikawa, Kenji Kyoto University
255 Fukushima, Hidehiro Hitachi Ltd.
256 Fuller, Vince BBN Corporation
257 Fumeno, Takanori Telecoment Inc.
258 Furuseth, Hallvard University of Oslo
259 Gadre, Jay Bell Atlantic
260 Gahrns, Mike Microsoft Corporation
261 Galvin, James CommerceNet
262 Ganguly, Anik Campbell Services Inc.
263 Garcia, Francisco Hewlett-Packard Laboratories
264 Garrett, Mark Bellcore
265 Gastonde, Sunil Cisco Systems
266 Gilliam, William Hewlett-Packard
267 Gilmore, John Electronic Frontier Foundation
268 Girod, Lewis Massachusetts Institute of Technology
269 Glass, Steven FTP Software, Inc.
270 Glatting, Dennis CyberSafe Corporation
271 Goel, Vab Sprint
272 Goland, Yaron Microsoft
273 Gold, Harry NCCOSC
274 Goldsmith, Eric Applied Innovation, Inc.
275 Goller, Sean Carnegie Mellon University
276 Golshan, Ali 3Com Corporation
277 Gonzalez, Ricardo Hypertech Corporation
278 Gorden, Bengt KTHNOC
279 Goto, Yukinori Institute of Systems & Information Technology
280 Govindan, Ramesh Information Sciences Institute
281 Goyal, Mukul Sun Microsystems, Inc.
282 Gray, Eric
283 Gray, Terry University of Washington
284 Greene, Barry Cisco Systems
285 Greene, Jeremy Xedia Corporation
286 Greene, Maria Ascom Nexion, Inc.
287 Grill, Thomas E-Systems
288 Gudmundsson, Olafur Trusted Information Systems
289 Gupta, Rajeev Trillium Digital Systems, Inc.
290 Gupta, Vipul Sun Microsystems, Inc.
291 Gurajapu, Suresh Trancell Systems, Inc.
292 Haller, Neil Bellcore
293 Halpern, Joel Newbridge Networks Inc.
294 Halpin, James U.S. Robotics
295 Hambridge, Sally Intel Corporation
296 Hamilton, Martin University of Technology, Loughborough
297 Handelman, Sigmund IBM Corporation
298 Haney, Craig Cando Consulting
299 Hanna, Donal Netskills
300 Hansen, Karen Ohio University
301 Hardie, Ted NASA Science Internet
302 Harrington, Dan Lucent Technologies
303 Harrison, Sari Apple Computer Inc.
304 Hasegawa, Yusaku Nara Institute of Science & Technology
305 Haskin, Dimitry Bay Networks, Inc.
306 Hawkinson, John BBN Planet
307 Heard, C.M. VVNET, Inc.
308 Hedberg, Roland SUNET
309 Heffernan, Andy cisco Systems
310 Heffner, Wendy U.C. Berkeley
311 Heidemann, John USC/ISI
312 Hernacki, Brian Netscape Communications, Inc.
313 Herron, Andrew Microsoft Corporation
314 Herzog, Shai IBM
315 Hetzel, Dorn HLC/Epoch Networks
316 Hien, Nguyen IBM Corporation
317 Hildenbrand, Bruce Sun Microsystems
318 Hilton, Rhonda Cable Television Laboratories
319 Hinden, Robert Ipsilon Networks, Inc.
320 Hirabaru, Masaki Merit Network, Inc.
321 Hirai, Chiaki Hitachi Ltd.
322 Hobby, Russ University of California, Davis
323 Hoffman, Don Sun Microsystems, Inc.
324 Hoffman, Paul Internet Mail Consortium
325 Hofmann, Jeanette WZB
326 Holcomb, Jeff Apple Computer, Inc.
327 Holdrege, Matt Ascend Communications
328 Hole, Steve The Esys Corporation
329 Holmstead, Stephen Hewlett Packard
330 Honce, Jhon Hughes STX
331 Honnur, Virupaksh Cisco Systems
332 Hopkins, Gerry Bell Atlantic
333 Hopprich, John Cisco Systems
334 Hornby, Peter Unisys Corporation
335 Horneffer, Martin University of Cologne
336 Horowitz, Marc Cygnus Support
337 Hoschka, Philipp INRIA-Rodeo
338 Hosein, Javed Bay Networks, Inc.
339 Hoshi, Tohru Hitachi, Ltd.
340 Huang, Chia-Li Nokia Telecommunications
341 Huber, Rick AT&T Bell Laboratories InterNIC
342 Huddle, Scott MCI Telecommunications Corporation
343 Huitema, Christian Bellcore
344 Huizer, Erik SURFnet Expertise Center
345 Hunt, Bill VPNet Technologies, Inc.
346 Hur, Matt Cyber Safe Corporation
347 Huss, Claude Matsushita Electric Works US R&D Laboratories
348 Huston, Geoff Telstra
349 Hyman, Marco
350 Ilgun, Koral Advanced Computer Communications
351 Inbar, Ofer The Left Bank Operation, Inc.
352 Inoue, Takash Furukawa Electric Technologies
353 Inoue, Yoshinobu Fujitsu Laboratories Ltd.
354 Irlam, Gordon Cygnus Support
355 Ishiguro, Kunihiro DML
356 Ishiyama, Masahiro Toshiba Corporation
357 Iuso, Francesco Telecom Italia
358 Iversen, Ruben Dan Net
359 Iwata, Atsushi NEC Corporation
360 Jackowski, Steven NetManage, Inc.
361 Jacobs, Stuart GTE Laboratories
362 Jacobsen, Ole ConneXions
363 Jennings, Barbara Sandia National Laboratories
364 Jensen, Del Novell, Inc.
365 Jiang, Jonathan Bellcore
366 Jinzenji, Hiroshi NTT Human Interface Labs
367 Johnson, Jeff Cisco Systems
368 Johnson, Keith Federal Express Corporation
369 Johnson, Richard Cisco Systems
370 Johnson, Terry Develcon Electronics Ltd.
371 Johnson, Tony Network Systems Corporation
372 Jokubaitis, Vito AT&T
373 Jones, Ken Bay Networks, Inc.
374 Jork, Markus Digital Equipment GmbH
375 Joseph, Mark Attachmate Corporation
376 Juliano, Bryan NASA/Ames
377 Kaat, Marijke SURFnet Expertise Center
378 Kalbfleisch, Carl On-Ramp Technologies, Inc.
379 Kalra, Sanjay Cisco Systems
380 Kapil, Vivek Nortel Technology
381 Kapur, Arun Quadritek Systems, Inc.
382 Kashima, Hiroaki Fujitsu Ltd.
383 Kassi-Lahlou, Mohammed France Telecom
384 Kastenholz, Frank FTP Software, Inc.
385 Kato, Akira The University of Tokyo Computer Center
386 Katsube, Yasuhiro Toshiba Corporation
387 Kaufman, Charlie Iris Associates
388 Kawano, Tetsuo NTT Software Laboratories
389 Kellenbenz, Jerry Apple Computer, Inc.
390 Kemp, David National Security Agency
391 Kennedy, John Novell Inc.
392 Kennedy, L. Sean BBN Corporation
393 Kent, Stephen BBN Corporation
394 Kermode, Roger MIT Media Lab
395 Kern, Ed DIGEX
396 Keromytis, Angelos University of Pennsylvania
397 Kessens, David USC/ISI
398 Key, Kenneth Cisco Systems
399 Khalsa, Kirpal Lotus ccMail
400 Khare, Rohit W3 Consortium
401 Kim, Charlie Apple Computer, Inc.
402 Kim, Dae Sik ETRI
403 Kim, David Apple Computer
404 Kim, Dorian CICNet, Inc.
405 Kim, Hyogon Bellcore
406 Kim, Young-kyun National Computerization Agency
407 Kirani, Shekhar Starfish Software
408 Kirchhoff, Julie Corporation for National Research Initiatives
409 Kirstein, Peter University College London
410 Kiyoshima, Naoki Ultra-high Speed Network & Computer Tech. Labs.
411 Klensin, John MCI Telecommunications Corporation
412 Knuutila, Timo Nokia Research Center
413 Kobayashi, Masayuki CSR co., Ltd.
414 Koch, Harald Secure Computing Canada Ltd.
415 Koester, Greg Bay Networks
416 Komiya, Masakatsu Japan Satellite Systems Inc.
417 Kondo, Kuniaki Dream Train Inernet, Inc.
418 Kopsa, Ray Cygnet
419 Korver, Brian Terisa Systems, Inc.
420 Koskelainen, Petri Nokia Research Center
421 Kosters, Mark InterNIC
422 Krawczyk, John Bay Networks, Inc.
423 Krechmer, Ken Action Consulting
424 Kristol, David Lucent Technologies, Bell Laboratories
425 Krol, Edward University of Illinois Urbana
426 Krupczak, Cheryl Empire Technologies, Inc.
427 Kuang, Fidelia Apple Computer Inc.
428 Kuehne, Mirjam RIPE NCC
429 Kumar, Sanjay First Virtual Corporation
430 Kumar, Vinay ICAST Communications, Inc.
431 Kumarasamy, Jay Novell, Inc.
432 Kunze, John UCSF Center for Knowledge Management
433 Kurakami, Hiroshi NTT Multimedia Networks Labs
434 Kurn, David Tandem Computers Inc.
435 Kuroda, Yasutsugu Fujutsu Laboratory Ltd.
436 Kwan, Stuart Microsoft Corporation
437 Kwan, William Jupiter Technology, Inc.
438 Lahey, Kevin NASA/Ames Research Center
439 Lamond, Keith British Telecom North America
440 Lang, Ruth SRI International
441 Langeveld, Henk Sun Microsystems
442 Langlois, Sylvain Electricite de France
443 Lanphier, Rob Progressive Networks
444 Larsson, Jorgen Telia AB
445 Lasker, Valerie Precept Software, Inc.
446 Latzko, Alex Rutgers University Computing Services
447 LaVange, Don Novell, Inc.
448 Laviano, Vincent George Mason University
449 Lavu, Lava George Mason University
450 Lawler, John VPNet Technologies, Inc.
451 Lear, Eliot Silicon Graphics, Inc.
452 Lechner, Mikel NEC Technologies
453 Lee, C.J. Novell, Inc.
454 Lee, Dongho Kwangwoon University
455 Lee, WeeSan USC/ISI
456 Leech, Marcus Nortel Technology
457 Leinen, Simon SWITCH
458 Lemaire, Thomas 3Com Corporation
459 Lenggenhager, Thomas SWITCH
460 Lenharth, William University of New Hampshire
461 Leong, Ivan Pacific Internet Pte. Ltd.
462 Leroy, David FORE Systems
463 Leu, Brian Semaphore Communications Corp.
464 LeValley, Jim Macmillan Technical Publishing
465 Levi, Steven Microsoft Corporation
466 Levinson, Ed XIson, Inc.
467 Lewis, Edward Trusted Information System
468 Li, Hongqing Lucent Technologies
469 Li, Jian Sprint
470 Li, Tony Juniper Networks Inc.
471 Li, Yan-Fa Hewlett-Packard
472 Liau, Wendy Oracle Corporation
473 Lichtensteiger, Reto Mitsubishi Electric ITA
474 Lim, Koon Sang Logic Group of Companies
475 Ling, Lin SunSoft
476 Ling, Wenken Bay Networks, Inc.
477 Linn, John OpenVision Technologies
478 Liu, Eric Cable & Wireless
479 Liu, Yuan-Kwei NASA Ames Research Center
480 Lord, Anne UUNET PIPEX
481 Love, E. Paul Internet Consulting of Vermont
482 Lu, Hui-Lan Lucent Technologies
483 Lu, Vivian NetEdge Systems, Inc.
484 Luciani, James Bay Networks, Inc.
485 Lund, Craig Mercury Computer Systems, Inc.
486 Lundblade, Laurence Qualcomm Inc.
487 Luotonen, Ari Netscape Communications
488 Lutz, Raymond Cognisys Inc.
489 Macker, Joseph US Naval Research Laboratory
490 Mader, Keith Bay Networks, Inc.
491 Madison, Eric ACSI
492 Maeda, Kaori Hiroshima City University
493 Mahdavi, Jamshid Pittsburgh Supercomputing Center
494 Maher, Maryann USC/ISI
495 Malamud, Carl MIT Media Lab
496 Malcolm, Andrew SCO
497 Malis, Andrew Ascom Nexion, Inc.
498 Malkin, Gary Bay Networks
499 Mallory, Tracy 3Com Corporation
500 Mamros, Shawn FTP Software, Inc.
501 Mankin, Allison Information Sciences Institute
502 Mannie, Eric Brussels University
503 Manning, Bill Information Sciences Institute
504 Marine, April NASA NIC
505 Markham, Tom Secure Computing Corp.
506 Marsh, Ian Swedish Institute of Computer Science
507 Martillo, Joachim Telford Tools, Inc.
508 Martin, Antony DRA
509 Martin, Cynthia Defense Information Systems Agency
510 Martin, John TERENA
511 Maruyama, Mitsuru NTT Software Laboratories
512 Masinter, Larry Xerox Corporation
513 Maston, Michael Cisco Systems
514 Mather, Tim Apple Computer
515 Mathis, Matt Pittsburgh Supercomputing Center
516 Matsuhira, Naoki Fujitsu Laboratories Ltd.
517 Matsukata, Jun National Center for Science Information Systems
518 Matsune, Mio Network Information Service Co
519 Matsushita, Nobuo Bell Labs, Lucent Technologies
520 Maughan, Douglas National Security Agency
521 Maw, Tim Stentor Resource Centre Inc.
522 Maxham, Mark Apple Computer, Inc.
523 Mazzucato, Sandro Bunyip Information Systems
524 McBurnett, Neal Lucent Technologies, Bell Labs
525 McCann, Jack Digital Equipment Corporation
526 McCloghrie, Keith cisco Systems
527 McCollum, Bob SAIC
528 McCooey, Jeremy University of New Hampshire
529 McDonald, Daniel Sun Microsystems, Inc.
530 McGarvey, John IBM
531 McManis, Chuck Free Gate Corporation
532 McMaster, Donna Cisco Systems
533 McMillan, Tom 3Com Primary Access
534 McPherson, Danny MCI Telecommunications Corporation
535 Mealling, Michael Network Solutions, Inc.
536 Medrinsky, Ari Cyber Safe Corporation
537 Medued, Patrick Computer Associates
538 Mehta, Mehul Apple Computer
539 Mende, Robert Silicon Graphics, Inc.
540 Merchant, Shashank Advanced Micro Devices
541 Metzger, Perry Piermont Information Systems
542 Meyer, David University of Oregon
543 Meyer, Gerry Shiva Limited
544 Miller, Quentin Microsoft Corporation
545 Miller, Thomas Siemens
546 Miller, W. Marcus Lawrence Livermore National Labs
547 Millington, Linda Control Data Systems, Inc.
548 Mills, Cynthia GTE Laboratories, Inc.
549 Milnes, Brian Lycos, Inc.
550 Minami, Masaki Keio University
551 Minshall, Greg Ipsilon Networks, Inc.
552 Mistry, Danny Nortel Technology
553 Moats, Ryan AT&T Bell Laboratories InterNIC
554 Mogul, Jeffrey Digital Equipment Corporation
555 Mohta, Pushpendra CERFnet
556 Monsour, Robert Hi/fn, Inc.
557 Montenegro, Gabriel Sun Microsystems, Inc.
558 Moore, Keith University of Tennessee
559 Moore, Mike Hewlett-Packard
560 Moore, Richard Michigan State University
561 Moore, Robert IBM Corporation
562 Morgan, Bob Stanford University
563 Morla, Kim Pontificia Universidad Catolica del Peru
564 Morris, David barili systems limited
565 Morris, Jonathan Manchester Metropolitan University
566 Morse Johnson, Kelly Cisco Systems
567 Moscaritolo, Vinnie Apple Computer
568 Moskowitz, Robert Chrysler Corporation
569 Mouradian, George AT&T Laboratories
570 Moy, Diana U.S. Robotics
571 Moy, John Cascade Communications Corporation
572 Muller, Claude Hewlett-Packard Laboratories
573 Mundy, Russ Trusted Information Systems
574 Murai, Jun Keio University
575 Murphy, Patrick U.S. Geological Survey
576 Murphy, Sandra Trusted Information Systems
577 Murray, Cecil Campbell Services Inc.
578 Mutz, Andrew Hewlett-Packard
579 Myers, John Carnegie Mellon University
580 Myjak, Michael University of Central Florida
581 Na, Jung-jung National Computerization Agency
582 Nagami, Ken-ichi Toshiba Corporation
583 Nahm, Stephen Sun Microsystems, Inc.
584 Nakamura, Osamu Keio University
585 Napjus, Erikas Carnegie Mellon University
586 Narayan, Vishy NASA Ames Research Center
587 Narayana, Raj Cable & Wireless
588 Narten, Thomas IBM Corporation
589 Nassi, Ike AppleSoft
590 Natale, Bob American Computer and Electronics Corporation
591 Neely, W. Shields National Semiconductor
592 Neer, Merle NRaD
593 Nelson, JoAnn NASA Science Internet
594 Nemeth, Evi University of Colorado
595 Nerenberg, Lyndon The Esys Corporation
596 Nesser, Philip Nesser & Nesser Consulting
597 Nessett, Dan 3Com Corporation
598 Neuman, Clifford Information Sciences Institute
599 Newman, Chris Innosoft International, Inc.
600 Ng, Fo Hong Kong Supernet
601 Nguyen, Hai Raytheon E-Systems
602 Niazi, S. Chin Apple Computer Inc.
603 Nicklass, Orly RAD Data Communications
604 Nicklow, Doug Lycos, Inc.
605 Nielsen, Henrik World Wide Web Consortium
606 Niinomi, Tadafusa Fujitsu Laboratories Ltd.
607 Nikander, Pekka
608 Nishida, Takeshi NEC USA
609 Noerenberg, John Qualcomm Inc.
610 Nowicki, William Silicon Graphics, Inc.
611 O'Leary, David Cisco Systems
612 O'Leary, Peter Clear Blue Network Systems, Inc.
613 Obraczka, Katia USC/ISI
614 Oehler, Michael National Security Agency
615 Ogawa, Jun Fujitsu Lab.
616 Ohta, Masataka Tokyo Institute of Technology
617 Okamoto, Toshio Toshiba Corporation
618 Onishi, Steven Bay Networks, Inc.
619 Ooka, Toshio Sumitomo Electric USA, Inc.
620 Oran, David Cisco Systems
621 Ordille, Joann Bell Labs, Lucent Technologies
622 Orman, Hilarie DARPA/ITO
623 Ostrowski, Stephen 3Com
624 Overby, Mary UNC-CH
625 Ozaki, Satoshi Toshiba Corporation
626 Paez-Ramirez, Alonso BT Labs
627 Pang, Joseph Starlight Networks
628 Pareth, Sameer C2Net
629 Paridaens, Oliver Universite Libre de Bruxelles
630 Parker, Steve SunSoft, Inc.
631 Partan, Andrew WNA
632 Partington, Heath US Robotics Inc.
633 Patrick, Michael Motorola ISG
634 Patton, Michael
635 Perkins, Charles IBM Corporation
636 Perkins, Colin University College London
637 Perlman, Radia Novell, Inc.
638 Petke, Richard CompuServe, Inc.
639 Petronelli, Paul PALM Associates, Inc.
640 Pfenning, Thomas Microsoft Corporation
641 Picoto, Carlos University of Lisbon
642 Pierce, Greg Network Solutions, Inc.
643 Pilger, Alexander Siemens AG
644 Pink, Stephen Swedish Institute of Computer Science
645 Piper, Derrell Cisco Systems
646 Plzak, Ray SAIC
647 Postel, Jon Information Sciences Institute
648 Presuhn, Randy BMC Software, Inc.
649 Prior, Mark connect.com.au pty ltd
650 Pullen, J. Mark C3I Center
651 Pusateri, Tom Juniper Networks
652 Rabin, Tal IBM
653 Raghu, Jagannath Shomiti Systems, Inc.
654 Rajagopalan, Bala Bellcore
655 Rajagopal, Murali Fujitsu
656 Ramalingam, Jayakumar Novell, Inc.
657 Ramanan, P.S. Sprint Corporation
658 Randall, Karen AT&T Universal Card Services Corporation
659 Rank, Edward Bay Networks
660 Ravikanth, Ravadurgam Nokia Research Center
661 Ray, Cathe Sun Microsystems, Inc.
662 Reed, Benjamin IBM Corporation
663 Reeder, David Portland State University
664 Reitsma, Rob Unisource Business Networks
665 Rekhter, Yakov Cisco Systems
666 Renwick, John Ascend Communications
667 Rescorla, Eric Terisa Systems, Inc.
668 Resnick, Pete Qualcomm Inc.
669 Rex, Martin SAP AG
670 Reynolds, Joyce K. Information Sciences Institute
671 Richard, Pat Xcert Software Inc.
672 Richardson, John Intel Corporation
673 Rickard Bollentin, WendyOnTheInternet Magazine
674 Ridenour, Howard Apple Computer Inc.
675 Riordan, John Swiss Telecom
676 Robinson, David Sun Microsystems, Inc.
677 Rodney, Steve Racal - Datacom
678 Rogerson, Duncan University of London
679 Romanow, Allyn Sun Microsystems, Inc.
680 Romkey, John Blue Forest Research
681 Ronen, Elazar Radlinx Ltd.
682 Roque Marques, Pedro Universidade de Lisboa
683 Rose, Marshall T. First Virtual Holdings Inc.
684 Roselinsky, Milt Advanced Computer Communications
685 Rossen, Ken MCI Systemhouse
686 Routhier, Shawn Epilogue Technology Corporation
687 Royce, Kathy Bay Networks, Inc.
688 Ruth, Greg GTE Laboratories, Inc.
689 Rutkowski, Anthony General Magic, Inc.
690 Ryan, Gerard Bell Labs
691 Ryutov, Tatyana USC/ISI
692 Saito, Takeshi Toshiba Corporation
693 Sakamoto, Hiromitsu NEC Corporation
694 Sales, Bernard Alcatel Telecom
695 Salo, Timothy Minnesota Supercomputer Center
696 Salomon, Marc University of California
697 Samanick, John Defense Information Systems Agency
698 Samberg, Larry Maker Communications
699 Sandick, Hal IBM Corporation
700 Saperia, Jon BGS Systems, Inc.
701 Sarkezians, Hasmik US Robotics
702 Sarmiento, Ramiro Sun Microsystems, Inc.
703 Sawyer, Wilson Bay Networks/LANcity
704 Scano, John 3Com
705 Schertler, Mark Terisa Systems
706 Schey, John Europay International
707 Schiller, Jeffrey Massachusetts Institute of Technology
708 Schmechel, Christopher Sun Microsystems, Inc.
709 Schneider, Mark National Security Agency
710 Schneider, Wolfgang GMD
711 Schnell, Steven Sprint Government Systems Division
712 Scholl, Reinhard Siemens AG
713 Schulman, Martin Cisco Systems
714 Scott, Gregor Defense Information Systems Agency
715 Sedayao, Jeff Intel Corporation
716 Seto, Koichiro Hitachi Cable
717 Shand, Mike Digital Equipment Co. Ltd.
718 Shew, Stephen Nortel Technology
719 Shieh, Shuching Bay Networks, Inc.
720 Shimojo, Shinji Osaka University Computer Center
721 Shionozaki, Atsushi Sony Computer Science Laboratory
722 Shirey, Rob BBN Corporation
723 Shirley, Fred Sanders
724 Shmulevsky, Mark ADP, Inc.
725 Shobatake, Yasuro Toshiba Corporation
726 Sikora, John AT&T Bell Laboratories
727 Siller, Curtis Lucent Technologies
728 Simpson, William Computer Systems Consulting Services
729 Singh, Jasdip InterNIC
730 Sloane, Timon timonWare Inc.
731 Smith, Andrew NeoSoft, Inc.
732 Smith, Carl Sun Microsystems, Inc.
733 Smith, Michael TIAA-CREF
734 Smith, Philip UUNET PIPEX
735 Smith, Timothy IBM Corporation
736 So, Benny Novell, Inc.
737 Solensky, Frank FTP Software, Inc.
738 Sollins, Karen Massachusetts Institute of Technology
739 Solo, Dave BBN Corporation
740 Solomon, Jim Motorola
741 Sommerfeld, Bill Hewlett-Packard
742 Spatscheck, Oliver University of Arizona
743 Speer, Michael Sun Microsystems, Inc.
744 Spell, Charlie Cisco Systems
745 Spreitzer, Mike Xerox PARC
746 Sridhar, T. Future Communications Software
747 Srinivasan, Suresh Thomson Technology Services Group
748 Srinivasan, Andre Oracle Corporation
749 St. Johns, Michael @Home Network
750 Staubach, Peter Sun Microsystems, Inc.
751 Steenstrup, Martha BBN Corporation
752 Stefferud, Einar Network Management Associates
753 Stephens, Tom Microsoft Corporation
754 Stibler, Stephen IBM Corporation
755 Stockman, Bernhard Telia AB
756 Stuart, Wayne Cisco Systems
757 Sumikawa, Munechika Nara Institute of Science and Technology
758 Sumner, Mark Motorola
759 Sundell, Kenneth Ericsson Telecom AB
760 Suzuki, Muneyoshi NTT Multimedia Networks Labs
761 Swallow, George Cisco Systems
762 Swan, Matti Helsinki Telephone Company Ltd
763 Sweeney, Steven Apple Computer
764 Swink, Michael Sprint
765 Takada, Toshiaki Dream Train Internet, Inc.
766 Takamatsu, Satoshi NTT
767 Takeuchi, Shohei NEC Corporation
768 Takihiro, Masatoshi Hitachi Ltd.
769 Tallerico, David The MITRE Corporation
770 Talpade, Rajesh Georgia Institute of Technology
771 Tanaka, Kei Internet Initiative Japan Inc.
772 Tang, Cheng Hewlett-Packard
773 Taniguchi, Kunihiro NECUSA
774 Taylor, Peter Mailbase, Newcastle University
775 Tecot, Ed Apple Computer, Inc.
776 Teplitsky, Jacob Fore Systems
777 Teraoka, Fumio Sony Computer Science Laboratory, Inc.
778 Terpstra, Marten Bay Networks, Inc.
779 Tesink, Kaj Bellcore
780 Thatcher, Michael Thatcher Consulting Services
781 Thayer, Rodney Sable Technology Corporation
782 Thomas, Matt Digital Equipment Corporation
783 Thomas, Richard Nortel Technology
784 Thomas, Robert Berkeley Networks
785 Thomson, Susan Bellcore
786 Thurlow, Robert Sun Microsystems Inc.
787 Tirilok, Prem Computer Associates
788 Tomimura, Eiji Sumitome Electric USA, Inc.
789 Tominaga, Akihiro Keio University
790 Topolcic, Claudio BBN Corporation
791 Touch, Joseph USC/ISI
792 Tow, Agnes AT&T
793 Tracy, Michael Sunsoft
794 Traina, Paul Juniper Networks, Inc.
795 Tramposch, Albert World Intellectual Property Organization
796 Travis, Ward Cisco Systems
797 Trest, Mike ATMNET
798 Trostle, Jonathan CyberSafe Corporation
799 Ts'o, Theodore Massachusetts Institute of Technology
800 TSE, Hiu Wa Hong Kong Supernet Ltd.
801 Tsuchiya, Kazuaki Hitachi, Ltd.
802 Tsukada, Koji Hitachi, Ltd.
803 Tung, Brian Information Sciences Institute
804 Turaj, Nancy The MITRE Corporation
805 Turner, Randy Sharp Laboratories of America
806 Uehara, Keisuke KEIO University
807 Umeda, Masayoshi Nippon Telegraph and Telephone Corporation
808 Varnis, Harry Network Systems Corporation
809 Vaudreuil, Gregory Octel Network Services
810 Veach, Ross CICNet, Inc.
811 Veenstra, Jack AT&T
812 Vegesna, Srinivas Cisco Systems
813 Verina, Maria ICGEB
814 Verrilli, Colin IBM Corporation
815 Villanueva, Deric WRQ
816 Vinores, Cindy SunSoft
817 Vohra, Quaizar University of New Hampshire
818 von Kaenel, Juerg IBM
819 Vozza, Vincenzo Telecom Italia
820 Vu, Anh Fore Systems
821 Vu, Joseph Fore Systems
822 Vu, Trinh Secure Computing Corp.
823 Wada, Hiromi Matsushita Electric Industrial Company, Ltd.
824 Wahl, Mark Critical Angle, Inc.
825 Wall, Matt Carnegie Mellon University
826 Wallace, Dick Concord Communications, Inc.
827 Wallace, Leland Apple Computer Inc.
828 Ward, Carol NASA Ames Research Center
829 Watanabe, Ken Hitachi, Ltd.
830 Watt, James Newbridge Networks Inc.
831 Weaver, Elfed Defense Research Agency
832 Webber, Bob PictureTel Corporation
833 Weiler, Samuel Carnegie Mellon University
834 Weinrib, Abel Intel Corporation
835 Weise, Bernd DeteBerkom GmbH
836 Weiss, Howard SPARTA, Inc.
837 Wellens, Chris InterWorking Labs, Inc.
838 Wells, Amy Tracy InterNIC Net Scout
839 Wessels, Duane Nat'l Lab for Applied Netwrk Research
840 West, Jim Ciena Optical Communications
841 Whipple, Mark Octel Services
842 White, Gerry LANcity Corporation
843 White, Paul University College London
844 Wiebe, Walter Federal Networking Council
845 Williams, Carl Sun Microsystems, Inc.
846 Williamson, Scott Network Solutions, Inc.
847 Windrim, Mark Newstar Technologies
848 Winkler, Linda Argonne National Laboratory
849 Winter, Brian US Robotics Inc.
850 Won, King Network General Corp.
851 Woodcock, Bill Zocalo Engineering
852 Wright, Graham Hummingbird Communications
853 Wright, Russ Lawrence Berkeley Laboratory
854 Wroclawski, John Massachusetts Institute of Technology
855 Yamamoto, Kazuhiko Nara Institute of Science Technology
856 Yao, Kwang Hewlett-Packard
857 Yarnell, Jeff Kaspia Systems, Inc.
858 Yavatkar, Raj Intel Corporation
859 Yen, Leemay 3Com Corporation
860 Ying, Wen-Ping AT&T Wireless Services
861 Ylonen, Tatu SSH Communications Security
862 Yoshida, Shin Sumitomo Electric U.S.A., Inc.
863 Yoshida, Toshiaki Werk mikro systems, Ltd.
864 Yu, I-Hsiang GTE Laboratories Inc.
865 Zhang, Lixia UCLA
866 Zhang, Yi 3Com
867 Zhang, Zhaohui Bay Networks, Inc.
868 Zhao, Bill AT&T
869 Ziegast, Eric GTE Interactive Media
870 Ziemba, Paul Fore Systems
871 Zorn, Glen Microsoft Corporation
Received: from ietf.org by ietf.org id aa04473; 7 Nov 96 17:46 EST
Received: from ietf.org by ietf.org id aa04052; 7 Nov 96 17:42 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: ietf-rsvp at ietf.org
Subject: IETF MAILING: RSVP: December 9-13, 1996/San Jose, CA
Date: Thu, 07 Nov 1996 17:42:29 -0500
X-Orig-Sender: mbeaulie at ietf.org
Message-ID: <9611071742.aa04052 at ietf.org>
***********Early Registration cut-off is November 8, 1996***********
REGISTRATION FORM
37th Internet Engineering Task Force - Page 1 of 2
December 9-13, 1996
San Jose, California, USA
Please print or type:
Name (Mr/Dr/Ms)__________________________________________________________
Title____________________________________________________________________
Organization_____________________________________________________________
Address__________________________________________________________________
_________________________________________________________________________
City_____________________________State_____________Postal Code___________
Country__________________________________________________________________
Telephone______________________________Fax_______________________________
Email____________________________________________________________________
Do you plan to attend the Sunday, DECEMBER 8th NEWCOMER'S ORIENTATION at
1530?
YES___ NO___
Do you plan to attend the Sunday, DECEMBER 8th reception at 17:00?
YES___ NO___
The IETF Proceedings are available electronically. Would you still
like a hard copy?
YES___ NO ___
US$250.00 Registration postmarked on or BEFORE, Friday, November 8, 1996.
US$270.00 (US$250.00 + US$20.00 late fee) Registration postmarked after
Friday, November 8, 1996.
Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check
(U.S. dollars, drawn on a U.S. Bank), payable to:
Corporation for National Research Initiatives
Account No.____________________________ Expiration Date__________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: ietf-rsvp at ietf.org
Facsimile: +1-703-758-5913
Postal: Corporation for National Research Initiatives
Accounting Department - 37th IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 20191-5434 USA
REGISTRATION FORM
37th Internet Engineering Task Force - Page 2 of 2
December 9-13, 1996
San Jose, California, USA
IMPORTANT:
1. Payment MAY, but does NOT have to, accompany the Form.
2. As long as your Form is postmarked by the deadline date of
November 8, 1996, you are locked in to pay the lower registration
fee of $250.00 (e.g., send us your form via e-mail by the
deadline date and pay the $250.00 fee later via postal
mail). When paying by company check, be sure that your Accounting
Department knows that you qualified yourself for the lower rate.
3. Payment is accepted on-site.
4. Register ONE person per form. Substitutions are NOT allowed.
5. Include a completed Registration Form with payment.
6. Purchase orders are NOT accepted.
7. DD Form 1556 IS accepted.
8. We CANNOT invoice for payment.
9. Registration Forms will be accepted via electronic mail and
facsimile until 1300ET on Wednesday, December 4, 1996.
10. Requests for refunds must be received by 1700ET, Thursday,
December 5, 1996. No refunds will be processed beyond this
point.
11. REFUND POLICY: Refunds are subject to a US$20.00 service charge.
Late fees WILL NOT be refunded.
12. Your registration fee includes Sunday evening reception (cash bar),
and a daily continental breakfast and coffee breaks.
For additional information or assistance, please contact +1-703-620-8990,
+1-703-758-5913 (Fax) or ietf-rsvp at ietf.org. Direct all inquiries
to: 37th IETF Meeting - San Jose, California, USA
Received: from ietf.org by ietf.org id aa04484; 7 Nov 96 17:46 EST
Received: from ietf.org by ietf.org id aa04266; 7 Nov 96 17:43 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Geoff Huston <gih at telstra.net>
Subject: 2nd Nominations Call
Date: Thu, 07 Nov 1996 17:43:47 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9611071743.aa04266 at ietf.org>
IETF CALL FOR NOMINATIONS
-------------------------
It is the task of the IETF Nominations Committee to seek qualified
candidates to fill half of the positions on the IESG and the IAB each
year.
1. Open Positions
-----------------
The positions which expire at the Spring 1997 IETF meeting are:
IESG : Area Directors for:
*Applications current incumbent is Harald Alvestrand
*Operational Requirements current incumbent is Scott Bradner
Internet current incumbent is Frank Kastenholz
*Network Management current incumbent is Deirdre Kostick
Transport current incumbent is Allison Mankin
* There will be some changes to the IESG structure which will see
the Network Management areas of activity being relocated within
the Applications AD and a new Operations and Management AD.
The Nominations Committee is seeking to fill the resultant
4 open slots on the IESG.
IAB : 6 positions are to be nominated. These positions are currenly
filled by:
J Allard
Elise Gerich
Erik Huizer
Robert Moskowitz
Yakov Rekhter
Chris Weider
2. Nominations
--------------
Nominations are sought for these positions. Any member of the IETF
community may nominate any member of the IETF community for any open
position, as listed above. A self-nomination is permitted.
All nominations must be directed by email to
nomcom at telstra.net
Nominations should include the name of the individual being
nominated, the position to which the individual is being nominated
and the basis of the nomination.
The process is intended to seek the best leadership possible from
within the IETF community, so qualities of leadership and extensive
experience working within the IETF are considered desireable `
qualities for nominated individuals.
IETF Nominations close on November 22 1996.
3. Milestones for the Nominations Committee
-------------------------------------------
IETF Nominations
October 23 - November 22
Evaluation of Nominated Individuals by the Nominations Committee
October 23 - December 18
Obtain final consent for nomination from nominated individuals
December 18 - December 23
Potential iteration of nominations (if final consent not obtained)
December 23 - January 17
Prepare nominations and testaments
December 23 - January 24
Pass nominations to confirming bodies
January 27
(The absolute deadline for termination of this activity is 5 March
1997. This schedule attempts to complete the process well in
advance of that date.
4. The IETF Nominations Committee
---------------------------------
Those drawn from the hat to serve on the 1997 committee are:
Guy Almes almes at betelgeuse.advanced.org
Jim Bound bound at zk3.dec.com
Matt Crawford crawdad at fnal.gov
Phill Gross 0006423401 at mcimail.com
Bob Hinden hinden at ipsilon.com
Dorian Kim dorian at cic.net
Bill Manning bmanning at ISI.EDU
Marshall Rose mrose.dbc at dbc.mtview.ca.us
Mike StJohns stjohns at stjohns.eos.home.net
Glen Zorn glennz at microsoft.com
Plus the following non-voting members:
Geoff Huston (chair) gih at telstra.net
Joyce K. Reynolds (IESG liaison) jkrey at isi.edu
Radia Perlman (IAB liaison) Radia_Perlman at novell.com
Christian Huitema (ISOC liaison) huitema at bellcore.com
collectively these folk can be addressed as
nomcom at telstra.net
5. Documents
------------
The documents used by the committee are the POISED95 documents:
RFC 2027
IAB and IESG Selection, Confirmation, and Recall Process: Operation
of the Nominating and Recall Committees", J. Galvin, 05/15/1996.
RFC2028
The Organizations Involved in the IETF Standards Process", R. Hovey,
S. Bradner, 06/11/1996.
Received: from ietf.org by ietf.org id aa05961; 7 Nov 96 18:00 EST
Received: from zephyr.isi.edu by ietf.org id aa05830; 7 Nov 96 17:57 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA15816>; Thu, 7 Nov 1996 14:56:45 -0800
Message-Id: <199611072256.AA15816 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2009 on GPS-Based Addressing and Routing
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 07 Nov 96 14:56:45 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2009:
Title: GPS-Based Addressing and Routing
Author: T. Imielinski, J. Navas
Date: November 1996
Mailbox: {imielins,navas} at cs.rutgers.edu
Pages: 27
Characters: 66,229
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2009.txt
In this document we propose a family of protocols and addressing
methods to integrate GPS into the Internet Protocol to enable the
creation of location dependent services.
IANA Note: This document describes a possible experiment with
geographic addresses. It uses several specific IP addresses and
domain names in the discussion as concrete examples to aid in
understanding the concepts. Please note that these addresses and
names are not registered, assigned, allocated, or delegated to the use
suggested here.
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961107143612.RFC at ISI.EDU>
SEND /rfc/rfc2009.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2009.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961107143612.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07484; 7 Nov 96 18:24 EST
Received: from [207.32.128.130] by ietf.org id aa07414; 7 Nov 96 18:22 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id RAA26002; Thu, 7 Nov 1996 17:13:17 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCCCF.3AF74200 at webster.unety.net>; Thu, 7 Nov 1996 17:15:10 -0600
Message-ID: <01BBCCCF.3AF74200 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Christopher Ambler' <chris at hal.iodesign.com>,
"dcrocker at brandenburg.com" <dcrocker at brandenburg.com>,
"HANK at vm.biu.ac.il" <HANK at vm.biu.ac.il>
Cc: "heath at linus.isoc.org" <heath at linus.isoc.org>,
"ietf at ietf.org" <ietf at ietf.org>, "newdom at vrx.net" <newdom at vrx.net>
Subject: RE: IAHC
Date: Thu, 7 Nov 1996 17:15:08 -0600
Encoding: 39 TEXT
Source-Info: From (or Sender) name not authenticated.
On Thursday, November 07, 1996 2:17 PM, Christopher Ambler[SMTP:chris at hal.iodesign.com] wrote:
@ Please, Jim, calm down for a couple days, okay?
@
@ Nobody is more anxious than I am to see the IAHC fully formed and working,
@ as a prospective registry owner. I've waited over a year now for IANA, I
@ can surely find something to occupy my time for 72 hours while the IAHC
@ bootstraps themselves.
@
@ --
@ Christopher Ambler
@ President, Image Online Design, Inc.
@
@
One thing you could do is work on a root name server.
The Internet Infrastructure can use some more companies
willing to donate bandwidth and equipment to help provide
this important public service.
I bet if you were nice, you could volunteer to operate that
root name server on behalf of the ISOC. Maybe that would
be a donation.
The ISOC and the IAHC seem to be missing some key
points. Their main objective should be to deploy a root
name server, to help organize and sort out the situation
with the 9 popular root name servers that seem to follow
the ISOC direction, help to coordinate the global collection
of root name servers and their interfaces to registries
which have already started to operate.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa12937; 7 Nov 96 19:38 EST
Received: from ng.netgate.net by ietf.org id aa12835; 7 Nov 96 19:36 EST
Received: from [205.175.103.54] (conf1-54.conf.uwash.com [205.175.103.54]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA22404; Thu, 7 Nov 1996 16:44:51 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100601aea815a13f8e at [205.175.103.54]>
In-Reply-To: <199611071619.KAA18711 at Mercury.mcs.net>
References: <9611070426.aa09875 at ietf.org> from "Hank Nussbacher" at Nov 7,
96 11:19:43 am
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 7 Nov 1996 14:53:28 -0800
To: Karl Denninger <karl at mcs.net>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: The cartel begins to crumble?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 8:19 AM -0800 11/7/96, Karl Denninger wrote:
>If a TLD is desirable, it will have NEW customers.
I'd guess that any scheme that is adopted needs to handle the
TRANSITION very, very carefully. Disruption of service is a fundamentally
Bad Thing, as I'd predict you will agree.
So, yes. If no one is using a TLD, who cares. But the instant
there is even ONE user of a TLD, what is our "social" responsibility to
ensure continuity of service (i.e., permanence of domain names)? We can
certainly be cavalier and leave the whole matter to freemarket commercial
forces, but we can also choose to require continuity. Personally, I would
wish for the latter, if feasible.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa15822; 7 Nov 96 20:05 EST
Received: from callandor.cybercash.com by ietf.org id aa15731;
7 Nov 96 20:02 EST
Received: by callandor.cybercash.com; id TAA18129; Thu, 7 Nov 1996 19:56:43 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma018125; Thu, 7 Nov 96 19:56:31 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA13371; Thu, 7 Nov 96 19:59:03 EST
Date: Thu, 7 Nov 1996 19:59:02 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Simon Higgs <simon at higgs.com>
Cc: Jon Postel <postel at isi.edu>, ietf at ietf.org
Subject: Re: [Question] IAHC = IDNB ???
In-Reply-To: <v03007800aea8057bf675 at [204.250.49.20]>
Message-Id: <Pine.SUN.3.91.961107194247.12643C-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
The IDNB was to help settle disputes over who is to manage a domain that
exists or is already specifically provided for, primarily the national TLDs.
IAHC has to do with created new TLDs and handling registries for the global
TLDs. In my opinion, both are simply creations of the IANA who, to the
extent not constrained by standards/bcp actions of the IESG, has plenary
authority over number/name assignment/registration within the IETF, using
IETF in its broad sense, (subject to the possibility of being removed and a
new IANA being appointed by the IAB). And what authorithy does the IETF,
using IETF in its broad sense, have? Why, none at all except to the extent
that people follow it, just like every other authority.
Donald
On Thu, 7 Nov 1996, Simon Higgs wrote:
> Date: Thu, 7 Nov 1996 13:42:26 -0800
> From: Simon Higgs <simon at higgs.com>
> To: Jon Postel <postel at isi.edu>
> Cc: ietf at ietf.org, newdom at vrx.net, newdom at ar.com
> Subject: [Question] IAHC = IDNB ???
>
> Hi all,
>
> I'm trying to update draft-higgs-tld-cat for the IAHC committee's
> review and have a protocol question. What is the difference between the
> Internet Domain Name Board (IDNB) mentioned in some older RFC's and the
> IAHC? They both appear to be performing the same executive domain name
> functions.
>
> Thanks,
>
> Simon
>
> --
> Madness takes its toll. Please have exact change.
>
>
>
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa24005; 7 Nov 96 21:37 EST
Received: from [207.32.128.130] by ietf.org id aa23882; 7 Nov 96 21:36 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id UAA26688; Thu, 7 Nov 1996 20:29:53 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCCEA.B212A300 at webster.unety.net>; Thu, 7 Nov 1996 20:31:46 -0600
Message-ID: <01BBCCEA.B212A300 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Dave Crocker' <dcrocker at brandenburg.com>, Karl Denninger <karl at mcs.net>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: US Top Level Domain
Date: Thu, 7 Nov 1996 20:31:44 -0600
Encoding: 138 TEXT
Source-Info: From (or Sender) name not authenticated.
On Thursday, November 07, 1996 4:53 PM, Dave Crocker[SMTP:dcrocker at brandenburg.com] wrote:
@ At 8:19 AM -0800 11/7/96, Karl Denninger wrote:
@ >If a TLD is desirable, it will have NEW customers.
@
@ I'd guess that any scheme that is adopted needs to handle the
@ TRANSITION very, very carefully. Disruption of service is a fundamentally
@ Bad Thing, as I'd predict you will agree.
@
@ So, yes. If no one is using a TLD, who cares. But the instant
@ there is even ONE user of a TLD, what is our "social" responsibility to
@ ensure continuity of service (i.e., permanence of domain names)? We can
@ certainly be cavalier and leave the whole matter to freemarket commercial
@ forces, but we can also choose to require continuity. Personally, I would
@ wish for the latter, if feasible.
@
@ d/
@
Did that kind of thinking go into the US Top Level Domain
transitions...?
@@@@@@
While many people have been discussing NEW top level domains
the delegation of large blocks of city domains across the United
States have been quietly made to a few companies that now
appear to have a lock on those names, even though the
companies may not be in the same state where the city is located.
(It is interesting to note that companies in New York "own"
many of the cities in New Jersey)
The US domain has historically been FREE. Now a few companies
are able to charge fees and evidently there is no requirement
that a percentage of those fees be sent back to the IANA,
ISI, or the University of Southern California where the
US domain is managed.
This is not much different than the top level domain situation.
Many people have claimed that fees and special selection
procedures are required to delegate top level domains to
registries. People also claim that procedures are needed
to protect consumers in case a registry fails.
As can be seen in the case of the (now valuable) US
top level domain, none of the procedures proposed in
the infamous "Draft Postel" were required to commercialize
what used to be FREE. There does not seem to be much
concern about registries failing, and a first come first
serve policy seems to be in place.
As can be seen below, the US domain is no longer
a special place oriented toward city governments.
Without any input from the city governments, their
names were given to ISPs that now are establishing
commercial registries.
One solution to this situation is the creation of the
.USA top level domain. More information on top level
domains can be found at...
http://www.agn.net/USA-DOMAIN.html
The precendents are now becoming clear, while
some people have been working for many months
to come to a consensus on future TLD directions
others have been making forward progress. Now the
market place will be allowed to decide where all this
heads.
@@@@@@@@@@@@@@@@@@@@@@@@
----------
From: US Domain Registration[SMTP:usdomreg at ISI.EDU]
Sent: Thursday, November 07, 1996 1:06 PM
To:
Cc: usdomreg at ISI.EDU
Subject: Re: Specific US Domain Name
Hi,
The locality names in the US part of the domain name system (such as
Tacoma.WA.US) are to be used for all types of things in that
locality, including businesses, individuals, clubs, and governments.
For example, a business like Joe's Market might have the domain name
Joes-Mkt.TACOMA.WA.US, or an individual, say Fred Jones, cold have
the domain name FHones.Tacoma.WA.US, and the city government could
have the domain name ci.Tacoma.WA.US.
It is typically not appropriate for the city government to control the
domain name management and operation of the nameservers for all the
Internet users in that locality.
The management and operation of locality domain names are often
delegated to Internet service providers (ISPs). These organizations
usually have the resources and experience to do this work. Sometimes
ISPs are delegated several localities to manage. This has generally
worked out well.
In the past some of the ISPs were able to provide these domain name
management services for free, but this is no longer the case. Most of
the ISPs are now charging a small fee for this work (typically
$10/yr).
The delegation is not changed from one manager to another unless there
are significant service problems.
US Domain Registry
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
P.S. The figure of $10 above has not been confirmed. $50 seems
like a more accurate estimate.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa10957; 8 Nov 96 2:55 EST
Received: from SPECTRUM.RNS.COM by ietf.org id aa10866; 8 Nov 96 2:51 EST
Received: from anchor.rns.com by RNS.COM (SMI-8.6/SMI-4.1(Spectrum))
id XAA05096; Thu, 7 Nov 1996 23:42:38 -0800
Received: by anchor.rns.com (SMI-8.6/SMI-SVR4)
id XAA03501; Thu, 7 Nov 1996 23:50:34 -0800
To: ietf at ietf.org
Path: anchor!not-for-mail
Sender:ietf-request at ietf.org
From: Lars Poulsen <lars at anchor.rns.com>
Newsgroups: ietf.misc
Subject: Why More TLDs
Date: 7 Nov 1996 23:50:32 -0800
Organization: RNS / Meret Communications
Lines: 118
Distribution: world
Message-ID: <55uoo8$3d2 at anchor.rns.com>
Source-Info: From (or Sender) name not authenticated.
I must confess a certain puzzlement. I see a small but very vocal band
of mutineers, fighting the entire establisment of Internet governance,
fighting for the right to take over the licensing of top level domains.
Yet I have seen no clear enumeration of the problems to be solved, and
how the changes would - or possibly could - resolve those problems.
Somewhere along the line, the mutineers have decided that we need more
TLDs, and the TLDs must be given to competing registries, and those
deemed most financially promising to the mutineers should be deemed
to have already been licensed to the AlterNIC.
I do see some problems with the current scheme, but I don't see that
adding more TLDs will conclusively improve on the situation, or
that the situation could not be improved by means other than those now
proposed.
Here are the problems that I see in the current regimen:
1) The root servers are heavily loaded, and lookups often seem
to be hampered by congestion.
It seems to me that this is a result of too many functions being
loaded on the same set of servers, and could be best alleviated by
distributing the system more, separating the servers for
ROOT, COM, EDU and the rest onto 4 distinct (symmetrically mirrored)
server sets. I have never understood why it was considered an
advantage to keep SOA for all the TLDs on the root server set.
2) The COM domain is too crowded. The lack of a second-level structure
creates a huge, flat namespace which must be hard on the servers'
search algorithms.
At first blush one would think that adding more TLDs would spread
the registrations; I have come to believe that this is not clear
at all, and that only one thing can possibly induce a migration away
from the .COM namespace: A fee high enough to scare any but the
largest users away; my guess is that it would take at least
$5000 per name per year to make a dent. (Assuming we can
establish a less expensive place for them to go to.)
3) In the absence of a better directory function, DNS+WWW has become
our directory. Thus everyone is motivated to register in the
obvious place in the namespace: <company-name>.COM in order to make
it simple for customers to find them. Since company names aren't
unique, this produces collisions which the registries are
ill-equipped to resolve.
Multiple TLDs served out of unique registries would not solve this
problem, unless there were to be a strong price differentiation.
If we open BIZ, INC, TRADE and COMPANY with the same $50/year
registration fee, I predict that everyone would rush to duplicate
their second-level entries under .COM in EACH of the new domains.
This would be worse than the status quo, in that the clients would
pay more, the burdens of sorting out conflicts would get multiplied by
the number of registries. At the same time, it would be less
convenient for users, since any search that failed in .COM would now
have to be retried in each of the alternates, before the slower
fallback lookup methods (such as WHOIS) would be tried.
Furthermore, there is a real risk that large businesses would choose
to use the TLD registry function to effectively register themselves in
the root rather than in the second level, thus perpetuating the present
problems and focusing them in the root, which has got to be the worst
possible place to have this congestion.
4) There are anecdotes of clients being denied registration in
reasonable parts of the national domains.
I am sure that this has happenend, but I have yet to be convinced
that it is widespread.
Here are some advantages in the current system:
5) It is really simple to navigate. Over 90% of the time, I find the
entity I'm looking for in the first try.
6) It provides for choices in where to register: COM, US, ORG.
7) Everyone involved seems to have a friendly, community-service
attitude (at least until someone threatens them with lawyers).
8) It works remarkably well. I suspect that after we open up the
system, it will never work this well again.
Here are some minor steps we could take:
9) Open for industry-specific second level domains under US
NETWORKS.US (e.g. CISCO.NETWORKS.US)
MOTOR.US (e.g. FORD.MOTOR.US)
MOVIES.US (e.g. ID4.MOVIES.US, Texas-Chainsaws.MOVIES.US)
AERO.US (e.g. BOEING.AERO.US, MARTIN.AERO.US)
AIRLINES.US (e.g. AMERICAN.AIRLINES.US)
etc.
and encourage other national registries to do the same.
This could take a LOT of pressure off COM.
10) License a single alternative TLD named ALT to the group behind
AlterNIC to operate as they wish. This would allow them to set up
an entire structure with a market orientation under
BIZ.ALT
INC.ALT
MARKET.ALT
etc
This would have a minimal impact on the core system, while allowing
the community to asses the effects of competition. The licenssee
should be free to sublicense portions of this namespace according to
whatever rules they can agree on between themselves.
Under this proposal, an IAHC could later license other TLDs to
other groups if the experiment is successful.
All of my engineering experience tells me that the way to get to a new
structure is by a sequnece of planned, minor adjustments rather than by
massive changes all at once.
--
/ Lars Poulsen Internet E-mail: lars at OSICOM.COM
OSICOM Technologies (Internet Business Unit, formerly RNS)
7402 Hollister Avenue Telefax: +1-805-968-8256
Santa Barbara, CA 93117 Telephone: +1-805-562-3158
Received: from ietf.org by ietf.org id aa14215; 8 Nov 96 5:04 EST
Received: from dxmint.cern.ch by ietf.org id aa13864; 8 Nov 96 5:00 EST
Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch
with SMTP id KAA14868; Fri, 8 Nov 1996 10:59:23 +0100 (MET)
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM)
id AA05282; Fri, 8 Nov 1996 10:59:16 +0100
Message-Id: <9611080959.AA05282 at dxcoms.cern.ch>
Subject: Re: IAHC
To: Karl Denninger <karl at mcs.net>
Date: Fri, 8 Nov 1996 10:59:16 +0100 (MET)
Sender:ietf-request at ietf.org
From: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
Cc: HANK at taunivm.tau.ac.il, karl at mcs.net, HANK at vm.biu.ac.il, ietf at ietf.org
In-Reply-To: <199611071959.NAA17027 at Jupiter.Mcs.Net> from "Karl Denninger" at Nov 7, 96 01:59:58 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
>--------- Text sent by Karl Denninger follows:
>
...
>
> Further, the IAB has not responded to our formal complaint regarding the
> IANA attempts to circumvent procedure.
If you are referring to a message from Eugene Kashpureff dated September
17, 1996, we replied to it on September 27, 1996.
Brian Carpenter
Received: from ietf.org by ietf.org id aa17031; 8 Nov 96 6:34 EST
Received: from eunet.EU.net by ietf.org id aa16800; 8 Nov 96 6:30 EST
Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id MAA06107; Fri, 8 Nov 1996 12:29:54 +0100 (MET)
Received: by jotun.EU.net id AA00921
(5.67a/IDA-1.5); Fri, 8 Nov 1996 12:29:53 +0100
Message-Id: <199611081129.AA00921 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <bilse at eu.net>
Date: Fri, 8 Nov 1996 12:29:52 +0100
In-Reply-To: <01BBCCBD.094F5560 at webster.unety.net>
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Jim Fleming <JimFleming at unety.net>
Subject: Re: The Internet Tree
Cc: "ietf at ietf.org" <ietf at ietf.org>
Source-Info: From (or Sender) name not authenticated.
On Nov 7, 15:04, Jim Fleming <JimFleming at unety.net> wrote:
> @ How does your, Fleming's, et als "process" line up?
>[...]
>
> The process I have proposed is VERY simple. It is
For one thing, it sounds like an awfully complicated nightmare to me,
but you are in fact completely missing the point. The "process" I am
referring to is the feeble-minded attempt by a couple of individuals
to invent or hijack non-existent/unregistered namespace and pretend
to innocent bystanders that they are authorities on the issue and
that their dreams represent the real world. This is completely
bogus. And when money changes hands based on this, I believe "fraud"
is indeed a correct description.
--
------ ___ --- Per G. Bilse, Mgr Network Operations
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net
Received: from ietf.org by ietf.org id aa17773; 8 Nov 96 6:46 EST
Received: from eunet.EU.net by ietf.org id aa17543; 8 Nov 96 6:44 EST
Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id MAA06409; Fri, 8 Nov 1996 12:43:33 +0100 (MET)
Received: by jotun.EU.net id AA00979
(5.67a/IDA-1.5); Fri, 8 Nov 1996 12:43:32 +0100
Message-Id: <199611081143.AA00979 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <bilse at eu.net>
Date: Fri, 8 Nov 1996 12:43:32 +0100
In-Reply-To: <199611071959.NAA17027 at Jupiter.Mcs.Net>
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Karl Denninger <karl at mcs.net>
Subject: Re: IAHC
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
On Nov 7, 13:59, Karl Denninger <karl at mcs.net> wrote:
> Sure. But I won't give you 4 (or more) months.
So what are you going to do? Sue somebody, as usual?
Can't you just for once lower the adrenalin level and let things fall
into place? You didn't seriously believe anybody in the Net would
fall for the AlterNIC story, did you?
The IAHC will have the full support of all relevant parts of the Net,
given that it seems to consist of sober, rational, well-composed
individuals with more or less reasonably proven track records
wherever they come from. This is what creates authority, Karl; not
jumping up and down, bellowing, and foaming at the mouth.
--
------ ___ --- Per G. Bilse, Mgr Network Operations
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net
Received: from ietf.org by ietf.org id aa21542; 8 Nov 96 9:13 EST
Received: from Kitten.mcs.com by ietf.org id aa21114; 8 Nov 96 9:04 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id IAA14040; Fri, 8 Nov 1996 08:03:02 -0600 (CST)
Received: from Jupiter.Mcs.Net (karl at Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id IAA25868; Fri, 8 Nov 1996 08:03:01 -0600 (CST)
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id IAA11211; Fri, 8 Nov 1996 08:03:00 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611081403.IAA11211 at Jupiter.Mcs.Net>
Subject: Re: The cartel begins to crumble?
To: Rens Troost <rens at name.net>
Date: Fri, 8 Nov 1996 08:03:00 -0600 (CST)
Cc: karl at mcs.net, HANK at taunivm.tau.ac.il, HANK at vm.biu.ac.il, ietf at ietf.org
In-Reply-To: <199611080959.EAA21151 at engine.name.net> from "Rens Troost" at Nov 8, 96 04:59:10 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> > It would be a *real* bad idea to attempt to do this in many countries -- the
> > United States included.
>
> Incorrect. Most securities firms, for instance, tape all
> converstations as a matter of course. The government actually smiles
> on this activity, as do the insurance companies.
>
> -Rens
There are laws providing that proper notice must be given to the person
calling you when you do that.
How likely is someone to admit to a practice they know is a problem on the
phone if they KNOW they're being taped.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa21832; 8 Nov 96 9:16 EST
Received: from [207.32.128.130] by ietf.org id aa21577; 8 Nov 96 9:14 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id IAA29123; Fri, 8 Nov 1996 08:07:46 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCD4C.3102DB60 at webster.unety.net>; Fri, 8 Nov 1996 08:09:40 -0600
Message-ID: <01BBCD4C.3102DB60 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: Multiple recipients of list DOMAIN-POLICY <DOMAIN-POLICY at lists.internic.net>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>, 'New Newdom' <newdom at vrx.net>,
"'simsong at VINEYARD.NET'" <simsong at vineyard.net>
Subject: RE: US Top Level Domain
Date: Fri, 8 Nov 1996 08:09:39 -0600
Encoding: 28 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 08, 1996 7:20 AM, Simson L. Garfinkel[SMTP:simsong at VINEYARD.NET] wrote:
@ US domain used to be a volunteer project. It became a burden for ISI. So they
@ farmed it out. People who take up regions are allowed to charge.
@ -s
@
It is useful to note that this "farming out" was not done with
an RFC, no fee guidelines have been set, no IAHC had to be
formed, and the net has not collapsed.
Are people happy about this ? Only time will tell...
Do city governments understand why "their" domain is
managed by some company in another state ? No.
Will state governments start asking those companies
why they are not registered to do business in the states
where they control large blocks of US domain names ?
Only time will tell...
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa22948; 8 Nov 96 9:31 EST
Received: from ietf.org by ietf.org id aa22347; 8 Nov 96 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnsind-dynDNS-10.txt
Date: Fri, 08 Nov 1996 09:26:10 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611080926.aa22347 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Title : Dynamic Updates in the Domain Name System (DNS UPDATE)
Author(s) : P. Vixie, S. Thomson, Y. Rekhter, J. Bound
Filename : draft-ietf-dnsind-dynDNS-10.txt
Pages : 28
Date : 11/07/1996
The Domain Name System was originally designed to support queries of a
statically configured database. While the data was expected to change, the
frequency of those changes was expected to be fairly low, and all updates
were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add or
delete RRs or RRsets from a specified zone. Prerequisites are specified
separately from update operations, and can specify a dependency upon either
the previous existence or nonexistence of an RRset, or the existence of
a single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-dynDNS-10.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-dynDNS-10.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-dynDNS-10.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961107111943.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-dynDNS-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-dynDNS-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961107111943.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22962; 8 Nov 96 9:31 EST
Received: from ietf.org by ietf.org id aa22404; 8 Nov 96 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-fujikawa-ipsvc-01.txt
Date: Fri, 08 Nov 1996 09:26:33 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611080926.aa22404 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Another ATM Signaling Protocol for IP (IP-SVC)
Author(s) : K. Fujikawa
Filename : draft-fujikawa-ipsvc-01.txt
Pages : 13
Date : 11/07/1996
This memo describes IP-SVC that is another ATM signaling protocol for
implementing IP protocols. IP-SVC restricts the range of signaling to an IP
subnet, and this restriction makes the IP-SVC structure simple. IP-SVC
provides easy implementation of the mechanism of ARP and IP multicasting
without any servers.
IP-SVC can not establish VCs across IP subnet boundaries by itself.
However, adapting CSRs (Cell Switching Routers) with RSVP (Resource
ReSerVation Protocol) enables end-to-end VC establishment across IP subnet
boundaries in IP/ATM LANs based on IP-SVC. This method also shows one
solution of RSVP over ATM.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-fujikawa-ipsvc-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-fujikawa-ipsvc-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-fujikawa-ipsvc-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961107163254.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-fujikawa-ipsvc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-fujikawa-ipsvc-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961107163254.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22942; 8 Nov 96 9:31 EST
Received: from ietf.org by ietf.org id aa22377; 8 Nov 96 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-wessels-icp-v2-00.txt
Date: Fri, 08 Nov 1996 09:26:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611080926.aa22377 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Cache Protocol (ICP), version 2
Author(s) : D. Wessels, K. Claffy
Filename : draft-wessels-icp-v2-00.txt
Pages : 7
Date : 11/07/1996
This draft document describes the Internet Cache Protocol (ICP) currently
implemented in a few World-Wide Web proxy cache packages. ICP was
initially developed by Peter Danzig, et. al. at the Univerisity of Southern
California. It evolved as an important part of hierarchical caching on the
Harvest research project.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-wessels-icp-v2-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-wessels-icp-v2-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-wessels-icp-v2-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961107140512.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-wessels-icp-v2-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-wessels-icp-v2-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961107140512.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22900; 8 Nov 96 9:31 EST
Received: from ietf.org by ietf.org id aa22365; 8 Nov 96 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-stager-pdc-netapp-backup-00.txt
Date: Fri, 08 Nov 1996 09:26:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611080926.aa22365 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Network Data Management Protocol
Author(s) : R. Stager, D. Hitz
Filename : draft-stager-pdc-netapp-backup-00.txt
Pages : 75
Date : 11/07/1996
The Network Data Management Protocol (NDMP) addresses the user's need for
centralized control of enterprise-wide network data management while
minimizing network traffic. The design objective of the protocol is to make
every network attached storage device "backup ready", enabling true
plug-and-play backup operation. The user will not be required to install
any additional software on an NDMP-compliant network storage device. With
the NDMP approach, each network-attached file server ships with a
"universal agent," which can be used by any NDMP-compliant backup
administration application. For IS departments and system administrators,
NDMP will ensure interoperability between different file servers and backup
solutions, significantly simplifying the data management process. This same
universal agent architecture is also for network-attached backup devices,
such as a tape libraries.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-stager-pdc-netapp-backup-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-stager-pdc-netapp-backup-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-stager-pdc-netapp-backup-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961107115709.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-stager-pdc-netapp-backup-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-stager-pdc-netapp-backup-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961107115709.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23764; 8 Nov 96 9:37 EST
Received: from cnri by ietf.org id aa23531; 8 Nov 96 9:34 EST
Received: from wilbur.nas.nasa.gov by CNRI.Reston.VA.US id aa11254;
8 Nov 96 9:34 EST
Received: (from lekash at localhost)
by wilbur.nas.nasa.gov (8.7.6/NAS.6.1) id GAA09703; Fri, 8 Nov 1996 06:32:56 -0800 (PST)
Date: Fri, 8 Nov 1996 06:32:56 -0800 (PST)
Sender:ietf-request at ietf.org
From: John Lekashman <lekash at nas.nasa.gov>
Message-Id: <199611081432.GAA09703 at wilbur.nas.nasa.gov>
To: JimFleming at unety.net, sthaug at nethelp.no
CC: ietf at CNRI.Reston.VA.US, newdom at vrx.net, lekash at nas.nasa.gov
In-reply-to: <01BBC802.B4CACCE0 at webster.unety.net> (message from Jim Fleming on Fri, 1 Nov 1996 14:41:01 -0600)
Subject: NASA name servers, various comments regarding function.
Source-Info: From (or Sender) name not authenticated.
I noted that various comments were made regarding alleging problems
with reachability, functionality, Government funding, et al, with
regard to the current NASA root name server.
NASA has programmatic requirements that lead it to develop major
parts of Internet infrastructure in the distant past, and to continue
to be well connected and a part of that infrastructure.
It is actually a fairly trivial economic decision to spend some small
amount of $ on things such as root servers, rather than a much larger
amount to provision private systems.
So, I made that particular decision some 10 years ago, when I first
set up said root server.
Yes, things have changed. Yes, I gave it all to Milo to run, some
five or six years ago, because he did it very well, and I had other
things to go build.
Yes, there have been many personnel changes at NASA in the interim.
If there are now operational problems with the facilities,
I would like actual explicit details of actual problems with
these, or other such NASA Internet facilities. I am prepared to
do something about it, if there are any substantive issues.
Useful statements, such as noting under-capacity servers or links,
noted extended downtime, corrupted or out of date caching, congestion
choke-points in the infrastructure, or any other real issues will be
addressed. I do not, however, promise that your overloaded T1 will be
upgraded.
Innuendo, noting that some random site could not ping the server, or
other such statements, are not very useful.
Questions regarding the political rightness or wrongness of the US
Government using or deploying a facility, or other forms of
self-aggrandizement will be ignored. Send those to your Congressman
or other favorite elected official, please.
Thank you,
john
remember. simple is really, really hard.
lekash at nas.nasa.gov
Received: from ietf.org by ietf.org id aa25296; 8 Nov 96 9:57 EST
Received: from dns1.noc.best.net by ietf.org id aa24764; 8 Nov 96 9:53 EST
Received: from bovik.vip.best.com (bovik.vip.best.com [205.149.161.94]) by dns1.noc.best.net (8.8.2/8.7.3) with SMTP id GAA01059 for <ietf at ietf.org>; Fri, 8 Nov 1996 06:52:37 -0800 (PST)
Message-Id: <199611081452.GAA01059 at dns1.noc.best.net>
Date: Fri, 08 Nov 96 06:53:00 -0800
Sender:ietf-request at ietf.org
From: James Salsman <jsalsman at bovik.org>
Organization: Bovik Research
X-Mailer: Mozilla 1.22 (Windows; I; 16bit)
MIME-Version: 1.0
Newsgroups: comp.speech
To: ietf at ietf.org
Subject: Re: IETF speech coding for email?
References: <328332D4.4AD0 at sprynet.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Dan Robinson <lldavis at sprynet.com> wrote:
>
> The IETF is looking at sending coded speech via email.
> Does anyone know what algorithm they are planning to use?
Dear IETF:
Please do not use Linear Predictive Coding.
Linear Predictive Coding has been shown many times to
be microphone-dependent, which is to say that identical
speech sampled with different microphones produces
highly divergent Linear Predictive Codes.
Linear Predictive Coding may be a remnant of legal
threats made my the government against independant
inventors who have from time to time developed very
effective speech coding schemes which happened to be
used in sensitive cockpit applications and as such
would have provided hostile forces with the means for
identifying the plain text of sensitive transmissions.
Please use a coding which is likely to allow for the
seperation of phonemic units by flat hyperplanes in
the space defined by the code vector. I believe the
most suitable candidate for use is an overlapping
window of cepstral codes, as defined by Cooley and
Tukey in 1963 as the forward Fourier transform of
the log magnitude spectrum. The IETF should also
consider providing a code which emphasises the
frequencies of the range of human vocal tracts.
My personal opinion is that the IETF should also
consider a coding which seperatly encodes the
harmonics of the spoken sound. For additional
information on this topic, please see the one-page
dataflow diagram in ftp://ftp.best.com/pub/bovik/coder.ps
Sincerely,
:James Salsman
Disclaimer: these are my views and I have shared these
views with my employers. Now that I have an employer
capable of understanding these views (for which I am
quite thankful), they agree as far as I know.
Received: from ietf.org by ietf.org id aa27785; 8 Nov 96 10:18 EST
Received: from mikado.name.net by ietf.org id aa27545; 8 Nov 96 10:13 EST
Received: from engine.name.net (engine.name.net [204.50.44.14]) by name.net (8.7.6/8.6.12) with ESMTP id KAA19956; Fri, 8 Nov 1996 10:12:34 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by engine.name.net (8.7.6/8.6.12) with SMTP id KAA22282; Fri, 8 Nov 1996 10:12:34 -0500 (EST)
Message-Id: <199611081512.KAA22282 at engine.name.net>
X-Authentication-Warning: engine.name.net: Host localhost [127.0.0.1] didn't use HELO protocol
To: Karl Denninger <karl at mcs.net>
cc: Rens Troost <rens at name.net>, HANK at taunivm.tau.ac.il, HANK at vm.biu.ac.il,
ietf at ietf.org
Subject: Re: The cartel begins to crumble?
X-Jothi: Mail Not From Jothi. Jothi's permission not required for distribution.
In-reply-to: Your message of "Fri, 08 Nov 1996 08:03:00 CST."
<199611081403.IAA11211 at Jupiter.Mcs.Net>
Date: Fri, 08 Nov 1996 10:12:33 -0500
Sender:ietf-request at ietf.org
From: James Wetterau <jwjr at name.net>
Source-Info: From (or Sender) name not authenticated.
Karl Denninger says:
> > > It would be a *real* bad idea to attempt to do this in many countries --
the
> > > United States included.
> >
> > Incorrect. Most securities firms, for instance, tape all
> > converstations as a matter of course. The government actually smiles
> > on this activity, as do the insurance companies.
> >
> > -Rens
>
> There are laws providing that proper notice must be given to the person
> calling you when you do that.
>
> How likely is someone to admit to a practice they know is a problem on the
> phone if they KNOW they're being taped.
The laws vary from state to state. I believe that all of the
following have been tried somewhere in the U.S., at some time:
o you must give advance notice
o you must merely beep every n seconds, to implicitly notify the other person
o you must do both of the above
o you may freely, clandestinely tape
I believe that in New York state the last is now the law, but I am not
a lawyer. Consult a lawyer before taping.
--
James Wetterau
jwjr at name.net
Received: from ietf.org by ietf.org id aa28352; 8 Nov 96 10:26 EST
Received: from jekyll.piermont.com by ietf.org id aa28194; 8 Nov 96 10:23 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id KAA27396; Fri, 8 Nov 1996 10:21:11 -0500 (EST)
Message-Id: <199611081521.KAA27396 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol
To: Jim Fleming <JimFleming at unety.net>
cc: 'Hank Nussbacher' <HANK at vm.biu.ac.il>, "ietf at ietf.org" <ietf at ietf.org>,
'New Newdom' <newdom at vrx.net>
Subject: Re: More iTLD thread
In-reply-to: Your message of "Thu, 07 Nov 1996 13:57:35 CST."
<01BBCCB3.A20269A0 at webster.unety.net>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 08 Nov 1996 10:21:05 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Jim Fleming writes:
> I do not think that you 4 months. Have you read Paul Vixie's
> postion statement giving you a January 15, 1997 deadline
> before he goes "ballistic" (whatever Paul means by that).
I've spoken to Paul. He understands the situation.
Feel free to continue spreading rumors if you wish, however.
Perry
Received: from ietf.org by ietf.org id aa01062; 8 Nov 96 11:05 EST
Received: from jekyll.piermont.com by ietf.org id aa00832; 8 Nov 96 11:01 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id KAA27488; Fri, 8 Nov 1996 10:59:05 -0500 (EST)
Message-Id: <199611081559.KAA27488 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol
To: Karl Denninger <karl at mcs.net>
cc: Hank Nussbacher <HANK at taunivm.tau.ac.il>, HANK at vm.biu.ac.il,
ietf at ietf.org
Subject: Re: The cartel begins to crumble?
In-reply-to: Your message of "Thu, 07 Nov 1996 14:04:54 CST."
<199611072004.OAA17158 at Jupiter.Mcs.Net>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 08 Nov 1996 10:59:05 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Karl Denninger writes:
> > In one case, a customer taped his phone conversation with the company
> > trying to sell the DN.
>
> Try that in the US and you may run afoul of CRIMINAL statutes, depending on
> the state you're calling from and to.
In most of the U.S., its perfectly legal to tape a conversation you
are a party to. In a couple of exceptional states, it isn't.
Perry
Received: from ietf.org by ietf.org id aa03535; 8 Nov 96 11:27 EST
Received: from jekyll.piermont.com by ietf.org id aa03052; 8 Nov 96 11:22 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id LAA27522; Fri, 8 Nov 1996 11:20:01 -0500 (EST)
Message-Id: <199611081620.LAA27522 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol
To: Jim Fleming <JimFleming at unety.net>
cc: "ietf at ietf.org" <ietf at ietf.org>, 'New Newdom' <newdom at vrx.net>
Subject: Re: More iTLD thread
In-reply-to: Your message of "Thu, 07 Nov 1996 15:36:45 CST."
<01BBCCC1.7C657940 at webster.unety.net>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 08 Nov 1996 11:20:01 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Jim Fleming writes:
> Why haven't the discussions with "Paul" been in
> an open forum...?
Jim;
I will call Paul Vixie up any time I like and discuss anything I like
with him. I am under no obligation, now or ever, to inform you before
I call him, to inform you if I call him, or to inform you of why I
called him or the contents of the call if I choose to mention in
public that I spoke with him at all.
Perry
Received: from ietf.org by ietf.org id aa09967; 8 Nov 96 13:32 EST
Received: from Kitten.mcs.com by ietf.org id aa09843; 8 Nov 96 13:28 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id MAA28265; Fri, 8 Nov 1996 12:27:28 -0600 (CST)
Received: from Mars.mcs.net (karl at Mars.mcs.com [192.160.127.85]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id MAA14844; Fri, 8 Nov 1996 12:27:19 -0600 (CST)
Received: (from karl at localhost) by Mars.mcs.net (8.8.2/8.8.2) id MAA22241; Fri, 8 Nov 1996 12:27:14 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611081827.MAA22241 at Mars.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Dave Crocker <dcrocker at brandenburg.com>
Date: Fri, 8 Nov 1996 12:27:13 -0600 (CST)
Cc: karl at mcs.net, ietf at ietf.org
In-Reply-To: <v03100601aea815a13f8e at [205.175.103.54]> from "Dave Crocker" at Nov 7, 96 02:53:28 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> At 8:19 AM -0800 11/7/96, Karl Denninger wrote:
> >If a TLD is desirable, it will have NEW customers.
>
> I'd guess that any scheme that is adopted needs to handle the
> TRANSITION very, very carefully. Disruption of service is a fundamentally
> Bad Thing, as I'd predict you will agree.
Yes it is.
However, I do not believe it is a proper function of the Internet
"infrastructure" to provide what amounts to insurance.
I *do* support an escrow arrangement for the *current* configuration of the
zone (since its public anyway, there are no issues). Likewise, there are no
significant issues with pointing the NS lines in the root nameservers on a
*temporary* basis to an escrowing agent if a registry "dies" -- until things
are sorted out. However, any attempt to prevent and money with the normal
asset disposal process of a bankrupt registry is going to run afoul of at
least US (and probably most other national) laws.
There is no point in trying to do this. The courts won't permit it anyway,
and if you represent that you *can* usurp their authority you just create a
cause of action for the registrants against the ISOC and related organizations!
Why would you want to do THAT?
> So, yes. If no one is using a TLD, who cares. But the instant
> there is even ONE user of a TLD, what is our "social" responsibility to
> ensure continuity of service (i.e., permanence of domain names)? We can
> certainly be cavalier and leave the whole matter to freemarket commercial
> forces, but we can also choose to require continuity. Personally, I would
> wish for the latter, if feasible.
> --------------------
> Dave Crocker +1 408 246 8253
You can't *require* continuity.
You can take steps to attempt to prevent interruption of service *during the
period that a registry is offline, up to but not beyond the point at which a
court makes a disposal of that asset (the registry and its customers)*.
The first is trival to do.
The second (ie: trying to force successors to honor agreements with a firm
that no longer exists) is contrary to public policy and law, and won't
stand.
The first rule that I believe these "committees" need to understand is this:
Don't try to act like a tribunal. Do not attempt to set policy
which has the effect of contravening the authority of real judicial
systems. You *will* get in trouble down the road if you do this
from BOTH sides of the disputes which subsequently arise, and you
are just creating causes of civil action out of whole cloth!
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa10034; 8 Nov 96 13:34 EST
Received: from Kitten.mcs.com by ietf.org id aa09932; 8 Nov 96 13:31 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id MAA28362; Fri, 8 Nov 1996 12:30:34 -0600 (CST)
Received: from Mars.mcs.net (karl at Mars.mcs.com [192.160.127.85]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id MAA15582; Fri, 8 Nov 1996 12:30:30 -0600 (CST)
Received: (from karl at localhost) by Mars.mcs.net (8.8.2/8.8.2) id MAA22372; Fri, 8 Nov 1996 12:30:29 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611081830.MAA22372 at Mars.mcs.net>
Subject: Re: IAHC
To: Per Gregers Bilse <bilse at eu.net>
Date: Fri, 8 Nov 1996 12:30:28 -0600 (CST)
Cc: karl at mcs.net, ietf at ietf.org
In-Reply-To: <199611081143.AA00979 at jotun.EU.net> from "Per Gregers Bilse" at Nov 8, 96 12:43:32 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> On Nov 7, 13:59, Karl Denninger <karl at mcs.net> wrote:
> > Sure. But I won't give you 4 (or more) months.
>
> So what are you going to do? Sue somebody, as usual?
If someone (including the IAHC) does something which creates a cause of
action, why wouldn't I?
Or are we (and the rest of the Internet community) just supposed to "take it
on the chin" and enjoy it? I think not.
> Can't you just for once lower the adrenalin level and let things fall
> into place? You didn't seriously believe anybody in the Net would
> fall for the AlterNIC story, did you?
On the contrary. Many people are supporting the eDNS environment.
> The IAHC will have the full support of all relevant parts of the Net,
> given that it seems to consist of sober, rational, well-composed
> individuals with more or less reasonably proven track records
> wherever they come from.
On the contrary. There is no evidence to support this assertion *AT THIS
TIME*. The actions of that group will determine the response.
>This is what creates authority, Karl; not
> jumping up and down, bellowing, and foaming at the mouth.
And people wonder why they end up in kill files.... ad-hominen attacks top
the list of causes.
> ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
Thank you very much for yet another organization that needs no cooperation
from me.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa10641; 8 Nov 96 13:42 EST
Received: from cnri by ietf.org id aa10313; 8 Nov 96 13:39 EST
Received: from hera.rbi.informatik.uni-frankfurt.de by CNRI.Reston.VA.US
id aa17641; 8 Nov 96 13:39 EST
Received: from dbis.informatik.uni-frankfurt.de (roma.dbis.informatik.uni-frankfurt.de) by hera.rbi.informatik.uni-frankfurt.de with SMTP
(1.40.112.4/16.2) id AA060217630; Fri, 8 Nov 1996 19:27:10 +0100
Received: from atlas.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp
(Smail3.1.28.1 #4) id m0vLvdw-000BmsC; Fri, 8 Nov 96 19:27 MET
Received: by atlas.rbi.informatik.uni-frankfurt.de
(1.39.111.2/16.2) id AA007308782; Fri, 8 Nov 1996 19:46:22 +0100
Sender:ietf-request at ietf.org
From: zicari at informatik.uni-frankfurt.de
Posted-Date: Fri, 8 Nov 1996 19:46:22 +0100
Received-Date: Fri, 8 Nov 1996 19:46:22 +0100
Message-Id: <199611081846.AA007308782 at atlas.rbi.informatik.uni-frankfurt.de>
Subject: owf release
To: int.multimedia at dbis.informatik.uni-frankfurt.de
Date: Fri, 8 Nov 1996 19:46:22 +0100 (MET)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 5390
Source-Info: From (or Sender) name not authenticated.
FYI.
Regards
Roberto Zicari
OWF Chair
-------------------------------------------------------
Press Release
Object World Frankfurt is now 60% larger than last year
Frankfurt -- October 15, 1996.
A Rapidly Growing Show:
The conferences and exhibits Object World Frankfurt and Internet Forum Europe,
held October 9-11, 1996 at the Sheraton Conference Center (Airport) in
Frankfurt/Main, continue to grow.
With 78 exhibitors (1995: 50), 2,000 sqm exhibition (1995: 1,200),
2,800 visitors (1995: 1,800), and 780 conference delegates (1995: 650),
the show grew overall of a whopping 60 percent with respect to last year.
The business aspects of object technology and the Internet was the main
theme of the two conferences Object World Frankfurt - now in its fifth year-
and Internet Forum Europe - premiere event this year - , and of the combined
exhibits.
For the two conferences, over 150 speakers from all over the world came
to Frankfurt/Main from October 9 to 11, to address issues such as
"The Business value of the Internet", and "The Real Benefits of Objects
in Business".
International Conferences:
40% of the conference delegates came this year from several European
countries ranging from the Netherlands, Switzerland to Sweden.
The rest of the delegates came from Germany, with the notably exception
of a delegation of participants from the Japan Education Service Corporation
in Tokyo.
"We are particularly happy with this result: The high number of
international conference delegates, and the fact that the European Commission
has chosen Object World Frankfurt and Internet Forum Europe to present
their activities on the Internet, is a confirmation of the importance of
this event in Europe", says Prof. Roberto Zicari, Object World Frankfurt
and Internet Forum Europe Program Chair.
The European Commission presented at Internet Forum Europe two tracks on
Electronic Commerce, the G7 Initiative for a Global Marketplace for SMEs,
and Web for schools.
The combined exhibition on object technology and Internet on
October 10 and 11, included leading companies such as Deutsche Telekom,
Digital Equipment, Hewlett-Packard, IBM, Informix Software, NeXT Computer,
Siemens Nixdorf, Software AG, SunSoft, and Sybase.
"Combining object technology and the Internet in one single exhibition has
proven to be a successful formula" , says Christiane Sattler, show manager
at LogOn Technology Transfer GmbH, "We will definitely repeat it next year
as well".
Show Highlight: The Object Application Awards
One of the highlights of the show was in the evening of October 10,
the Third Object Applications Ceremony. Dr. Hartmut Schwesinger,
Chief Executive Officer, Business and Economic Development Corp. City of
Frankfurt, welcomed the over 400 attendees to the ceremony, together with
Christopher Stone, President and CEO of the Object Management Group, who was
the Master of Ceremony. Five Awards for the best applications using object
technology were given to: ABB (Germany), debis Systemhaus GmbH (Germany),
Deutsche Bahn AG (Germany), Motorola (US) and Sabre Decision Technologies (US).
The awards jury was chaired by Prof. Roberto Zicari, University of Frankfurt
and LogOn and included Prof. Gerhard Barth (Daimler Benz), Prof. Ulrich
Eisenecker (FH Heidelberg), Dr. Ralf Jungclaus (Deutsche Telekom),
Prof. Dr. Klaus Kuspert (University of Jena), Dr. Thomas Neumann (SMS),
Hauke Peyn (Bertelsmann), Prof. Radu Popescu-Zeletin (GMD FOKUS),
Michael Wagner (Free Journalist).
Dates for the 1997 show:
Internet Forum Europe and Object World Frankfurt will return to
Frankfurt/Main next year on October 7-10, 1997
(Sheraton Airport Conference Center).
OWF and IFE are sponsored and organized by Object World Corp.
(a Softbank COMDEX company) Object Management Group (OMG)
and LogOn technology Transfer GmbH.
Press contact:
LogOn Technology Transfer GmbH
Birgit Osterholt, Annegret Claushues
Burgweg 14
D-61476 Kronberg / Ts.
Germany
phone: +49-61 73 - 2852
fax: +49-61 73 - 94 04 20
e-mail: 101510.3135 at compuserve.com (Birgit Osterholt)
Object World Corp.
Object World Corporation, a Softbank COMDEX company, owns and
produces Object World conferences and expositions. Object World is
the world's largest leading object technology event series focusing
exclusively on the commercial and practical applications of object technology
and distributed object computing. Object World is held annually in Boston,
San Jose, London, Frankfurt, Tokyo and Sydney.
LogOn
LogOn Technology Transfer GmbH, founded in 1991, is a privately owned
company exclusively focused on the Internet and object technology market.
LogOn helps European companies to exploit the Internet and object technology
(OT) for their business needs and provides a comprehensive set of services.
LogOn is organized into five operating divisions: Trade Shows Division,
Marketing Division, PR Division, Training Division, Business Division.
LogOn is the official representative of the Object Management Group (OMG)
for Austria, Benelux, France, Germany, Italy and Switzerland.
OMG is the largest software consortium worldwide with more than 600 members
companies dedicated to promoting the theory and practice of object technology
(OT) for the development of distributed computing systems.
World Wide Web: http://www.ltt.de
##
2
Received: from ietf.org by ietf.org id aa17089; 8 Nov 96 16:29 EST
Received: from presence.lglobal.com by ietf.org id aa16910; 8 Nov 96 16:23 EST
Received: from [207.107.12.71] (voyager6.lglobal.com [207.107.12.71]) by presence.lglobal.com (8.6.12/8.6.12) with SMTP id QAA09988; Fri, 8 Nov 1996 16:32:49 -0500
X-Sender: allisat at mail.lglobal.com
Message-Id: <v01540b03aea954d6474d at [207.107.12.71]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 8 Nov 1996 16:26:43 -0500
To: perry at piermont.com
Sender:ietf-request at ietf.org
From: Bob Allisat <tor at wtv.net>
Subject: Re: More iTLD thread
Cc: Jim Fleming <JimFleming at unety.net>,
'Hank Nussbacher' <HANK at vm.biu.ac.il>, "ietf at ietf.org" <ietf at ietf.org>,
'New Newdom' <newdom at vrx.net>
Source-Info: From (or Sender) name not authenticated.
Perry E. Metzger wrote:
>I've spoken to Paul. He understands the situation.
>
>Feel free to continue spreading rumors if you wish, however.
And, Perry, you can continue
to spread disharmony, venom
and a slanted view of the
whole matter. As you always
have. Same bitter Metzger.
Quote> No, but there could be a perception that you picked the
Quote> most rabid, stubborn, uncooperative IANA apologist that
Quote> could be found on this earth.
In my Humble opinion you're
the best thing to happen to
the IAHC... you are sure to
destroy it's credibility
faster than anyone I know.
Except, perhaps, me...
Internationally Yours,
Bob Allisat tor at wtv.net
Director, (416) 588-0670
World Televirtual Network http://www.wtv.net
PO Box 191 Station E Toronto Ontario Canada M6H 4E2
Received: from ietf.org by ietf.org id aa17699; 8 Nov 96 16:39 EST
Received: from capone.ch.apollo.hp.com by ietf.org id aa17550;
8 Nov 96 16:36 EST
Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA252838890 at capone.ch.apollo.hp.com>; Fri, 8 Nov 1996 16:34:50 -0500
Received: from thunk (sommerfeld at localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id QAA01133; Fri, 8 Nov 1996 16:34:47 -0500 (EST)
Message-Id: <199611082134.QAA01133 at thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: Leonid Egoshin <egoshin at genesyslab.com>
Cc: ietf at ietf.org, lars at anchor.rns.com
Subject: Re: Why More TLDs
In-Reply-To: egoshin's message of Fri, 08 Nov 1996 13:22:35 -0800.
<199611082122.NAA06282 at giant.genesyslab.com>
Date: Fri, 08 Nov 1996 16:34:39 -0500
Sender:ietf-request at ietf.org
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Source-Info: From (or Sender) name not authenticated.
> Yes, but the namespace of _trademarks_ is unique. Of course in the
> area of corresponding laws. And it is possible to create hierarhy .TM
> which would match "hierarhy" of trademarks laws.
Nope. .TM would be, or is, Turkmenistan's top level domain.
Still waiting for someone to register toys.ar.us,
- Bill
Received: from ietf.org by ietf.org id aa17964; 8 Nov 96 16:45 EST
Received: from eunet.EU.net by ietf.org id aa17812; 8 Nov 96 16:42 EST
Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id WAA23017; Fri, 8 Nov 1996 22:41:33 +0100 (MET)
Received: by jotun.EU.net id AA02743
(5.67a/IDA-1.5); Fri, 8 Nov 1996 22:41:33 +0100
Message-Id: <199611082141.AA02743 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <bilse at eu.net>
Date: Fri, 8 Nov 1996 22:41:32 +0100
In-Reply-To: <199611081830.MAA22372 at Mars.mcs.net>
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Karl Denninger <karl at mcs.net>
Subject: Re: IAHC
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
On Nov 8, 12:30, Karl Denninger <karl at mcs.net> wrote:
> > > Sure. But I won't give you 4 (or more) months.
> >
> > So what are you going to do? Sue somebody, as usual?
>
> If someone (including the IAHC) does something which creates a cause of
> action, why wouldn't I?
And taking a little time to evaluate proposals creates a cause
of action? If people don't do as you say, they're wrong?
> Or are we (and the rest of the Internet community) just supposed to "take it
> on the chin" and enjoy it? I think not.
Take what? Are you saying damage is incurred by having people
evaluate and implement something sustainable, instead of just
doing what you say?
> >This is what creates authority, Karl; not
> > jumping up and down, bellowing, and foaming at the mouth.
>
> And people wonder why they end up in kill files.... ad-hominen attacks top
> the list of causes.
An ad hominem attack is one where a person's character is attacked.
I did not attack your character, I said your style is counter-productive.
--
------ ___ --- Per G. Bilse, Mgr Network Operations
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net
Received: from ietf.org by ietf.org id aa18313; 8 Nov 96 16:49 EST
Received: from cnri by ietf.org id aa18063; 8 Nov 96 16:46 EST
Received: from hail.ncr.disa.mil by CNRI.Reston.VA.US id aa22668;
8 Nov 96 16:46 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id MAA05936 for <IETF at cnri.reston.va.us>; Fri, 8 Nov 1996 12:37:52 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA847485969; Fri, 08 Nov 96 12:18:13 EST
Date: Fri, 08 Nov 96 12:18:13 EST
Sender:ietf-request at ietf.org
From: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>
Message-Id: <9610088474.AA847485969 at ncr.disa.mil>
To: IETF at CNRI.Reston.VA.US
Subject: Three Cheers for Jake Feinler !!
Source-Info: From (or Sender) name not authenticated.
There is worthy food for thought, I believe, in the comments of
Jake Feinler below!
THANX Jake for taking the time to provide a very cogent and
statesmanlike perspective on what the IETF is all about!
C.Joe Pasquariello
US/DoD/DISA
[remote, ccMobile, NYC, 08 Nov 96/1207]
______________________________ Forward Header __________________________________
Subject: Re: The cartel begins to crumble?
Author: Jake Feinler <feinler at nsipo.arc.nasa.gov> at smtp
Date: 11/6/96 7:12 PM
Having been the originator of the idea of .com, .edu, .gov, .mil, etc I
have been watching this discussion with some amusement.
I can only say to those whose first language is not English that you are
not alone in feeling some trepidation. I feel great sympathy for ** ANY**
speakers who are willing to step up to the microphone in IETF meetings,
especially if the topic is naming and addressing! That is not an
exercise for the faint of heart.
In the heat of battle and the exchange of ideas, it behooves us all to
remember that we are engaged in an international discussion among peers
and be a little kinder and gentler with each other. As this discussion is
pointing out, what is satire in one background can be insult in another.
Also I might point out that the naming system has held up reasonably well
over several years because of the many ideas and heated discussions that
led to a workable consensus. My suggestion would be to continue this
process of evolution of the naming system until better solutions are
found, and go easy on flames and bashing. IETF is not perfect in its
approach to problem solving, but hey, it's held up as a viable open
technical forum for more than 20 years (thanks to the dedication of many)
and has produced the phenomenon of the Internet, so has to be doing
something right. If you have good ideas get them in there...global
feedback and concensus are what have made the Internet great...it's a
chaotic democracy not a cartel conspiracy.
Signed,
Tattered but still unfurled
Jake Feinler
P.S. These are my own musings and do not represent any organizations with
which I am now or have been affiliated.
==================================================================
Received: from ietf.org by ietf.org id aa20855; 8 Nov 96 17:15 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa20419; 8 Nov 96 17:12 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id RAA15624; Fri, 8 Nov 1996 17:11:24 -0500
Message-Id: <199611082211.RAA15624 at black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Leonid Egoshin <egoshin at genesyslab.com>
Cc: ietf at ietf.org
Subject: Re: Why More TLDs
In-Reply-To: Your message of "Fri, 08 Nov 1996 13:22:35 PST."
<199611082122.NAA06282 at giant.genesyslab.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199611082122.NAA06282 at giant.genesyslab.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_432571060P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 08 Nov 1996 17:11:24 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_432571060P
Content-Type: text/plain; charset=us-ascii
On Fri, 08 Nov 1996 13:22:35 PST, you said:
> Yes, but the namespace of _trademarks_ is unique. Of course in the
> area of corresponding laws. And it is possible to create hierarhy .TM
> which would match "hierarhy" of trademarks laws. And we can register
> company under name if its trademarks.
This doesn't *really* address the issue of multinational companies.
What happens when XYZ Inc of the US and XYZ France, which are 2
seperate businesses that own their trademarks in their respective
contries, both go multi-national? It would be considered Really Bad
if user expectations said "Well, XYZ is trademarked, but XYZ.TM takes
me to the wrong company"....
OK.. you want to make it 'trademark-here.country.tm'? Pop Quiz - in
what country is Honeywell-Bull's trademark held? I know Bull is a
French company, but Honeywell is US-based, so where do I look, under
.US.TM, or .FR.TM?
I'll defer the question of whether "IBM World Trade" (IBM's worldwide
operations) is actually trademarked in every country that IBM does business,
or whether it's trademarked in every country that can *access* IBM World Trade
computers via the Internet. This is just *asking* for trouble, if you
are a user in some recently-founded Balkanize-Europe or African contry,
where IBM does not do business, is not trademarked, but you wish to reach
it anyhow....
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_432571060P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMoOwCtQBOOoptg9JAQFH+QP/aoAlAqi6DWtf7z7B3rVkuFycDFkiZWdu
GuwdWU0E7IAsHq6ca5U35I5+j+0xBowWevCAd55yPb4uXH7OU43c1GI1q+7lalyg
//DS9I9ewSMtJAVuWi4iIllh9wWnGviIvoMTxF82L2m8mLKW5kp/opPHDmE6AOm4
gsNrFOwWuZU=
=zrv+
-----END PGP MESSAGE-----
--==_Exmh_432571060P--
Received: from ietf.org by ietf.org id aa23976; 8 Nov 96 17:46 EST
Received: from nirvana.genesyslab.com by ietf.org id aa23710; 8 Nov 96 17:44 EST
Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id OAA11589; Fri, 8 Nov 1996 14:44:16 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA07907; Fri, 8 Nov 1996 14:43:46 -0800 (PST)
Date: Fri, 8 Nov 1996 14:43:46 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199611082243.OAA07907 at giant.genesyslab.com>
To: Valdis.Kletnieks at vt.edu
Subject: Re: Why More TLDs
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: Valdis.Kletnieks at vt.edu
>
>On Fri, 08 Nov 1996 13:22:35 PST, you said:
>> Yes, but the namespace of _trademarks_ is unique. Of course in the
>> area of corresponding laws. And it is possible to create hierarhy .TM
>> which would match "hierarhy" of trademarks laws. And we can register
>> company under name if its trademarks.
>
>This doesn't *really* address the issue of multinational companies.
>What happens when XYZ Inc of the US and XYZ France, which are 2
>seperate businesses that own their trademarks in their respective
>contries, both go multi-national? It would be considered Really Bad
>if user expectations said "Well, XYZ is trademarked, but XYZ.TM takes
>me to the wrong company"....
>
Any multinational corparation must run in the national law.
And register trademark in all countries. If it want, of course.
If not - I have doubts that it is serious business.
>OK.. you want to make it 'trademark-here.country.tm'? Pop Quiz - in
>what country is Honeywell-Bull's trademark held? I know Bull is a
>French company, but Honeywell is US-based, so where do I look, under
>.US.TM, or .FR.TM?
>
Look at trademark lists - may be this name absent in both countries :-)
And may be IS in both lists (I think so). In this case it would be two
names: Honeywell-Bull.US.TM and Honeywell-Bull.FR.TM pointed to the same
company. Or pointed to different sets of hosts. I think it is more
preferable for most of companies - to point to regional division:
look at fr.oracle.com and us.oracle.com for exam. At least it is definitely used
for mail exchange.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa24486; 8 Nov 96 17:52 EST
Received: from nirvana.genesyslab.com by ietf.org id aa24184; 8 Nov 96 17:51 EST
Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id OAA11640; Fri, 8 Nov 1996 14:47:23 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA07987; Fri, 8 Nov 1996 14:46:52 -0800 (PST)
Date: Fri, 8 Nov 1996 14:46:52 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199611082246.OAA07987 at giant.genesyslab.com>
To: sommerfeld at apollo.hp.com
Subject: Re: Why More TLDs
Cc: ietf at ietf.org, lars at anchor.rns.com
Source-Info: From (or Sender) name not authenticated.
>From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
>
>> Yes, but the namespace of _trademarks_ is unique. Of course in the
>> area of corresponding laws. And it is possible to create hierarhy .TM
>> which would match "hierarhy" of trademarks laws.
>
>Nope. .TM would be, or is, Turkmenistan's top level domain.
>
Ok, let it be .C (Copyright, of course :-)
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa24851; 8 Nov 96 17:56 EST
Received: from zephyr.isi.edu by ietf.org id aa24084; 8 Nov 96 17:49 EST
Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA20896>; Fri, 8 Nov 1996 14:48:43 -0800
Message-Id: <199611082248.AA20896 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2057 on Source Directed Access Control
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 08 Nov 96 14:51:36 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2057:
Title: Source Directed Access Control on the Internet
Author: S. Bradner
Date: November 1996
Mailbox: sob at harvard.edu
Pages: 20
Characters: 56,664
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2057.txt
This memo was developed from a deposition that Scott Bradner submitted
as part of a challenge to the Communications Decency Act of 1996, part
of the Telecommunications Reform Act of 1996. This document may be
useful where descriptions of the way the Internet and its applications
work could help clear up confusion in the technical feasibility of
proposed content control regulations.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961108144252.RFC at ISI.EDU>
SEND /rfc/rfc2057.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2057.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961108144252.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25986; 8 Nov 96 18:12 EST
Received: from SPECTRUM.RNS.COM by ietf.org id aa25878; 8 Nov 96 18:10 EST
Received: from anchor.rns.com by RNS.COM (SMI-8.6/SMI-4.1(Spectrum))
id PAA07855; Fri, 8 Nov 1996 15:01:40 -0800
Received: by anchor.rns.com (SMI-8.6/SMI-SVR4)
id PAA27889; Fri, 8 Nov 1996 15:09:44 -0800
To: ietf at ietf.org
Path: anchor!not-for-mail
Sender:ietf-request at ietf.org
From: Lars Poulsen <lars at anchor.rns.com>
Newsgroups: ietf.misc
Subject: Re: US Top Level Domain
Date: 8 Nov 1996 15:09:43 -0800
Organization: RNS / Meret Communications
Lines: 67
Message-ID: <560ejn$r79 at anchor.rns.com>
References: <01BBCD4C.3102DB60 at webster.unety.net>
Source-Info: From (or Sender) name not authenticated.
On Friday, November 08, 1996 7:20 AM,
Simson L. Garfinkel[SMTP:simsong at VINEYARD.NET] wrote:
>@ US domain used to be a volunteer project. It became a burden for ISI. So they
>@ farmed it out. People who take up regions are allowed to charge.
In article <01BBCD4C.3102DB60 at webster.unety.net>
JimFleming at unety.net (Jim Fleming) writes:
>It is useful to note that this "farming out" was not done with
>an RFC, no fee guidelines have been set, no IAHC had to be
>formed, and the net has not collapsed.
While one could wish that the RFCs documenting the operation of
the US domain had been updated when the procedures changed,
the transition appears to have gone remarkably well.
There have been no wholesale complaints of
- lack of access
- unreasonable fees
- contention for address space
that I am aware of, other than the allegations from the
"AlterNIC mutineers" for which I have not seen specific
examples to back them up.
I attribute this success to someone having had extremely good
judgement in selecting registry delegates to service the local
zones, as well as a good dose of community spirit on behalf
of the delegates in refraining from exploiting the community's
trust. I have heard stories of many national TLDs that have
not had such good luck with their delegations.
---
Someone was suggesting that trademarks form a unique hierachy,
and would be suitable for a TLD. As far as I understand, trademarks
are registered country by country, so if a TM hierachy were
implemented, it would have to be replicated under each national
domain, with a second level for the twenty-some separate market
classifications recognized by the trademark authorities (which I
would expect to have some variations from country to country).
I.e. such a domain would have the form
<name>.<category>.TRADEMARK.US
IBM.OFFICE-EQUIPMENT.TRADEMARK.US
Someone else suggested that if BIND was unable to deal with a
humongous flat namespace, BIND should be rewritten to do that
better. I believe that better hierachical structure will benefit
ANY implementation of a DNS server.
A third correspondent suggested that I save my breath and
sit back and wait until the mutineers fail. Actually, I think
their effort has merit; it is a worthwhile experiment. I just
want their tree to be rooted one level down from the top,
rather than at the root. Less debris to clean up that way,
if they fail to maintain discipline in their structuring
of the name space.
Jim Fleming complains of fees being introduced into (some parts
of ?) the US branch. I think that what he really is unhappy
about is that the fees are modest, so he cannot achieve the
financial independence he desires by operating such a branch.
(For all I know, they are probably informally regulated to be
no higher than InterNIC's fees.)
--
/ Lars Poulsen Internet E-mail: lars at OSICOM.COM
OSICOM Technologies (Internet Business Unit, formerly RNS)
7402 Hollister Avenue Telefax: +1-805-968-8256
Santa Barbara, CA 93117 Telephone: +1-805-562-3158
Received: from ietf.org by ietf.org id aa00051; 8 Nov 96 19:09 EST
Received: from zephyr.isi.edu by ietf.org id aa29873; 8 Nov 96 19:04 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA24826>; Fri, 8 Nov 1996 16:03:32 -0800
Message-Id: <199611090003.AA24826 at zephyr.isi.edu>
To: IETF-Announce: ;
To: Internet-Monthly-Report-People: ;
Subject: Internet Monthly Report for September, 1996
Cc: imr-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 08 Nov 96 16:03:32 PST
Sender:ietf-announce-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
--NextPart
The Internet Monthly Report for September, 1996 is now available
at the following location:
URL= ftp://ftp.isi.edu/in-notes/imr/imr9609.txt
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
Requests to be added or deleted from the IMR report list:
The Internet Monthly Report list is managed by MajorDomo atISI.EDU.
The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be added or deleted from the Internet Monthly report list
should be sent to majordomo at isi.edu with the message body either
subscribe imr or unsubscribe imr.
Requests to be added or deleted from the IETF list should be sent to
ietf-request at ietf.org.
Internet Monthly Report availability via WWW, FTP and EMAIL:
IMR Retrieval using WWW
-----------------------
The URL below may be used in web browsers to access the IMRs. You
will see a list of names in the form IMR9609.TXT. For example,
IMR9609.TXT is the report for September 1996.
URL: ftp://ftp.isi.edu/in-notes/imr
IMR Retrieval using EMAIL via the RFC-INFO Service
--------------------------------------------------
The EMail retrieval system RFC-Info will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to rfc-info at ISI.EDU with
the message body help: ways_to_get_imrs. For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from FTP.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of
the IMR.
For example IMR9609.TXT is the report for September 1996).
Login with FTP username anonymous and password ftp.
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the current IMR.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9609
--OtherAccess
Content-Type: Message/External-body;
name="imr9609.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa00185; 8 Nov 96 19:09 EST
Received: from zephyr.isi.edu by ietf.org id aa29985; 8 Nov 96 19:07 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA24984>; Fri, 8 Nov 1996 16:06:06 -0800
Message-Id: <199611090006.AA24984 at zephyr.isi.edu>
To: ietf at ietf.org, imr at isi.edu
Subject: Internet Monthly Report for September, 1996
Cc: imr-ed at isi.edu
Date: Fri, 08 Nov 96 16:06:06 PST
Sender:ietf-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
Source-Info: From (or Sender) name not authenticated.
September 1996
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to "IMR at ISI.EDU".
`````````````````````````````````````````````````````````````````````
The Internet Monthly Report mailing list is now managed by MajorDomo at
ISI.EDU. The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be ADDED or DELETED from the Internet Monthly report list
should be sent to "majordomo at isi.edu" with the message body either
"subscribe imr" or "unsubscribe imr".
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
or URL: http://www.isi.edu/in-notes/imr/
IMR Editor [Page 1]
Internet Monthly Report September 1996
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 12
Registration Services . . . . . . . . . . . . . . . . . page 12
Directory Services. . . . . . . . . . . . . . . . . . . page 13
US Domain Registry. . . . . . . . . . . . . . . . . . . page 14
MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 18
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 20
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 21
TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 25
IMR Editor [Page 2]
Internet Monthly Report September 1996
INTERNET ARCHITECTURE BOARD
---------------------------
The minutes of the IAB back to 1990 are available for anonymous ftp
access on host ftp.isi.edu, directory /pub/IAB, or via the IAB
World-Wide Web page with URL http://www.iab.org/iab/.
Brian Carpenter IAB Chair
INTERNET ENGINEERING REPORTS
----------------------------
IETF Monthly Report for September, 1996
1. The IETF returns to San Jose, California on December 9-13, 1996.
Our local host will be cisco Systems. The Secretariat will begin
accepting registrations the first part of October. The IETF
opens 1997 in Memphis, Tennessee where Federal Express will be
the host. This meeting will be held April 7-11, 1997. Following
Memphis, the IETF is we returning to Europe and will met in
Munich, Germany August 11-15, 1997, hosted by Digi/ISOC.DE. The
Secretariat is still working on the final meeting of 1997.
Once all the arrangements have been made, notifications will be
sent to the IETF Announcement list. Remember that information
on future IETF meetings can be always be found in the file
0mtg-sites.txt which is located on the IETF shadow directories.
This information can also be viewed from the IETF Home Page on
the Web. The URL is:
http://www.ietf.org
2. The minutes of the IESG teleconferences have been publicly
available on the IETF Shadow directories since 1991. These
files are placed in the /ftp/iesg directory.
The following IESG minutes have been added:
August 22, 1996 (iesg.96-08-22)
September 5, 1996 (iesg.96-09-05)
IMR Editor [Page 3]
Internet Monthly Report September 1996
3. The IESG approved or recommended the following 15 Protocol
Actions during the month of September, 1996:
o RIPng for IPv6 for publication as a Proposed Standard.
o RIPng Protocol Applicability Statement be published as an
Informational RFC.
o RIP-II MD5 Authentication for publication as a Proposed
Standard.
o Common Internet Message Headers be published as an
Informational RFC.
o Requirements for Web Transaction Security be published as an
Informational RFC.
o Multicast Support for Nimrod: Requirements and Solution
Approaches be published as an Informational RFC.
o Mobility Support for Nimrod: Requirements and Solution
Approaches be published as an Informational RFC.
o Definition of X.500 Attribute Types and an Object Class to
Hold Uniform Resource Identifiers (URIs) for publication as
a Proposed Standard.
o The Model Primary Content Type for Multipurpose Internet Mail
Extensions for publication as a Proposed Standard.
o Network Renumbering Overview: Why would I want it and what
is it anyway? be published as an Informational RFC.
o How new BGP Attribute Types are defined be published as an
Informational RFC.
o Generic Security Service Application Program Interface,
Version 2 for publication as a Proposed Standard.
o Internationalization of the Hypertext Markup Language for
publication as a Proposed Standard.
o IMAP/POP AUTHorize Extension for Simple Challenge/Response
for publication as a Proposed Standard.
o IRTF Research Group Guidelines and Procedures for publication
as a Best Current Practices RFC.
IMR Editor [Page 4]
Internet Monthly Report September 1996
4. The IESG issued 9 Last Calls to the IETF during the month of
September, 1996:
o Selection and Operation of Secondary DNS Servers
<draft-ietf-dnsind-2ndry-03> for consideration as a Best
Current Practices RFC.
o Security Extensions For HTML <draft-ietf-wts-shtml-02> for
consideration as a Proposed Standard.
o Clarifications to the DNS Specification
<draft-ietf-dnsind-clarify-01> for consideration as a
Proposed Standard.
o The Secure HyperText Transfer Protocol
<draft-ietf-wts-shttp-03> for consideration as a Proposed
Standard.
o The PPP NetBIOS Frames Control Protocol (NBFCP)
<draft-ietf-pppext-netbios-fcp-08> for consideration as a
Proposed Standard.
o Management Information Base for Frame Relay DTEs
<draft-ietf-iplpdn-frmib-dte-08> (Draft Standard)
o VEMMI URL Specification <draft-mavrakis-vemmi-url-spec-01>
for consideration as a Proposed Standard.
o A File Format for the Exchange of Images in the Internet
<RFC1314> be republished as an Informational RFC.
o The PPP Bandwidth Allocation Protocol (BAP) & The PPP
Bandwidth Allocation Control Protocol (BACP)
<draft-ietf-pppext-bacp-04> for consideration as a Proposed
Standard.
5. Three Working Groups were created during this period:
Extensions to FTP (ftpext)
Uniform Resource Names (urn)
IP over Cable Data Network (ipcdn)
and one working groups concluded:
HyperText Markup Language (html)
IMR Editor [Page 5]
Internet Monthly Report September 1996
6. A total of 76 Internet-Draft actions were taken during the month
of September, 1996:
(Revised draft (o), New Draft(+) )
(ospf) o OSPF Version 2 <draft-ietf-ospf-version2-08.txt>
(iplpdn) o Management Information Base for Frame Relay DTEs
<draft-ietf-iplpdn-frmib-dte-08.txt>
(idmr) o Core Based Trees (CBT) Multicast -- Protocol
Specification <draft-ietf-idmr-cbt-spec-06.txt>
(asid) o Definition of X.500 Attribute Types and an Object
Class to Hold Uniform Resource Identifiers (URIs)
<draft-ietf-asid-x500-url-03.txt>
(ripv2) o RIP-II MD5 Authentication
<draft-ietf-ripv2-md5-04.txt>
(http) o An Extension to HTTP: Digest Access Authentication
<draft-ietf-http-digest-aa-05.txt>
(atommib) o Definitions of Supplemental Managed Objects for ATM
Management <draft-ietf-atommib-atm2-07.txt>
(none) o The auto-submitted e-mail header field
<draft-palme-autosub-01.txt>
(isdnmib) o ISDN Management Information Base
<draft-ietf-isdnmib-snmp-isdn-mib-08.txt>
(idmr) o Internet Group Management Protocol, Version 2
<draft-ietf-idmr-igmp-v2-04.txt>
(idmr) o Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification
<draft-ietf-idmr-pim-sm-spec-06.txt, .ps>
(isdnmib) o Dial Control Management Information Base
<draft-ietf-isdnmib-dial-control-05.txt>
(none) o The Model Primary Content Type for Multipurpose
Internet Mail Extensions
<draft-nelson-model-mail-ext-05.txt>
IMR Editor [Page 6]
Internet Monthly Report September 1996
(trunkmib) o Definitions of Managed Objects for the DS3/E3
Interface Type <draft-ietf-trunkmib-ds3-mib-03.txt>
(trunkmib) o Definitions of Managed Objects for the DS1, E1, DS2
and E2 Interface Types
<draft-ietf-trunkmib-ds1-mib-04.txt>
(none) o ISO Transport Service on top of TCP (ITOT)
<draft-pouffary-itot-03.txt>
(mixer) o X.400 image body parts
<draft-ietf-mixer-images-01.txt>
(hubmib) o Definitions of Managed Objects for IEEE 802.3
Repeater Devices
<draft-ietf-hubmib-repeater-dev-03.txt>
(ids) o The CCSO Nameserver (Ph) Architecture
<draft-ietf-ids-ph-02.txt>
(none) o Bi-directional Tunneling for Mobile IP
<draft-montenegro-tunneling-01.txt>
(idmr) o Protocol Independent Multicast-Dense Mode (PIM-DM):
Protocol Specification
<draft-ietf-idmr-pim-dm-spec-04.txt, .ps>
(ids) o X.500 Implementations Catalog-96
<draft-ietf-ids-x500-imps-03.txt>
(ids) o Managing the X.500 Root Naming Context
<draft-ietf-ids-root-naming-01.txt>
(applmib) o Definitions of Managed Objects for Applications
<draft-ietf-applmib-sysapplmib-03.txt>
(trunkmib) o Definitions of Managed Objects for the DS0 and DS0
Bundle Interface Type
<draft-ietf-trunkmib-ds0-mib-03.txt>
(none) + Dynamic Reassignment of IP Addresses for TCP and UDP
<draft-bound-ipv6-ip-addr-00.txt>
(idmr) o Distance Vector Multicast Routing Protocol
<draft-ietf-idmr-dvmrp-v3-03.txt, .ps>
IMR Editor [Page 7]
Internet Monthly Report September 1996
(ipsec) o Combined DES-CBC, HMAC and Replay Prevention
Security Transform
<draft-ietf-ipsec-esp-des-md5-03.txt>
(dnssec) o Secure Domain Name System Dynamic Update
<draft-ietf-dnssec-update-02.txt>
(none) o IMAP/POP AUTHorize Extension for Simple
Challenge/Response <draft-klensin-cram-02.txt>
(http) o Transparent Content Negotiation in HTTP
<draft-holtman-http-negotiation-03.txt>
(fddimib) o FDDI Management Information Base
<draft-ietf-fddimib-objects-v2-02.txt>
(none) o The ESP Stream Transform
<draft-caronni-esp-stream-01.txt>
(pier) o Network Renumbering Overview: Why would I want it
and what is it anyway?
<draft-ietf-pier-renum-ovrvw-02.txt>
(none) o Voice Profile for Internet Mail - version 2
<draft-ema-vpim-02.txt>
(issll) o IP Integrated Services with RSVP over ATM
<draft-ietf-issll-atm-support-01.txt, .ps>
(issll) + Interoperation of Controlled-Load and
Guaranteed-Service with ATM
<draft-ietf-issll-atm-mapping-00.txt>
(asid) o Lightweight Directory Access Protocol: Extensions
for Dynamic Directory Services
<draft-ietf-asid-ldapv3ext-01.txt>
(none) o SBM (Subnet Bandwidth Manager): A Proposal for
Admission Control over Ethernet
<draft-yavatkar-sbm-ethernet-01.txt>
(none) o Issues affecting MARS Cluster Size
<draft-armitage-ion-cluster-size-01.txt>
(mboned) o Multicast pruning a necessity
<draft-ietf-mboned-pruning-01.txt>
IMR Editor [Page 8]
Internet Monthly Report September 1996
(fddimib) o FDDI Management Information Base in the SNMPv2 SMI
<draft-ietf-fddimib-smiv2-object-v2-01.txt>
(mhtml) o Content-ID and Message-ID Uniform Resource Locators
<draft-ietf-mhtml-cid-01.txt>
(none) o TFTP Multicast Option
<draft-emberson-tftp-multicast-opt-01.txt>
(none) + Domain Names and Company Name Retrieval
<draft-klensin-tld-whois-00.txt>
(none) + Review of Roaming Implementations
<draft-aboba-roam-rev-00.txt>
(none) + Challenge-Handshake Authentication Protocol for
SOCKS V5 <draft-vanheyningen-socks-chap-00.txt>
(none) + IPv4 Address Behaviour Today
<draft-iab-ip-ad-today-00.txt>
(ripv2) + RIP Version 2 Carrying Additional Information
<draft-ietf-ripv2-protocol-v2-00.txt>
(none) + IP Echo Host Service
<draft-rfced-exp-partridge-00.txt>
(none) + V2ToV1 Mapping SNMPv2 onto SNMPv1 within a
bi-lingual SNMP agent
<draft-rfced-info-wijnen-00.txt>
(none) + Requirements on HTTP for Distributed Content Editing
<draft-whitehead-http-distreq-00.txt>
(none) + The Application Configuration Access Protocol in the
Context of Other Internet Protocols
<draft-wall-acap-vsothers-00.txt>
(none) + On Experimental Top Level Domains Rev 0
<draft-collier-brown-itld-exper-00.txt>
(none) + Tag Distribution Protocol
<draft-doolan-tdp-spec-00.txt>
(none) + Firewall Support for Mobile IP
<draft-montenegro-firewall-sup-00.txt>
IMR Editor [Page 9]
Internet Monthly Report September 1996
(none) + S/MIME Message Specification: PKCS Security Services
for MIME <draft-dusse-mime-msg-spec-00.txt>
(none) + Tag Switching Architecture Overview
<draft-rfced-info-rekhter-00.txt>
(none) + Extensions to the MARS model for Integrated Services
<draft-kandlur-issll-rsvp-mars-00.txt>
(pppext) + Layer Two Tunneling Protocol "L2TP"
<draft-ietf-pppext-l2tp-00.txt>
(dnsind) + Simple Transaction Signature for DNS
<draft-ietf-dnsind-tsig-00.txt>
(none) + ATM Virtual Circuit Identification Support for an
RSVP-based Service
<draft-williams-issll-vcuse-00.txt>
(none) + ST2+ over ATM Protocol Specification - UNI 3.1
Version <draft-suzuki-st2-over-atm-00.txt>
(none) + Definitions of Managed Objects for Instance
Reservation <draft-battle-instresmib-00.txt>
(pppext) + Proposal for LCP Authentication Option
<draft-ietf-pppext-linknegot-00.txt>
(pppext) + Proposal for LCP Authentication Option
<draft-ietf-pppext-link-negot-00.txt>
(none) + QOSPPP Framing Extensions to PPP
<draft-andrades-framing-ext-00.txt>
(issll) + The Multi-Class Extension to Multi-Link PPP
<draft-ietf-issll-isslow-mcml-00.txt>
(none) + A Framework for Providing Integrated Services Over
Shared and Switched LAN Technologies
<draft-ghanwani-framework-is-lan-00.txt>
(none) + The IPv6 communication model
<draft-yamamoto-wideipv6-comm-model-00.txt>
(otp) + OTP Extended Responses <draft-ietf-otp-ext-00.txt>
IMR Editor [Page 10]
Internet Monthly Report September 1996
(none) + Limitations of Internet Protocol Suite for
Distributed Simulation in the Large Multicast
Environment <draft-pullen-lame-00.txt>
(none) + A MODEL FOR SECURE CALL-LIKE SESSIONS WITHIN THE
INTERNET <draft-davies-broker-model-00.txt>
(ids) + Internet Nomenclator Project
<draft-ietf-ids-inp-00.txt>
(none) + Electronic Data Interchange MIB (EDIMIB) Version 1
<draft-bolton-edimib-00.txt, .ps>
(pier) + Subnet Lists <draft-ietf-pier-subnet-lists-00.txt>
7. One RFC was published during the month of September, 1996:
RFC St WG Title
------- -- -------- -------------------------------------
RFC1982 PS (dnsind) Serial Number Arithmetic
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( B) Best Current Practice
( E) Experimental
( I) Informational
Steve Coya <scoya at ietf.org>
IMR Editor [Page 11]
Internet Monthly Report September 1996
INTERNET PROJECTS
-----------------
INTERNIC
--------
REGISTRATION SERVICES
---------------------
The Following report covers the months of July, August, and
September:
I. Significant Events
* HostReg and CReg templates are now being processed automatically;
previously they had to be processed manually; now about 50% are
being processed automatically.
* The auto-registration software now sorts requests into six
groups: (1) COM, (2) ORG, (3) NET, (4) GOV, (5) EDU and (6) TLD;
this eliminates a manual step in the process and allows the ability
to put an increased priority on GOV, EDU and TLD requests.
* Plans to initiate a night shift are under development to assist
in reducing the manual processing backlog.
* Informal training was provided for Billing CSRs regarding how to
register as a contact.
* Selection and training of a second shift for processing support
was completed; a full day training class was held on Saturday,
September 10th; final staffing arrangements were completed for a
night shift with a start date of September 30th.
* A "SWAT Team" of existing staff was used to reduce the backlog.
* Fax processing has become an overwhelming problem, requiring over
four full-time equivalent employees.
* Duane Stone and Carley Johnson represented the InterNIC DomReg
Section at Network World Interop.
* Testing of a share-ware Fax Server solution is going very well;
it would make faxes available as e-mail; the fax viewer works very
well on Sparc 5s and also supports sending faxes out; the MTS and
Ack/Nak interfaces still need to be completed.
IMR Editor [Page 12]
Internet Monthly Report September 1996
* DomReg software enhancements have reduced the number of requests
that need to be processed manually from about 1,000 to 700 (30%
improvement).
* A method for gathering performance measurements was finalized and
documented.
II. Current Status
Sept: Email: 210,283
Postal/Fax: 2,026
Phone: 24,806
Gopher connections: 14,275 retrievals: 34,676
WAIS connections: 54,926 retrievals: 29,985
FTP connections: 73,925 retrievals: 155,385
Mailserv: n/a
Telnet: 73,992
Http: 4,673,017
Whois client: 423,835 Whois server: 10,764,238
Rich Landers <richl at internic.net>
INTERNIC DIRECTORY AND DATABASE SERVICES
----------------------------------------
In September, our Harvest gatherer went into production operation.
It currently gathers from our directory of directories pages, and
offers search capabilities beyond those available using WAIS. It
also gives us the ability to index web pages. We expect to index
additional resources from inside and outside the InterNIC over
time.
To try out this system, look at:
http://ds.internic.net/Harvest/brokers/dod/query.html
To track new features on our servers, visit our "New Stuff" page:
http://ds.internic.net/new/newstuff.html
This page is updated regularly.
IMR Editor [Page 13]
Internet Monthly Report September 1996
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories. If you prefer, you can enter information
about your resource in our WWW suggestion form. The form can be
reached through our Directory of Directories Web page at:
http://ds.internic.net:80/ds/dsdirofdirs.html
by Rick Huber <rvh at ds.internic.net>
THE US DOMAIN REGISTRY
----------------------
The US Domain now has an online line registration form.
Some of the processing of the requests to the third level domain
name is now automated. In particular, most requests to register
names in localities already delegated are automatically forwarded
to the administrator for that locality.
The US Domain administrator no longer makes direct registrations of
hosts, and only makes delegations of third or fourth level domain
names (such as localities).
A new policy has been added to the criteria for delegating domain
names under the US Domain:
It is the intention that the delegation of third level (for
example, locality) domain names be wide spread to many
registries. It is undesirable for one person or organization
to manage a large part of the third level names in any
particular geographic or logical area.
No individual or organization shall have more than 500
delegations total in the US Domain as a whole, or more than 50
delegation in any particuilar second level (for example, a
state).
About the special domains under the state codes.
The K12, CC, TEC, LIB, STATE, DST, COG and GEN domain under
each state are established for special purposes (see RFC 1480).
IMR Editor [Page 14]
Internet Monthly Report September 1996
In addition to the constaint to use them only for the
defined purpose, each of these special domains is also
to delegated only to a manager within the state, and the
operation of the delegated registry should be non-profit.
The LIB domain should be managed by a govermental or
educational library organization.
Further, it is most appropriate for the K12, CC, and TEC,
domains to be managed by an educational organization (for
example, a university or a department of education).
The STATE domain is most appropriately managed by an agency
of the state government. DST and COG should be managed by a
goverment agency.
The GEN domain may be delegated to any organization that
will provide the registration service for free (and remember
the purpose of the GEN domain is to register statewide
non-profit organizations).
To obtain a copy of the list of other delegated localities and
subdomains not administered by the US Domain Registrar, get the
file "us-domain-delegated.txt".
URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt
For further information about the US Domain, send a message to:
US-DOMAIN at ISI.EDU, or see our WEB page:
http://www.isi.edu/us-domain
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 3101
PHONE 500
----------------------------
Total Contacts 3601
DELEGATIONS 137
FORWARDED DELEGATIONS: 972
OTHER US DOMAIN MSGS: 2492
---------------------------
Total 3601
IMR Editor [Page 15]
Internet Monthly Report September 1996
OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or
to/from the InterNic, phone calls, modifications, application
requests, discussion and clarification of the requests, questions
about names, resolving technical problems with zone files and name
servers, and whois listings.
In addition, and not listed below, another 398 localities have been
delegated in Arizona, Arkansas, California, Colorado, Connecticut,
Massachusetts, Maryland, Missouri, Montana, Michigan , Mississippi,
North Carolina, New Jersey, New York, Virginia, Vermont, this month.
MAJOR SUBDOMAINS DELEGATED
K12 CC TEC STATE LIB MUS GEN DST COG
===================================================================
51 37 34 47 39 23 24 9 4
===================================================================
-----------------------
THIRD LEVEL DELEGATIONS
-----------------------
CC.AL.US Community Colleges, Alabama.
LIB.AR.US Libraries, Arkansas.
TEC.AR.US Technical Schools, Arkansas.
GEN.AR.US General, Arkansas.
CC.AR.US Community Colleges, Arkansas.
LOCALITIES
==========
CHEYENNE-ARAPAHO.NSN.US. WESTFIELD.IN.US.
BEANBLOSSOM.IN.US. ATLANTA.GA.US.
COLORADO-SPRINGS.CO.US. LEES-SUMMIT.MO.US
MIDFIELD.AL.US. CITY-OF-COMMERCE.CA.US.
OAK-BLUFFS.MA.US. ALBEMARLE.NC.US.
LAYTONSVILLE.MD.US. BRUNSWICK.OH.US.
GILPIN.CO.US. SULLIVAN.TN.US.
DIAMONDHEAD.MS.US. GREENE.OH.US.
NEW-HANOVER.NC.US. ASHEVILLE.NC.US.
COBURG.OR.US. WAVELAND.MS.US.
WASHTENAW.MI.US. EATON.MI.US.
COLTS-NECK.NJ.US. SUFFOLK.VA.US.
FREMONT.CA.US. PLEASANTON.CA.US.
COLTS-NECK.NJ.US. SUFFOLK.VA.US.
IMR Editor [Page 16]
Internet Monthly Report September 1996
FREMONT.CA.US. PLEASANTON.CA.US.
ROCHESTER.NH.US. HAYWARD.CA.US.
MANCHESTER.VT.US. BAY-ST-LOUIS.MS.US.
LITTLEROCK.CA.US.
OTHER US DOMAIN DELEGATIONS THIS MONTH
--------------------------------------
TOWN.HIGHLAND.NY.US. TWP.SCIO.MI.US.
HEALTH.CO.HERKIMER.NY.US. BARTLESVILLE.LIB.OK.US.
GOODMAN.SUNBURY.PA.US. LAKEMED.CUMBERLAND.ME.US.
MSAS.GEN.MI.US. CALVARY.GEN.MI.US.
CI.BIG-BEAR-LAKE.CA.US. HAMPTON.LIB.NH.US.
CO.NEVADA.CA.US. SRVFPD.DST.CA.US.
INFO.WASHINGTON.DC.US. NSCC.CC.MA.US.
CI.MADISON.NH.US. MADISON.LIB.NH.US.
HILLSML.LIB.NH.US. FRIEDMAN.MOUNTAIN-VIEW.CA.US.
CI.WOODSTOCK.IL.US. MILIND-MARTHE.LARAMIE.WY.US.
PARADOX.WESTCHESSTER.CA.US. ONEWORD.READING-CENTER.NY.US.
FORD.DEARBORN.MI.US. CI.CRESTLINE.OH.US.
CI.EVERETT.WA.US. TOM.AGOURA.CA.US.
YV.COG.WA.US. WWW.WASHINGTON.DC.US.
PORTERCO.CO.PORTER.IN.US. MAGISTRATE.COG.GA.US.
TOWNSHIP.MONROE.NJ.US. GCIT.TEC.NJ.US.
CI.NEWMAN-GROVE.NE.US. CI.LEWISTON.NE.US.
SCVWD.DST.CA.US. WWW.CO.GWINNETT.GA.US.
PICHER.K12.OK.US. CI.FAIRFIELD.OH.US.
CPI.NEW-YORK.NY.US. CI.SCHUYLER.NE.US.
ECDEV.COVINA.CA.US. CI.MUKILTEO.WA.US.
ASPENTREE.LARAMIE.WY.US. METRO.WASHINGTON.DC.US.
ABNAMRO.CHICAGO.IL.US. ECPUBL.LIB.CA.US.
WMRLS.LIB.MA.US. TOWN.CHEVERLY.MD.US.
SPIDERNET.CHAUTAUQUA.NY.US. SHERIFF.FRANKLIN.OH.US.
KONAWA.K12.OK.US. CI.OAKLAND.NE.US.
PETERSON.HAYWARD.CA.US. CI.HUMBOLDT.NE.US.
CI.WAYNE.NE.US. CI.EUSTIS.NE.US.
CI.SHELBY.NE.US. CI.OSCEOLA.NE.US.
HEALTH.CO.MONROE.NY.US. CO.MADISON.NY.US.
SOPHIA2.SOMERVILLE.MA.US. CI.BARRINGTON-HILLS.IL.US.
CI.NEWARK.OH.US. AMB.CARMEL-VALLEY.CA.US.
CMASS.GEN.MA.US. CO.BUTTE.CA.US.
CO.ALLEN.IN.US. CI.HESPERIA.CA.US.
CHAMBER.DEMOPOLIS.AL.US. CI.FLAT-ROCK.MI.US.
CO.ALLEN.IN.US. CI.HESPERIA.CA.US.
CHAMBER.DEMOPOLIS.AL.US. CI.FLAT-ROCK.MI.US.
SVAHA.YELLOW-SPRINGS.OH.US. WMC.WRIGHTSVILLE.AR.US.
STPAT.GEN.MI.US. JAYCEES.GEN.MI.US.
IMR Editor [Page 17]
Internet Monthly Report September 1996
CI.LAGUNA-HILLS.CA.US. LSCS.LAKE-STATION.IN.US.
CI.MANCHESTER.NH.US. VAMPIRES.IRVING.TX.US.
BOSCOTECH.TEC.CA.US. FLINT.HARTLAND.MI.US.
COLEMAN.HADLYME.CT.US. CI.CREIGHTON.NE.US.
CI.WASHINGTON.DC.US. EIGHTCAP.GEN.MI.US.
CI.RUSHVILLE.NE.US. MIKESUN.HOLMDEL.NJ.US.
CI.SAN-PABLO.CA.US. TOWN.ANDOVER.MA.US.
FIRSTCITY.LIB.AK.US. HEALTH.CO.ORLEANS.NY.US.
RAPTOR.BENTON.KS.US. STANG.MOUNDRIDGE.KS.US.
HATHBURN.NIOTA.TN.US. GREGNET.ROYERSFORD.PA.US.
CI.TARBORO.NC.US. BAYPATH.TEC.MA.US.
ANTIOCH.YELLOW-SPRINGS.OH.US. LOOPEXPERT.BRIDGEWATER.NJ.US.
TOMLINSON.LPS.K12.OK.US. SCHOLASTICA.CHICAGO.IL.US.
QAR.OAK-PARK.CA.US. CO.JOHNSTON.NC.US.
CI.WALNUT.CA.US. CI.BAYTOWN.TX.US.
AGRANENTERPRISES.ATLANTA.GA.US. CRAIGSWORLD.FT-LAUDERDALE.FL.US.
LAKESREGIONOFMAINE.GEN.ME.US. DHS.CO.FAIRFIELD.OH.US.
TWP.CARNEYS-POINT.NJ.US. BREEDERS-REGISTRY.GEN.CA.US.
MCS.GEN.ME.US. SKIPATROL.MT-HOOD.OR.US.
CO.CULPEPER.VA.US. CI.PLEASANTON.CA.US.
-----------------------------------------------------------
URL: http://www.isi.edu/us-domain/
Shanthi Ranganathan (US-Domain at ISI.EDU)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MERIT INTERNET ENGINEERING
--------------------------
This report summarizes September 1996 activities of Merit's
Internet Engineering group on behalf of the Routing Arbiter (RA)
service and other projects.
The National Science Foundation has announced a new direction for
the Routing Arbiter project, which was charged by NSF in 1994 with
the task of providing routing coordination in the post-NSFNET
environment. The announcement, which followed the 24-month review
of the Routing Arbiter and the four Network Access Point projects,
noted that all these projects had completed their basic missions
ahead of schedule. The RA project is a partnership between Merit
and the University of Southern California Information Sciences
Institute. George Strawn, networking division director at the NSF,
commended the Routing Arbiter for its performance during the past
two years, and noted that the Routing Arbiter and the NAPs "have
IMR Editor [Page 18]
Internet Monthly Report September 1996
now proven that multiple network providers can work together in a
competitive marketplace, and so can be scheduled for transition to
commercial operations themselves." NSFNET program director Mark
Luker said that researchers from the RA and the NAPs will now focus
on connections and routing for advanced networking, and noted that
"both actions help NSF to move to the next stage, a stronger focus
on the high-performance Internet of the future needed to support
today's advanced research." Merit is working with NSF to define
its refocused activities for the RA project.
Elise Gerich, Associate Director of Merit for National Networking,
resigned her position to take a job in private industry. Elise
joined Merit in 1987 in support of the NSFNET Backbone Service
project, and focused on technical interfaces and policy
interactions between the regional networks, sister Federal
agencies, and international network research organizations. She
was named Manager of the Internet Engineering group in 1994, was
promoted to Associate Director in July 1995, and was also a Co-
Principal Investigator for the Routing Arbiter project. Elise was
instrumental in providing a smooth transition for the regional
networks to the new NSFNET architecture. We wish her continued
success in her new position!
Merit invites applications for both the Associate Director and
Manager of Internet Engineering positions; for further information,
contact Merit President Eric Aupperle (313/764-9430,
ema at merit.edu).
Last month's report described a new incremental update client
implemented for the Routing Arbiter Database by Jerry Winters. At
that writing, the client was polling the RIPE registry's mirroring
site every 30 minutes for database updates; previously, updates had
only been provided once each day. The new client is now polling
the RIPE site every 15 minutes; eventually, Merit expects that
polls will occur every five minutes.
A new tool known as IPN, Inter-Provider Notification, is now
available on the RA Web pages:
http://compute.merit.edu/ipn.html
IMR Editor [Page 19]
Internet Monthly Report September 1996
IPN is a public bulletin board that Internet Service Providers and
NAP operators can use to announce scheduled maintenance and ongoing
network outages. IPN participants include major Internet Service
Providers who BGP-peer at one or more of the primary exchange
points. We encourage providers to participate in testing and
developing the new tool; improved coordination and cooperation
among providers will lead to a better-managed and more stable
Internet. To join the IPN, send e-mail to:
outage at ra.net
Brian Renaud attended the 25th RIPE meeting in Amsterdam, where he
participated in sessions of the Routing and Database Working
Groups.
Susan R. Harris (srh at merit.edu)
UCL
----
Finally, the effort on the Merci project has paid off, with help
from HP and LBL, and the audio, text and (LBNL) video tools rat,
nte and vic all work on the various Microsoft Windows platforms.
Availability soon.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
IMR Editor [Page 20]
Internet Monthly Report September 1996
CALENDAR
--------
Last update 10/9/96
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at ietf.org>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
FYI - The EMail World & Internet World originally scheduled for
Sept. 10-12, 1996 has been moved to Oct. 15-17, 1996. Boston, MA.
A copy of this calendar is available as follows:
VIA FTP
------
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
Africa Address: ftp.is.co.za (196.4.160.12)
cd ietf
ls *0mtg*
WWW
-------
<http://www.ietf.org/home.html> Click on the link for "meetings" and
you should find an entry "listing of other Internet related events".
************************************************************************
1996
-----------
Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL
Oct. 7-11 ATM Forum Montreux, Switzerland
IMR Editor [Page 21]
Internet Monthly Report September 1996
Oct. 7-11 NetWorld+Interop Paris, France
Oct. 7-11 Performance 96 Conference Lausanne, Switzerland
Oct. 9-11 Object World Frankfurt Frankfurt, Germany
Oct. 13-16 IEEE Local Computer Ntwrks (LCN) Minneapolis, MN
Oct. 14-17 MEDNET '96 European Congress
of the Internet in Medicine Brighton, UK
Oct. 15 Commercenet New Orleans, LA
Oct. 15-17 EMail World & Internet Expo Boston, MA
Oct. 15-18 3rd Int'l on Protocols for
Multimedia Systems Madrid, Spain
Oct. 16-18 Internet World Monterrey '96 Monterrey, Mexico
Oct. 16-19 5th Int'l Conference on
Computer Communications & Ntwrks Rockville, MD
Oct. 17-20 IEEE Symposium on Planning & Design
of Broadband Networks Quebec, Canada
Oct. 21-22 FNC Advisory Committee Arlington, VA
Oct. 21-23 Integrated Office Conf '96 San Diego, CA
Oct. 21-25 ICECCS'96 (held jointly with
6th CSESAW, 4th IEEE RTAW) Montreal, Canada
Oct. 24-25 2nd IEEE Wrkshop on Wireless LANs Worcester, MA
Oct. 28-31 2nd USENIX Seattle, WA
Oct. 28-Nov. 1 NetWorld+Interop London, England
Oct. 29-31 Internet Professional '96 Paris, France
Oct. 29-Nov. 1 ICNP-96 Int'l Conf. on
Network Protocols Columbus, Ohio
Oct. 29-Nov. 1 2nd USENIX Symp. Operating Sys.
Design & Implement. (OSIDI II) Seattle, WA
Nov. 1996 OMG TC (Groupe Bull) Nice, France
Nov. 4-6 APPN Implementers Workshop Raleigh, NC
Nov. 4-8 ANSI X3T10 '96 Western Digital Palm Springs, CA
Nov. 5-6 7th Maryland Workshop on
Very High Speed Networks Balitmore, MD
Nov. 6-8 Web Developer Mexico '96 Mexico Ciy, Mexico
Nov. 10-12 2nd annual of ACM's MobiCom '96 Rye, New York
Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada
Nov. 12-15 3rd Int'l Conf.
on Multimedia Modeling Toulouse, France
Nov. 13 Commercenet Santa Clara, CA
Nov. 18-20 2nd USENIX Workshop on
Electronic Commerce Oakland, CA
Nov. 18-22 ACM Multimedia '96 Boston, MA
Nov. 18-22 IEEE Globecom 96 London, England
Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA
Nov. 20-21 IEEE Global Internet '96 London, UK
Nov. 25-29 NetWorld+Interop Sydney, Australia
Dec. 2-4 Web World San Diego, CA
Dec. 2-6 ANSI X3T11 (host by IBM) Minneapolis, MN
Dec. 2-6 ATM Forum Vancover, BC
IMR Editor [Page 22]
Internet Monthly Report September 1996
Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA
Dec. 9-12 Internet World '96 Baltimore, MD
Dec. 9-13 37th IETF (host by cisco) San Jose, CA
Dec. 9-13 OIW (Firm)
Dec. 10-13 Fall Internet World '96 New York, NY
Dec. 12 Internet Security for System
& Network Administrators Pittsburgh, PA
Dec. 13 Commercenet Albuquerque, NM
1997
-----------
Jan. 6-10 ANSI X3T10 '97
Jan. 6-10 USENIX '97
Annual Technical Conf. Anaheim, CA
Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA
Jan. 7-10 13th Annual Hawaii Int'l Conf
on Systems Sciences Maui, Hawaii
Jan. 7-10 Internet World Canada '97 Toronto, Canada
Jan. 21-23 Internet World Shanghai-China Shanghai, China
Jan. 21-25 Internet World Singapore Intl Singapore
Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL
Feb. 3-7 ANSI X3T11 (host by Sun) San Jose, CA
Feb. 9-15 ATM Forum San Diego, CA
Feb. 10-11 ISOC Symposium on Network and
Distributed System Security San Diego, CA
Feb. 17-19 Internet Expo & EMail World San Jose, CA
Mar. 1-5 ACM '97: The Next 50 yrs. of Computing
San Jose, CA
Mar. 10-13 UniForum San Francisco, CA
Mar. 10-14 OIW (Firm)
Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque
Mar. 11-14 Spring Internet World '97 Los Angeles, CA
Mar. 11-15 ANSI X3T10 '97
Mar. 17-19 1st Euromicro Working Conf. on
Software Maintenance & Reengineering
Berlin, Germany
Mar. 19-21 Internet World Asia '97 Kuala Lumpur, Malaysia
Mar. 24-27 APPN Implementers Workshop Raleigh, NC
Apr. 7-11 38th IETF (host by Fed. Exp) Memphis, TN
Apr. 7-11 ANSI X3T11 (Brocade) Palm Springs, CA
Apr. 7-11 IEEE Infocom '97 Kobe, Japan
Apr. 9-11 ISADS 97 - 3rd Intl Symposium on
Autonmous Decentralized Sys. Berlin, Germany
Apr. 22-24 Internet Expo & EMail World Chicago, IL
Apr. 27-May 3 ATM Forum Chicago, IL
May 5-9 ANSI X3T10 '97
May 12-15 8th JENC8 Edinburgh, Scotland
May 12-16 IFIP/IEEE San Diego, CA
IMR Editor [Page 23]
Internet Monthly Report September 1996
May 19-21 7th Int'l Workshop on Ntwk & Oper
for Digital Audio & Video St. Louis, MO
May 28-30 Web Developer '97 Chicago, IL
Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico
Jun. 8-12 ICC '97 (joint with ENM) Montreal, CANADA
Jun. 9-13 OIW (Firm)
Jun. 9-13 ANSI X3T11 (host by Boeing) Seattle, WA
Jun. 24-27 INET '97 Kuala Lumpur, Malaysia
Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI
Jul. 14-18 ANSI X3T10 '97
Jul. 14-17 APPN Implementers Workshop San Jose, CA
Jul. 20-26 ATM Forum Montreal, CANADA
Aug. 4-8 ANSI X3T11 (host by Hitachi) Honolulu, HI
Aug. 11-15 39th IETF (host by German ISOC) Munich, Germany
Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA
Sep. 8-12 ANSI X3T10 '97
Sep. 8-12 OIW (Firm)
Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland
Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France
Oct. 6-10 ANSI X3T11 (host by FSI) Tucson, AZ
Nov. 3-7 ANSI X3T10 '97
Nov. 30-Dec 6 ATM Forum Singapore
Dec. 1-5 ANSI X3T11 (host by DPT) Orlando, FL
Dec. 8-12 40th IETF (tentative) Univ. of Hawaii
Dec. 8-12 OIW (Firm)
TELECOM '97 Asia (Venue and Dates to be Determined)
1998
-----------
SPRING 1998 TELECOM '97 Africa Midrand, South Africa
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
1999
-----
Oct. 8-14 TELECOM '99 Geneva, Switzerland
IMR Editor [Page 24]
Internet Monthly Report September 1996
TERENA List of Meetings
=======================
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact
the chair of the meeting or the TERENA Secretariat. If you have
additions/corrections/comments, please mail <secretariat at terena.nl>.
**********************************************************************
MEETING/DATE LOCATION
============ ========
TERENA General Assembly
-----------------------
GA6
24-25 October Bled
GA7
15-16 May 1997 Edinburgh
TERENA Executive Committee
--------------------------
17 December Amsterdam
TERENA Technical Committee
--------------------------
13 November Brussels
22 January 1997 Amsterdam
TERENA Office Meeting
---------------------
16 October Amsterdam
JENC8
-----
Conference Committee
8 November (provisional) Edinburgh
Programme Committee
4 December Amsterdam
IMR Editor [Page 25]
Internet Monthly Report September 1996
INSIGHT Training Workshop
-------
28-29 October Bled
CEEnet
------
26 October Bled
PHARE Research Networking
------
25 October Bled
-----------------------------------------------------------------
=================================================================
EEMA
----
Electronic Commerce '96 Wembley, London
15-17 October
Regional Conference
29 November - 1 December Malta
Electronic Communications Olympia, London
10-12 December
EWOS
----
TA35, 3-4 December Brussels
TA36, 25-26 February 1997 "
TA37, 13-14 May 1997 "
TA38, 16-17 September 1997 "
TA39, 2-3 December 1997 "
SC - 24 September "
SC - 17 December "
Workshops
35: 21-25 October Brussels
36: 20-24 January 1997 "
37: 7-11 April 1997 "
38: 16-20 June 1997 "
39: 27-31 October 1997 "
IMR Editor [Page 26]
Internet Monthly Report September 1996
ETSI
----
Seminar/Workshop
1-3 October Nice, France
GA24 10-11 December Nice, France
TA25 23-25 October "
IETF
----
9-13 December San Jose, CA
7-11 April 1997 Memphis, Tenn.
11-15 August 1997 Munich, Germany
RIPE
----
RIPE26
20-22 January 1997 Amsterdam
RIPE27
May 1997 Dublin
NATO Workshop
-------------
5-9 May 1997 Edinburgh
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TERENA CONFERENCES
------------------
Call for Papers
JENC8 - 8th Joint European Networking Conference
------------------------------------------------
"Diversity and Integration: The New European Networking Landscape"
12-15 May 1997
Edinburgh, Scotland
This conference will be the European Forum to get up-to-date
information, to debate and assess the new deregulated tele-
communication environment in Europe, new leading-edge applications,
and the network/internetwork support infrastructure which is
currently being developed
IMR Editor [Page 27]
Internet Monthly Report September 1996
Subject Areas:
* Emerging Network Technologies and Network Engineering
* User Support, Training and Education
* Security and Management Issues
* Information Systems and Distributed Applications
* Economic and Political Issues
Deadline for paper submission 10 November 1996 to:
<jen8-submit at terena.nl>
For information please contact the JENC8 Secretariat at:
TERENA Secretariat
Singel 466-468
1017 AW Amsterdam, The Netherlands
tel: +31 20 6391131 fax: +31 20 6393289
email: <jenc8-sec at terena.nl>
http://www.terena.nl/jenc8
or
JENC8 Local Organization
c/o Concorde Services Ltd
Unit 5, SECC
Glasgow, G3 8YW, Scotland
email: <jenc8 at ed.ac.uk>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OTHER CONFERENCES:
-----------------
Performance '96
---------------
International Conference on Performance Theory, Measurement and
Evaluation of Computer and Communications Systems
Organized by IFIPWG7.3
7-11 October
Ecole Polytechnique Federal de Lausanne, Lausanne, Switzerland
Deadline paper submission 15 March 1996
Further information on WWW Page: http://lrcwww.epfl.ch/perf96/
IMR Editor [Page 28]
Internet Monthly Report September 1996
PROMS'96
Third International Workshop on Protocols for Multimedia Systems
----------------------------------------------------------------
15-18 October
Madrid, Spain
This workshop is intended to contribute to scientific, strategical
and practical cooperation between research institutes and industrial
companies in the area of distributed multimedia applications, protocols,
and intelligent management tools, with emphasis on their usage on
broadband networks.
Papers to be submitted by 7 June.
For information contact Arturo Azcorra at <aazcorra at dit.upm.es>
6th CEN/CENELEC/ETSI Conference 1996
--------------------------------
5-6 November
Sheraton Brussels Hotel, Brussels, Belgium
Theme of this conference is "Standards on Trial: Case Studies in
European Standardization"
Deadline for abstracts is 13 Sept. For further information:
c/o CENELAC, Tel: +32 2 519 6871 Fax: +32 2 519 6919
IDATE96
18th International Conference of IDATE
--------------------------------------
6-8 November
Montpellier, France
An opportunity for professional contacts with major industrial
group leaders, users and clients, researchers and academics,
administrators and politians.
Full details of the conference available on the Web:
http://www.idate.fr
CEN/TC304 - Character Set Technology Workshop
---------------------------------------------
11-12 November
Bled, Slovenia
Providing multilingual support in middleware: Implementing the
Universal Character Set ISO 10646 in the European Information Society
For information look up URL: http://www.e5.ijs.si/i18n/ws-bled.html
IMR Editor [Page 29]
Internet Monthly Report September 1996
"The Telematics Revolution,
Consequences for Individuals and Organisations"
----------------------------------------------
13 November
University of Technology, Eindhoven, the Netherlands
Theme of the conference is that progress of information and
telecommunication technologies do create a huge number of questions,
be it social, jurisdictional, economic or technical.
Parallel sessions will deal with: interactive scientific visual-
isation, tele-learning, user aspects of multimedia, distant
consultation and using of laboratories.
For all information and to receive brochure, contact
Mr. Marc Fleskens at email address <telematics at tue.nl>
IEEE Global Internet 1996
-------------------------
20-21 November
Queen Elizabeth II Conference Centre, London
This mini-conference will provide an open forum for the communications
and computer networking communities to review the state-of-the-art
technologies and applications of the evolving Global Internet.
Deadline paper submissions 15 May to:
http://gaia.cs.umass.edu:80/tccc/internet96/
or email Jon Crowcroft <jon at cs.ucl.ac.uk>
WEB INTERNATIONALIZATION & MULTILINGUISM SYMPOSIUM
--------------------------------------------------
20-22 November
Sevilla, Spain
Organized by Sadiel and the WWW Consortium, with the support of the
European Commission. The object of this symposium is the advancement
of the internationalization and multilingualism of the Web, as well
as to seek agreement on the relevant standards.
Registration from 15 September.
For further information see:
http://www.w3.org/pub/WWW/International/Sevilla-96
IMR Editor [Page 30]
Internet Monthly Report September 1996
EITC'96 - European IT Conference
--------------------------------
25-27 November
Congress Centre, Brussels, Belgium
"Doing Business in the Information Society"
Electronic commerce, provides the focus for sessions on IT
applications, enabling technologies and international initiatives.
Post-Conference Workshops to be held on 28 November.
For information contact European Commission, DGIII or
WWW: http://www.cordis.lu/esprit/src/eitc96.htm
ASIAN'96 - Asian Computing Science Conference
---------------------------------------------
2-5 December
Singapore
Themes of this conference is:
- Programming (sematics, languages, systems, ...)
- Concurrency & Parallelism (algorithms, formalisms, systems ...)
- Networking & Security (algorithms, protocols, formalisms, ...)
Additional information available from:
http://www.escs.nus.sg/~asian96
Multimedia Computing and Networking 1997
----------------------------------------
10-12 February 1997
San Jose, CA, USA
The object of this conference is to bring together researchers,
developers, and practitioners working in all facets of multimedia
computing and networking.
Paper submission by 16 July 1996.
For further information email <mmcn at cs.utexas.edu>
COREC -"Interregional Cooperation in RTD - Challenges and
Opportunities for Regions in Economic Conversion"
---------------------------------------------------------
16-17 December
Bremen, Germany
Background is the experience of the community initiative STRIDE and
other programmes of the European Commission.The conference will deal
questions of RTD-programmes and policies, their European Dimension
and impact on regional development.
For information contact Mr. Wolfgang Petzold at:
email <wmte at uni-bremen.de>
IMR Editor [Page 31]
Internet Monthly Report September 1996
IEEE INFOCOM '97
16th Annual Joint Conference of the IEEE
Computer & Communications Societies
----------------------------------------
7-11 April 1997
Kobe, Japan
Paper submissions by 14 June 1997.
For further information contact
http://www.ics.uci.edu/~infocom/
http:// arpeggio.ics.es.osaka-u.ac.jp/infocom.html
ISADS 97
3rd International Symposium on Autonomous Decentralized Systems
---------------------------------------------------------------
9-11 April 1997
Berlin, Germany
Supported by Hitachi, DeTeBerkom, NEC, Digital, GMD-FOCUS,
Hewlett Packard, IBM.
The focus will be on advancements and innovations in ADS platforms
and applications. Integration of telecommunication and computing
aspects into a uniform concept for providing an open distributed
processing environment.
For information see WWW: http://www.fokus.gmd.de/ws/isads97/
EEMA'97
10th Annual Conference of European Electronic Messaging Association
-------------------------------------------------------------------
16-19 June 1997
Maastricht Exhibition and Congress Centre, Maastricht, Netherlands
Issues of the conference will be:
Global Security; Corporate Directories; Messaging Products & Services;
Electronic Commerce; Global Messaging Enterprise; European Initiatives;
Mobile Messaging Technology; Messaging Technology & Management
Strategy; Intranet; World Wide Web & Infobots.
For information contact WWW: http://www.eema.org/
IMR Editor [Page 32]
Internet Monthly Report September 1996
INET'97
The Internet: The Global Frontiers
----------------------------------
24-27 June 1997
Kuala Lumpur, Malaysia
The conference will address the traditional and evolving frontiers
of the Internet as well as its significant impact on education,
commerce and societies throughout the world.
Abstracts of papers to be submitted by 10 October.
-for details of submission procedure
email <inet-program-interest at isoc.org>
-for program information email <inet-program-chair at isoc.org
-for general information email <inet'97 at isoc.org>
====================================================
This meeting list is also available on our WWW page:
http://www.terena.nl/news/
====================================================
IMR Editor [Page 33]
Received: from ietf.org by ietf.org id aa00278; 8 Nov 96 19:10 EST
Received: from service.esys.ca by ietf.org id aa00064; 8 Nov 96 19:08 EST
Received: from monet.esys.ca by service.esys.ca with smtp
(Smail3.1.28.1 #1) id m0vM0vP-000UmhC; Fri, 8 Nov 96 17:05 MST
Received: from multivac.orthanc.com by monet.esys.ca with smtp
(Smail3.1.28.1 #6) id m0vM0z1-000RWwC; Fri, 8 Nov 96 17:09 MST
Received: from localhost (lyndon at localhost) by multivac.orthanc.com (8.8.0/8.8.0) with SMTP id RAA00508; Fri, 8 Nov 1996 17:08:48 -0700 (MST)
Date: Fri, 8 Nov 1996 17:08:48 -0700 (MST)
Sender:ietf-request at ietf.org
From: Lyndon Nerenberg <lyndon at orthanc.com>
To: Leonid Egoshin <egoshin at genesyslab.com>
cc: ietf at ietf.org, lars at anchor.rns.com
Subject: Re: Why More TLDs
In-Reply-To: <199611082122.NAA06282 at giant.genesyslab.com>
Message-ID: <Pine.BSI.3.95.961108170734.444C-100000 at multivac.orthanc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 8 Nov 1996, Leonid Egoshin wrote:
> Yes, but the namespace of _trademarks_ is unique. Of course in the
> area of corresponding laws. And it is possible to create hierarhy .TM
> which would match "hierarhy" of trademarks laws. And we can register
> company under name if its trademarks.
Since the trademark space is not globally unique this would have to be
.<country>.TM.
--lyndon
Received: from ietf.org by ietf.org id aa00275; 8 Nov 96 19:10 EST
Received: from sjf-mail20.sjf.novell.com by ietf.org id aa00065;
8 Nov 96 19:08 EST
Received: from INET-SJF-Message_Server by novell.com
with Novell_GroupWise; Fri, 08 Nov 1996 16:01:23 -0800
Message-Id: <s2835953.058 at novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 08 Nov 1996 16:00:49 -0800
Sender:ietf-request at ietf.org
From: Skip Addison <SKIP_ADDISON at novell.com>
To: egoshin at genesyslab.com, ietf at ietf.org
Subject: Re: Why More TLDs -Reply
Source-Info: From (or Sender) name not authenticated.
Trademarks are not at all unique, even within a geography. Two companies can use the same trademark name if
their goods and services are unrelated. The requirement is simply that no relationship between the companies
would be inferred by a "reasonable" consumer. I've seen some real life examples that escape me at the moment.
The best one I can come up with off the top of my head is "Safeway" (grocery store chain) and "Safeway"
(security software). Unrelated services, identical trademark. Who gets Safeway.com?
Here's an example closer to home. Look at www.forefront.com. Now www.ffg.com. Tell me there's no trademark
collision. That's just "doing-business-as" (DBA) names. We haven't even gotten started on product brands.
-- Skip
>From: Leonid Egoshin <egoshin at genesyslab.com> 11/08/96 01:22pm
> [ . . . ]
> Yes, but the namespace of _trademarks_ is unique. Of course in the
>area of corresponding laws. And it is possible to create hierarhy .TM
>which would match "hierarhy" of trademarks laws. And we can register
>company under name if its trademarks.
Received: from ietf.org by ietf.org id aa00579; 8 Nov 96 19:14 EST
Received: from [207.32.128.130] by ietf.org id aa00493; 8 Nov 96 19:13 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id SAA01112; Fri, 8 Nov 1996 18:07:19 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCD9F.F30E10A0 at webster.unety.net>; Fri, 8 Nov 1996 18:09:14 -0600
Message-ID: <01BBCD9F.F30E10A0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "ietf at ietf.org" <ietf at ietf.org>, 'Lars Poulsen' <lars at anchor.rns.com>
Cc: 'New Newdom' <newdom at vrx.net>
Subject: RE: US Top Level Domain
Date: Fri, 8 Nov 1996 18:09:12 -0600
Encoding: 128 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 08, 1996 5:09 PM, Lars Poulsen[SMTP:lars at anchor.rns.com] wrote:
@ On Friday, November 08, 1996 7:20 AM,
@ Simson L. Garfinkel[SMTP:simsong at VINEYARD.NET] wrote:
@ >@ US domain used to be a volunteer project. It became a burden for ISI. So they
@ >@ farmed it out. People who take up regions are allowed to charge.
@
@ In article <01BBCD4C.3102DB60 at webster.unety.net>
@ JimFleming at unety.net (Jim Fleming) writes:
@ >It is useful to note that this "farming out" was not done with
@ >an RFC, no fee guidelines have been set, no IAHC had to be
@ >formed, and the net has not collapsed.
@
@ While one could wish that the RFCs documenting the operation of
@ the US domain had been updated when the procedures changed,
@ the transition appears to have gone remarkably well.
@ There have been no wholesale complaints of
@ - lack of access
@ - unreasonable fees
@ - contention for address space
@ that I am aware of, other than the allegations from the
@ "AlterNIC mutineers" for which I have not seen specific
@ examples to back them up.
@
@ I attribute this success to someone having had extremely good
@ judgement in selecting registry delegates to service the local
@ zones, as well as a good dose of community spirit on behalf
@ of the delegates in refraining from exploiting the community's
@ trust. I have heard stories of many national TLDs that have
@ not had such good luck with their delegations.
@
@ ---
@
@ Someone was suggesting that trademarks form a unique hierachy,
@ and would be suitable for a TLD. As far as I understand, trademarks
@ are registered country by country, so if a TM hierachy were
@ implemented, it would have to be replicated under each national
@ domain, with a second level for the twenty-some separate market
@ classifications recognized by the trademark authorities (which I
@ would expect to have some variations from country to country).
@ I.e. such a domain would have the form
@
@ <name>.<category>.TRADEMARK.US
@ IBM.OFFICE-EQUIPMENT.TRADEMARK.US
@
@ Someone else suggested that if BIND was unable to deal with a
@ humongous flat namespace, BIND should be rewritten to do that
@ better. I believe that better hierachical structure will benefit
@ ANY implementation of a DNS server.
@
@ A third correspondent suggested that I save my breath and
@ sit back and wait until the mutineers fail. Actually, I think
@ their effort has merit; it is a worthwhile experiment. I just
@ want their tree to be rooted one level down from the top,
@ rather than at the root. Less debris to clean up that way,
@ if they fail to maintain discipline in their structuring
@ of the name space.
@
@ Jim Fleming complains of fees being introduced into (some parts
@ of ?) the US branch. I think that what he really is unhappy
@ about is that the fees are modest, so he cannot achieve the
@ financial independence he desires by operating such a branch.
@ (For all I know, they are probably informally regulated to be
@ no higher than InterNIC's fees.)
@ --
@ / Lars Poulsen Internet E-mail: lars at OSICOM.COM
@ OSICOM Technologies (Internet Business Unit, formerly RNS)
@ 7402 Hollister Avenue Telefax: +1-805-968-8256
@ Santa Barbara, CA 93117 Telephone: +1-805-562-3158
@
@
Can you point out where I am "complaining" of fees
being introduced into the US top level domains ?
I believe that I was pointing out that a double standard
is at play, when the US top level domain is ready to
be parceled out, people just do it, and they do not
ask anyone...other delegations have not happened
in this manner.
I find it interesting that you attribute the quiet, behind
the scenes transition of the US domain to be "extremely
good judgement".
Why is that ?
Did the "right" people make the decision
without asking anyone ? So you give your
rubber stamp approval.
Do you consider it a success because it
was done quietly ?
Also, who is to say this has been a success ?
How many people really know what is going on ?
Maybe the key to top level domain migration is to
use "extremely good judgment" and do it quietly
the way the US domain was given away. No RFCs
were needed, no committees, no consensus.
All that was needed were commercial companies willing
to speculate on various city names and willing to run
registries, collect money, and keep DNS data bases
up to date.
This is about all that is needed for progress to be made
on new top level domains. I think that many people,
including myself, have been saying this for a long time.
The double standard is that people on "newdom" and
in similar discussions are told one thing while the US
domain administrators do as they please. You call this
"extremely good judgement".
If we follow your guidance, top level domain delegations
and registry start-ups should quietly proceed while the
rest of the people make a lot of noise in San Jose and
other places.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa03717; 8 Nov 96 19:50 EST
Received: from [207.32.128.130] by ietf.org id aa02888; 8 Nov 96 19:48 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id SAA01203; Fri, 8 Nov 1996 18:41:54 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCDA4.C8093D80 at webster.unety.net>; Fri, 8 Nov 1996 18:43:49 -0600
Message-ID: <01BBCDA4.C8093D80 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'New Newdom' <newdom at vrx.net>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>, "'postel at isi.edu'" <postel at isi.edu>
Subject: 500 Delegation Limit
Date: Fri, 8 Nov 1996 18:43:48 -0600
Encoding: 45 TEXT
Source-Info: From (or Sender) name not authenticated.
@@@@@ ftp://ftp.isi.edu/in-notes/imr/imr9609.txt
THE US DOMAIN REGISTRY
----------------------
The US Domain now has an online line registration form.
Some of the processing of the requests to the third level domain
name is now automated. In particular, most requests to register
names in localities already delegated are automatically forwarded
to the administrator for that locality.
The US Domain administrator no longer makes direct registrations of
hosts, and only makes delegations of third or fourth level domain
names (such as localities).
A new policy has been added to the criteria for delegating domain
names under the US Domain:
It is the intention that the delegation of third level (for
example, locality) domain names be wide spread to many
registries. It is undesirable for one person or organization
to manage a large part of the third level names in any
particular geographic or logical area.
No individual or organization shall have more than 500
delegations total in the US Domain as a whole, or more than 50
delegation in any particuilar second level (for example, a
state).
@@@@@@
Is a company an "organization"...?
Can people own multiple companies...?
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa06542; 8 Nov 96 20:48 EST
Received: from nirvana.genesyslab.com by ietf.org id aa06475; 8 Nov 96 20:46 EST
Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id RAA13874; Fri, 8 Nov 1996 17:45:41 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id RAA13626; Fri, 8 Nov 1996 17:45:06 -0800 (PST)
Date: Fri, 8 Nov 1996 17:45:06 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199611090145.RAA13626 at giant.genesyslab.com>
To: JimFleming at unety.net, ietf at ietf.org, lars at anchor.rns.com
Subject: RE: US Top Level Domain
Cc: newdom at vrx.net
Source-Info: From (or Sender) name not authenticated.
On Friday, November 08, 1996 5:09 PM, Lars Poulsen[SMTP:lars at anchor.rns.com] wrote:
> Someone was suggesting that trademarks form a unique hierachy,
> and would be suitable for a TLD. As far as I understand, trademarks
> are registered country by country, so if a TM hierachy were
> implemented, it would have to be replicated under each national
> domain, with a second level for the twenty-some separate market
> classifications recognized by the trademark authorities (which I
> would expect to have some variations from country to country).
> I.e. such a domain would have the form
>
> <name>.<category>.TRADEMARK.US
> IBM.OFFICE-EQUIPMENT.TRADEMARK.US
>
> Someone else suggested that if BIND was unable to deal with a
> humongous flat namespace, BIND should be rewritten to do that
> better. I believe that better hierachical structure will benefit
> ANY implementation of a DNS server.
>
If there are the only "twenty-some separate market classifications"
then it is simple to implement it in DNS name-servers or in resolver.
It is seemed as not very large load on servers.
- "Someone"
(Leonid Yegoshin, LY22)
Received: from ietf.org by ietf.org id aa26487; 10 Nov 96 7:32 EST
Received: from biff.ibm.net.il by ietf.org id aa26072; 10 Nov 96 7:23 EST
Received: from rex.ibm.net.il (root at rex.ibm.net.il [192.115.72.138]) by biff.ibm.net.il (8.7.5/8.7.3) with ESMTP id OAA15088 for <ietf at ietf.org>; Sun, 10 Nov 1996 14:18:43 +0200
Received: from hank (hank.tlv.ibm.net.il [192.115.72.130]) by rex.ibm.net.il (8.8.2/8.8.2) with SMTP id OAA46819 for <ietf at ietf.org>; Sun, 10 Nov 1996 14:22:09 +0200
Message-Id: <2.2.16.19961110142621.0d87b47a at rex.ibm.net.il>
X-Sender: hank at rex.ibm.net.il
X-Mailer: Windows Eudora Pro Version 2.2 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 10 Nov 1996 14:26:21 +0000
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Hank Nussbacher <hank at ibm.net.il>
Subject: NSI contract
Source-Info: From (or Sender) name not authenticated.
When does the NSI contract expire? Month and year, please.
Thanks,
Hank Nussbacher
IBM Israel
Received: from ietf.org by ietf.org id aa01255; 10 Nov 96 13:10 EST
Received: from merit.edu by ietf.org id aa01169; 10 Nov 96 13:07 EST
Received: from LapTop.Simpson.DialUp.Mich.Net (pm036-14.dialip.mich.net [141.211.7.56]) by merit.edu (8.7.6/merit-2.0) with SMTP id NAA12909 for <ietf at ietf.org>; Sun, 10 Nov 1996 13:06:37 -0500 (EST)
Date: Sun, 10 Nov 96 16:48:06 GMT
Sender:ietf-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <2177.wsimpson at greendragon.com>
To: ietf at ietf.org
Subject: Re: The cartel begins to crumble?
Source-Info: From (or Sender) name not authenticated.
> From: Karl Denninger <karl at mcs.net>
> > In one case, a customer taped his phone conversation with the company
> > trying to sell the DN.
>
> Try that in the US and you may run afoul of CRIMINAL statutes, depending on
> the state you're calling from and to.
>
> It would be a *real* bad idea to attempt to do this in many countries -- the
> United States included.
>
Actually, Karl, although you sometimes raise issues of real importance,
in these matters I wish that you would keep to areas of your own
expertise. It is perfectly legal virtually anywhere to record phone
conversations to which you are a party, or to wear a body microphone to
record conversations to which you are a party, or to wire a room which
you own to record any conversations that take place.
Interstate conversations by necessity do not follow state law, but
rather interstate (federal or international) law. But state laws
generally follow the federal anyway.
There are some instances where US law has stated that for formal legal
meetings, you must give all parties advance notice that you might record
the meeting. For example, US I.R.C. 7521(a)(1) has come into my life
recently.
You might have noticed that when you call your local RBOC, you hear a
message saying that the conversation might be recorded. That is because
the entity doing the recording is _not_ a party to the conversation;
instead, it is a third party administrator.
It only takes a court order to be admissible as evidence in a court of
law, and then only when recording conversations to which you are _NOT_ a
party. Otherwise, you can testify as to the accuracy of the recording
or transcript the same as if you had taken contemporaneous notes.
Next time you raise legal authority, please give us all a true case cite.
Thanks....
WSimpson at UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson at MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Received: from ietf.org by ietf.org id aa03024; 10 Nov 96 14:16 EST
Received: from Kitten.mcs.com by ietf.org id aa02820; 10 Nov 96 14:14 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id NAA07723; Sun, 10 Nov 1996 13:13:06 -0600 (CST)
Received: from Venus.mcs.net (karl at Venus.mcs.com [192.160.127.92]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA02742; Sun, 10 Nov 1996 13:13:05 -0600 (CST)
Received: (from karl at localhost) by Venus.mcs.net (8.8.2/8.8.2) id NAA00524; Sun, 10 Nov 1996 13:13:04 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611101913.NAA00524 at Venus.mcs.net>
Subject: Re: The cartel begins to crumble?
To: William Allen Simpson <wsimpson at greendragon.com>
Date: Sun, 10 Nov 1996 13:13:04 -0600 (CST)
Cc: ietf at ietf.org
In-Reply-To: <2177.wsimpson at greendragon.com> from "William Allen Simpson" at Nov 10, 96 04:48:06 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
>
> > From: Karl Denninger <karl at mcs.net>
> > > In one case, a customer taped his phone conversation with the company
> > > trying to sell the DN.
> >
> > Try that in the US and you may run afoul of CRIMINAL statutes, depending on
> > the state you're calling from and to.
> >
> > It would be a *real* bad idea to attempt to do this in many countries -- the
> > United States included.
> >
> Actually, Karl, although you sometimes raise issues of real importance,
> in these matters I wish that you would keep to areas of your own
> expertise. It is perfectly legal virtually anywhere to record phone
> conversations to which you are a party, or to wear a body microphone to
> record conversations to which you are a party, or to wire a room which
> you own to record any conversations that take place.
Not in Illinois.
There are specific exceptions, but in *GENERAL* it is illegal to record
a telephone conversation in this state.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa03293; 10 Nov 96 14:21 EST
Received: from access.netaxs.com by ietf.org id aa03219; 10 Nov 96 14:21 EST
Received: from unix1.netaxs.com (cook at unix1.netaxs.com [207.8.186.3]) by access.netaxs.com (8.7.6/8.6.11) with ESMTP id OAA22907; Sun, 10 Nov 1996 14:19:58 -0500 (EST)
Received: (from cook at localhost) by unix1.netaxs.com (8.7.6/8.7.3) id OAA00886; Sun, 10 Nov 1996 14:19:54 -0500 (EST)
Date: Sun, 10 Nov 1996 14:19:53 -0500 (EST)
Sender:ietf-request at ietf.org
From: Gordon Cook <cook at netaxs.com>
To: Hank Nussbacher <hank at ibm.net.il>
cc: ietf at ietf.org
Subject: Re: NSI contract
In-Reply-To: <2.2.16.19961110142621.0d87b47a at rex.ibm.net.il>
Message-ID: <Pine.SUN.3.94.961110140853.697A-100000 at unix1.netaxs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Hank asks when the NSI contract ends: The answer is: April 1 1998.
But remember that it is a cooperative agreement which means
that some of the rules governing it are a bit different than a contract.
And remember that the FNC (or was it the FNCAC?) recently expressed the
desire that NSF remove itself from involvement with the entire domain name
issue. Thus the terminaton of the current five year agreement well in
advance of April 1 1998 is not at all impossible.
************************************************************************
The COOK Report on Internet For subsc. pricing & more than
431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material
(609) 882-2572 (phone & fax) visit http://pobox.com/cook/
Internet: cook at cookreport.com For case study of MercerNet &
TIIAP induced harm to local community http://pobox.com/cook/mercernet.html
************************************************************************
On Sun, 10 Nov 1996, Hank Nussbacher wrote:
> When does the NSI contract expire? Month and year, please.
>
> Thanks,
> Hank Nussbacher
> IBM Israel
>
Received: from ietf.org by ietf.org id aa04858; 10 Nov 96 14:55 EST
Received: from ns.research.att.com by ietf.org id aa04815; 10 Nov 96 14:55 EST
Received: from research.att.com by ns; Sun Nov 10 14:53:05 EST 1996
Received: from raptor.research.att.com by research; Sun Nov 10 14:51:55 EST 1996
Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id OAA03116; Sun, 10 Nov 1996 14:51:54 -0500 (EST)
Message-Id: <199611101951.OAA03116 at raptor.research.att.com>
To: William Allen Simpson <wsimpson at greendragon.com>
cc: ietf at ietf.org
Subject: Re: The cartel begins to crumble?
Date: Sun, 10 Nov 1996 14:51:54 -0500
Sender:ietf-request at ietf.org
From: Steven Bellovin <smb at research.att.com>
Source-Info: From (or Sender) name not authenticated.
Interstate conversations by necessity do not follow state law, but
rather interstate (federal or international) law. But state laws
generally follow the federal anyway.
...
Next time you raise legal authority, please give us all a true case
cite.
There are number of states where all parties must consent to a conversation
being recorded. While I don't have a complete list handy, I know that
Pennsylvania is one. Here's a quote from the Pennsylvania Supreme Court
case barring Caller-ID in that state:
18 P.S. s 5704 provides: It shall not be unlawful under this
chapter for: ... (4) A person to intercept a wire, electronic
or oral communication, where all parties to the communication
have given prior consent to such interception. As stated by
Judge Pellegrini: [W]hen the 1988 amendments were adopted by
the General Assembly, they were grafted onto a legislative
scheme very different and one that is much more protective of
individual rights than federal law. Even though the language
of the federal law and 1988 amendments to the Wiretap Act are
nearly the same, by not changing the "all party consent rule,"
it is clear that the General Assembly meant that any part of
the communication, including phone number identification,
should have the consent of all parties prior to it being
trapped and traced. 576 A.2d at 93.
I'm quite certain that other states have similar provisions, but I don't have
a list handy. For starters, see Section 632 of the California Penal Code:
632. (a) Every person who, intentionally and without the consent of
all parties to a confidential communication, by means of any
electronic amplifying or recording device, eavesdrops upon or records
the confidential communication, whether the communication is carried
on among the parties in the presence of one another or by means of a
telegraph, telephone, or other device, except a radio, shall be
punished ...
(from http://www.leginfo.ca.gov/cgi-bin/displaycode?section=pen&group=00001-01000&file=630-637.6)
Recordings of conversations with phone companies is covered by 47 CFR 64.501,
which specifically requires consent of the othe party. See
http://orbus.pls.com:8001/cgi-bin/taos_doc.pl?unix+1+cfr+189723+query+record+conversation+%25BREAK%25+cfr%3a
for that one.
Received: from ietf.org by ietf.org id aa05041; 10 Nov 96 14:57 EST
Received: from mail1.Reston.mci.net by ietf.org id aa04975; 10 Nov 96 14:55 EST
Received: from cerf (infolink-204.189.236.45.Chicago.mci.net)
by MAIL1.RESTON.MCI.NET (PMDF V5.0-5 #8388)
id <01IBOO2ZTDR4000HB4 at MAIL1.RESTON.MCI.NET>; Sun,
10 Nov 1996 15:00:17 -0500 (EST)
Date: Sun, 10 Nov 1996 14:55:09 -0500
Sender:ietf-request at ietf.org
From: "Vinton G. Cerf" <vcerf at mci.net>
Subject: Re: NSI contract
X-Sender: vcerf at 166.45.25.52
To: Gordon Cook <cook at netaxs.com>
Cc: Hank Nussbacher <hank at ibm.net.il>, ietf at ietf.org
Message-id: <2.2.16.19961110195509.430776ba at 166.45.25.52>
MIME-version: 1.0
X-Mailer: Windows Eudora Pro Version 2.2 (16)
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT
Source-Info: From (or Sender) name not authenticated.
Gordon,
I think it was the FNCAC that expressed this view.
vint cerf
At 02:19 PM 1996/11/10 -0500, Gordon Cook wrote:
>Hank asks when the NSI contract ends: The answer is: April 1 1998.
>But remember that it is a cooperative agreement which means
>that some of the rules governing it are a bit different than a contract.
>And remember that the FNC (or was it the FNCAC?) recently expressed the
>desire that NSF remove itself from involvement with the entire domain name
>issue. Thus the terminaton of the current five year agreement well in
>advance of April 1 1998 is not at all impossible.
>
>
>************************************************************************
>The COOK Report on Internet For subsc. pricing & more than
>431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material
>(609) 882-2572 (phone & fax) visit http://pobox.com/cook/
>Internet: cook at cookreport.com For case study of MercerNet &
>TIIAP induced harm to local community http://pobox.com/cook/mercernet.html
>************************************************************************
>
>
Received: from ietf.org by ietf.org id aa08253; 10 Nov 96 16:07 EST
Received: from luggage.tecc.co.uk by ietf.org id aa08164; 10 Nov 96 16:05 EST
Received: from auntie.bbcnc.org.uk by luggage.tecc.co.uk id aa25692;
10 Nov 96 20:53 GMT
To: Steven Bellovin <smb at research.att.com>
cc: William Allen Simpson <wsimpson at greendragon.com>, ietf at ietf.org
Subject: Re: The cartel begins to crumble?
In-reply-to: Your message of "Sun, 10 Nov 1996 14:51:54 EST."
<199611101951.OAA03116 at raptor.research.att.com>
Date: Sun, 10 Nov 1996 20:53:49 +0000
Sender:ietf-request at ietf.org
From: Gordon Joly <gordo at tecc.co.uk>
Message-ID: <9611102053.aa25692 at luggage.tecc.co.uk>
Source-Info: From (or Sender) name not authenticated.
>> There are number of states where all parties must consent to a
>> conversation being recorded.
Shall I check what happens in the "state" of the UK? And European
Union?
--
Gordon Joly http://pobox.com/~gjoly/ gordon.joly at pobox.com
Received: from ietf.org by ietf.org id aa10824; 10 Nov 96 18:26 EST
Received: from WLV.IIPO.GTEGSC.COM by ietf.org id aa10731; 10 Nov 96 18:23 EST
Received: from SPIELZEUG.IIPO.GTEGSC.COM (SPIELZEUG.IIPO.GTEGSC.COM [199.107.242.241]) by wlv.iipo.gtegsc.com (8.8.2/8.7.3) with SMTP id PAA10986; Sun, 10 Nov 1996 15:09:28 -0800 (PST)
Sender:ietf-request at ietf.org
From: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>
Message-Id: <961110150854.ZM12734 at SPIELZEUG.IIPO.GTEGSC.COM>
Date: Sun, 10 Nov 1996 15:08:45 -0700
In-Reply-To: Gordon Joly <gordo at tecc.co.uk>
"Re: The cartel begins to crumble?" (Nov 10, 20:53)
References: <9611102053.aa25692 at luggage.tecc.co.uk>
X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996)
To: Gordon Joly <gordo at tecc.co.uk>, Steven Bellovin <smb at research.att.com>
Subject: Re: The cartel begins to crumble?
Cc: William Allen Simpson <wsimpson at greendragon.com>, ietf at ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
On Nov 10, 20:53, Gordon Joly wrote:
> Subject: Re: The cartel begins to crumble?
}
}
}>> There are number of states where all parties must consent to a
}>> conversation being recorded.
}
}Shall I check what happens in the "state" of the UK? And European
}Union?
I thought that the United Kingdom of Great Britain and Northern Ireland was
still independent. ;-) The "states" would be
England
Scotland
Wales
Northern Ireland
I'm a little rusty but I think the Channel Islands do have the following
states.
Jersey
Guernsey
Alderney
Sark
And, then we have the Isle of Man that doesn't have any states. It, also,
isn't a member of the European Union as are the United Kingdom and the Channel
Islands.
Could you give us a run down for each of the above?
Merton Campbell Crockett
Received: from ietf.org by ietf.org id aa11242; 10 Nov 96 18:33 EST
Received: from [207.32.130.1] by ietf.org id aa11151; 10 Nov 96 18:32 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id RAA09483 for <ietf at ietf.org>; Sun, 10 Nov 1996 17:26:18 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCF2C.9199B160 at webster.unety.net>; Sun, 10 Nov 1996 17:28:21 -0600
Message-ID: <01BBCF2C.9199B160 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Taxing Domain Name Servers
Date: Sun, 10 Nov 1996 17:28:19 -0600
Encoding: 143 TEXT
Source-Info: From (or Sender) name not authenticated.
TAXING DOMAIN NAME SERVERS
or "Think Globally and Act Locally"...
Now that the elections are over in the U.S. It appears that
some governments and local areas are quickly beginning
to see the light, that the Internet is a potential source of
tax revenue. This could also be a result of the windfall
profits being reaped by Network Solutions, Inc. and
their owner, SAIC, from its "cooperative agreement"
with the National Science Foundation (NSF) which is
largely funded by the U.S. Government.
State governments and local communities are beginning
to see that "tax-like" dollars for domain registrations are
being sent to Virginia from all around the world. As usual,
the Washington, D.C. area economy is the beneficiary
and states get little in return. In the past, people would
claim that free registrations in the US. domain allowed
people an alternative, and these "Internet Taxes" were
not a concern.
The US. domain is no longer totally free. Companies
are being delegated city's names and in some cases
they are sending invoices without the registrants' prior
approval. To make matters worse, some of these
companies are not operating in the state where the
city is located. This raises questions about business
licensing, registrations and interstate commerce.
Even though U.S. Internet users are constantly being told
that they should "think globally" and avoid U.S.-centric
views, when the rubber hits the road, Internet Politicians
"act locally" to protect their own interests. This is
no different than what has been happening for centuries,
all around the world, with government politicians.
As government politicians begin to see the "taxation"
patterns and revenue flows, there is little doubt that
they will become interested in mapping the Internet
to existing rules and regulations. One of the easiest
ways to do this is via the domain registration system.
Because of all of the discussions about new top level
domains and domain registries, people are becoming
more educated about the technology and the flexibility
of the systems. Many people have been mislead that
the system is rigid and "Internet Taxes" must be paid
to those that maintain the system and no one else
can participate. This is clearly not the case.
One of the keys to controlling the Internet domain
system rests with the root name servers. Internet
Service Providers use these root name servers to
help their subscribers locate web sites and e-mail
destinations. If ISPs are "encouraged", via legislation
or regulation, to use state supplied (or supported)
root name servers, the state can insert itself into
the domain name look-up flow, with very little effort,
and can bring "Internet Tax" dollars back to the
state (or community) where the commerce is
originating.
The arrangement would be very simple, the state
would provide a small collection of root name
servers and delegate all of the top level domains
to registries located in that state. The major
top level domains such as .COM, .NET, and
.ORG could be easily operated by local agencies
under "cooperative agreements" with the state.
Those agreements could be made with ISPs
in the state who cooperate with the plan.
With such an arrangement, companies currently
registered in the .COM domain would have to
register in each state (or region) where they wanted
to "easily" do business. They could start with
a "federal registration" as they do today and
then reproduce that in each state. Fifty states
at $50/year could cost a company $2,500.
At a more realistic cost of $10/state, these
fees could be brought into line with other
corporate filing fees currently levied by states.
To discourage changes, a fee could be charged
for any transaction, just as most states do today.
This process is nothing new to corporations
who must register as a "foreign corporation" in
all the states where they have operations. (Since
people could always bypass the domain name
system by using an IP address people could
still reach a company, the hard way).
The registration fees could help to fund Internet
infrastructure in that state and would not have to
be sent to a Washington, D.C. suburb. Also, the
technical burden on the companies would not be
high because all states could direct their .COM
name servers to the same corporate name servers
now supplied by the company (unless the company
wanted a different DNS data base for a different
region of the country).
While it would be nice to think that everyone is
going to "think globally" and "act globally" it is
clear that this is not the case. Pandora's box
was opened when the NSF allowed for "Internet
Taxes" to be levied without representation.
Those taxes have been enjoyed by a select
group of individuals who keep telling everyone
that there are no other solutions.
Many people have witnessed the bitter battles
over the domain name system and the positioning
for revenue opportunities and windfall profits.
These battles are just getting started. The next
round of top level domain expansion is likely
to attract large corporate players and it appears
that the Internet Politicians are more willing to
turn things over to big money, than the local
communities.
One solution available to local politicians is to
take that global NSF action and apply it at a local
level. They can now "think globally" and "act locally"
and keep those tax dollars in their community.
With a small change for ISPs, and some minor
investment in infrastructure, a state can insert
itself into the domain name system and follow
the model established by the Internet Politicians.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa13371; 10 Nov 96 19:36 EST
Received: from ivory.educom.edu by ietf.org id aa13285; 10 Nov 96 19:32 EST
Received: by ivory.educom.edu (8.6.12/1.34 (CREN))
id TAA02557; Sun, 10 Nov 1996 19:31:40 -0500
Message-Id: <199611110031.TAA02557 at ivory.educom.edu>
Subject: Re: NSI contract
To: Gordon Cook <cook at netaxs.com>
Date: Sun, 10 Nov 1996 19:31:39 -0500 (EST)
Sender:ietf-request at ietf.org
From: Mike Roberts <roberts at ivory.educom.edu>
Cc: hank at ibm.net.il, ietf at ietf.org
In-Reply-To: <Pine.SUN.3.94.961110140853.697A-100000 at unix1.netaxs.com> from "Gordon Cook" at Nov 10, 96 02:19:53 pm
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1753
Source-Info: From (or Sender) name not authenticated.
Gordon - That's not quite an accurate view of the FNCAC discussion.
The motion we passed expressed the strong desire that the FNC
work hard NOW to develop a sound future foundation for the
domain name system when the NSI agreement ends in less than
18 months, and further, that an "appropriate entity" be
identified to hold responsibility for those parts of the
DNS that are found to require permanent stewardship, ie not
to be handed over for dissection by the greedy private sector
types that lust after the alleged NSI monopoly profits.
- M.
>
> Hank asks when the NSI contract ends: The answer is: April 1 1998.
> But remember that it is a cooperative agreement which means
> that some of the rules governing it are a bit different than a contract.
> And remember that the FNC (or was it the FNCAC?) recently expressed the
> desire that NSF remove itself from involvement with the entire domain name
> issue. Thus the terminaton of the current five year agreement well in
> advance of April 1 1998 is not at all impossible.
>
>
> ************************************************************************
> The COOK Report on Internet For subsc. pricing & more than
> 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material
> (609) 882-2572 (phone & fax) visit http://pobox.com/cook/
> Internet: cook at cookreport.com For case study of MercerNet &
> TIIAP induced harm to local community http://pobox.com/cook/mercernet.html
> ************************************************************************
>
>
> On Sun, 10 Nov 1996, Hank Nussbacher wrote:
>
> > When does the NSI contract expire? Month and year, please.
> >
> > Thanks,
> > Hank Nussbacher
> > IBM Israel
> >
>
>
Received: from ietf.org by ietf.org id aa16048; 10 Nov 96 20:30 EST
Received: from [207.32.130.1] by ietf.org id aa15971; 10 Nov 96 20:28 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id TAA09689; Sun, 10 Nov 1996 19:21:18 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCF3C.A26D9AA0 at webster.unety.net>; Sun, 10 Nov 1996 19:23:21 -0600
Message-ID: <01BBCF3C.A26D9AA0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: Gordon Cook <cook at netaxs.com>, 'Mike Roberts' <roberts at ivory.educom.edu>
Cc: "hank at ibm.net.il" <hank at ibm.net.il>, "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: NSI contract
Date: Sun, 10 Nov 1996 19:23:19 -0600
Encoding: 60 TEXT
Source-Info: From (or Sender) name not authenticated.
On Sunday, November 10, 1996 1:31 PM, Mike Roberts[SMTP:roberts at ivory.educom.edu] wrote:
@ Gordon - That's not quite an accurate view of the FNCAC discussion.
@
@ The motion we passed expressed the strong desire that the FNC
@ work hard NOW to develop a sound future foundation for the
@ domain name system when the NSI agreement ends in less than
@ 18 months, and further, that an "appropriate entity" be
@ identified to hold responsibility for those parts of the
@ DNS that are found to require permanent stewardship, ie not
@ to be handed over for dissection by the greedy private sector
@ types that lust after the alleged NSI monopoly profits.
@
@ - M.
@
@ >
@ > Hank asks when the NSI contract ends: The answer is: April 1 1998.
@ > But remember that it is a cooperative agreement which means
@ > that some of the rules governing it are a bit different than a contract.
@ > And remember that the FNC (or was it the FNCAC?) recently expressed the
@ > desire that NSF remove itself from involvement with the entire domain name
@ > issue. Thus the terminaton of the current five year agreement well in
@ > advance of April 1 1998 is not at all impossible.
@ >
<snip ad>
@ >
@ >
@ > On Sun, 10 Nov 1996, Hank Nussbacher wrote:
@ >
@ > > When does the NSI contract expire? Month and year, please.
@ > >
@ > > Thanks,
@ > > Hank Nussbacher
@ > > IBM Israel
@ > >
@ >
@ >
Mike,
Since you refer to NSI's profits as "alleged NSI monopoly profits",
I assume that you are implying one of the following....
1. There are no profits.
2. They are not "monopoly" profits (in your opinion).
3. They are SAIC's profits, not NSI's.
4. They are alleged because no one knows
what the true story is because there is
no public disclosure.
For some of these options, you have to have information
on the financials. Can you disclose that information ?
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa25298; 10 Nov 96 23:37 EST
Received: from cnri by ietf.org id aa25126; 10 Nov 96 23:33 EST
Received: from gw.home.vix.com by CNRI.Reston.VA.US id aa00571;
10 Nov 96 23:33 EST
Received: by gw.home.vix.com id UAA20300; Sun, 10 Nov 1996 20:32:05 -0800 (PST)
Date: Sun, 10 Nov 1996 20:32:05 -0800 (PST)
X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
To: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Subject: Re: Why More TLDs
Organization: Vixie Enterprises
Message-ID: <VIXIE.96Nov10203203 at wisdom.vix.com>
References: <55uoo8$3d2 at anchor.rns.com>
NNTP-Posting-Host: wisdom.home.vix.com
In-reply-to: lars at anchor.rns.com's message of 8 Nov 1996 00:22:46 -0800
Xref: vixie local.mail.net.ietf:6629
Source-Info: From (or Sender) name not authenticated.
The simple answer to "why more TLD's?" is that 100% of the users on the
Internet as of this date are abusing DNS as a directory service, and since
DNS somewhat predictably does not work well as a directory service these
people are trying to solve a "wrong technology" problem with a "more data"
solution. It won't work but like lemmings to the sea, we just gotta do it.
Consider those rasty little ISO layers and which one(s?) hold any hope of
being used as a directory service:
L1 identifiers (circuit ID's, registered cross connects) change during the
lifetime of their consumer and provider, and are meaningless outside
of the cable plant other than for billing.
L2 identifiers (mac-level addresses like ethernet or E.164) also change during
the lifetime of their consumer and provider, and are meaningless to
anyone not connected to a particular L2 wire/hub/cloud.
L3 identifiers (IP addresses) change every time a new provider is chosen, even
though the web/mail/whatever server/client is still the same entity
doing the same things they did before the change.
L4 identifiers (<srcaddr,srcport,dstaddr,dstport> tuples) change every time
a connection is made and so using them as locators is an anticoncept.
Clearly we're not going to see any of those used on movie posters in a URL
that tells folks how to buy stuffed dolls representing story characters.
Right now we use domain names, since they are universally unique, and they
are permanent. They are not, however, guessable.
Sure, I can find *something* if I ask for http://WWW.PIZZA.COM/ but it's not
likely that I can find my local pizza shop that way. I can try Alta Vista
or Yahoo, but it's going to be hard to find my local pizza shop that way, too.
Therefore I use the telephone company's directory service ("can you give me
the number for Lucia's Pizza in Woodside?") and then I use the telephone to
call and get their URL so I can use HTTPS to order my pizza online. Then I
keep it as a bookmark. Which is OK until I have 2,000 such bookmarks and I
need to spend an hour per week cataloguing them.
(As it happens, PIZZA.COM is held by IIS, a domain name speculator. I digress.)
What I need and what the other 98% of Internet users who have not yet signed
on need, is a way to say "does lucia's pizza in woodside have a URL?" and get
something useful -- an authoritative "no" or a short/accurate list of possible
"yes"'s.
Asking Lucia's of Woodside to register as lucias.woodside.ca.us.pizza.com is
one possible answer but does it scale to automotive transmission shops? Do
I look under Automotive or do I look under Transmission? Keep in mind that
a true directory service allows some fuzz in the lookups, but DNS does not.
So I suppose we had better allocate .PIZZA but I don't think it will solve
the real problem. Lucia's Pizza of Woodside probably could live happily
with lucias.woodside.ca.us even though a lot of folks think they are in
Redwood City since they are actually closer to it. The domain name that
would work for them (lucias.woodside.ca.us) says nothing about their business
and it's not particularly guessable -- but it excells at what DNS provides,
which is universal uniqueness and permanence.
The current TLD's were chosen by programmers rather than librarians. If you
look at the average programmer's choice of file names and variable names and
what not, you will see that programmers ought not, usually, be allowed to
pick names -- especially names that have to map to real world objects.
What we *need* in DNS is to close the current TLD's to new registrations,
get a bunch of librarians together and let them hammer out a new schema that
will provide better splay (.COM is too flat), get leverage out of universal
uniqueness and permanence, and publically sacrifice (stake through the heart)
any possible guessability. And then we need an actual, real live directory
service that works as well as the one the telephone companies provide now.
What we'll *get* is .PIZZA and a zillion other attempts to meet the nongoal
of guessability.
Any questions?
(See ftp://ftp.vix.com/pri/vixie/dns-badnames.psf.gz for answers.)
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul at vix.com>
pacbell!vixie!paul
Received: from ietf.org by ietf.org id aa01980; 11 Nov 96 7:27 EST
Received: from cnri by ietf.org id aa01771; 11 Nov 96 7:23 EST
Received: from ng.netgate.net by CNRI.Reston.VA.US id aa00959;
11 Nov 96 7:23 EST
Received: from [204.179.131.85] (mg131-085.ricochet.net [204.179.131.85]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id VAA09708; Sun, 10 Nov 1996 21:58:04 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100704aeac6c671a61 at [204.179.131.85]>
In-Reply-To: <VIXIE.96Nov10203203 at wisdom.vix.com>
References: lars at anchor.rns.com's message of 8 Nov 1996 00:22:46 -0800
<55uoo8$3d2 at anchor.rns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 10 Nov 1996 21:46:46 -0800
To: Paul A Vixie <paul at vix.com>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: Why More TLDs
Cc: ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
At 8:32 PM -0800 11/10/96, Paul A Vixie wrote:
>Right now we use domain names, since they are universally unique, and they
>are permanent. They are not, however, guessable.
to emphasize for thos who may miss this point: guessability is the
core characteristic of a 'directory' versus the completely deterministic
behaviors of a mapping service like the dns. The difference between
=46INDING a name (and associated information) based on various criteria,
possibly including the name, versus USING the name to find only and
exactly the information associated with it is technically quite different
tasks.
>Asking Lucia's of Woodside to register as lucias.woodside.ca.us.pizza.com i=
s
>one possible answer but does it scale to automotive transmission shops? Do
Paul probably knows this, but to be clear, we need to make sure
that there is a general appreciation that this approach is doomed. The
scheme fits within the classic model of hierarchical (tree structured) data
base systems and they simply are not flexible enough for the undisciplined
range of queries that will come into a public Internet data base. Whatever
scheme you put lucias under, there will be others that some folks will look
for -- and not find.
>What we *need* in DNS is to close the current TLD's to new registrations,
I personally question the viability of this. It is, perhaps, yet
another example of the technicians approach. We find it comforting to fix
a problem by simply moving everyone off the field of battle and put them
somewhere more comfortable. Nice work if you can get it.
Also there is, I think, another factor at work. Domain Names are a
good idea not only because they can permit a degree of guessability -- a
degree; one that does not scale. Rather, they also have a general mnemonic
quality and some information redundancy. They tend to be easy to remember
and mistyping one usually causes a failure rather than misdelivery.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa03152; 11 Nov 96 8:06 EST
Received: from cnri by ietf.org id aa03063; 11 Nov 96 8:04 EST
Received: from host02.net.voyager.co.nz by CNRI.Reston.VA.US id aa02112;
11 Nov 96 8:04 EST
Received: from [203.21.27.148] (ts1p12.net.hamilton.voyager.co.nz [203.21.27.148]) by host02.net.voyager.co.nz (8.7.4/8.6.12) with SMTP id VAA09283 for <ietf at CNRI.Reston.VA.US>; Mon, 11 Nov 1996 21:23:06 +1300 (NZDT)
Date: Mon, 11 Nov 1996 21:23:06 +1300 (NZDT)
Message-Id: <199611110823.VAA09283 at host02.net.voyager.co.nz>
Subject: PLEASE TAKE ME OFF THIS LIST !!!!!!!!
Sender:ietf-request at ietf.org
From: jotham <jotham at voyager.co.nz>
To: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Source-Info: From (or Sender) name not authenticated.
PLEASE TAKE ME OFF THIS LIST !!!!!!!! thanks !!!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jotham Read
Graphic Artist and Web Designer
Email: jotham at voyager.co.nz
Phone: 07) 5520066
Web: Http://www.voyager.co.nz/~jotham/
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received: from ietf.org by ietf.org id aa03385; 11 Nov 96 8:08 EST
Received: from cnri by ietf.org id aa03183; 11 Nov 96 8:07 EST
Received: from fxiod04.is.chrysler.com by CNRI.Reston.VA.US id aa02188;
11 Nov 96 8:07 EST
Received: by fxiod04.is.chrysler.com; id AA29604; Mon, 11 Nov 96 07:01:43 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod04.is.chrysler.com via smap (V3.1.1)
id xma029601; Mon, 11 Nov 96 07:01:14 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id GAA09275; Mon, 11 Nov 1996 06:50:28 -0500 (EST)
Message-Id: <3.0b36.32.19961111065239.009eee60 at pop3hub.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b36 (32)
Date: Mon, 11 Nov 1996 07:01:05 -0500
To: Paul A Vixie <paul at vix.com>, ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Why More TLDs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 08:32 PM 11/10/96 -0800, Paul A Vixie wrote:
Paul, this is an excellent exposition. One of the best I've seen you
supply on a subject that you are so close to for so long. I hope that the
techno and business dweeps here can truely understand your meaning.
So, should we appeal to Joyce to get her crew in gear? I really think you
have done an excellent job of pointing out where the work on DNS really has
to move to. Not to operations and business, but to users and librarians.
Only after that can ops have it.
>The simple answer to "why more TLD's?" is that 100% of the users on the
>Internet as of this date are abusing DNS as a directory service, and since
>DNS somewhat predictably does not work well as a directory service these
>people are trying to solve a "wrong technology" problem with a "more data"
>solution. It won't work but like lemmings to the sea, we just gotta do it.
>
>Consider those rasty little ISO layers and which one(s?) hold any hope of
>being used as a directory service:
>
>L1 identifiers (circuit ID's, registered cross connects) change during the
> lifetime of their consumer and provider, and are meaningless outside
> of the cable plant other than for billing.
>
>L2 identifiers (mac-level addresses like ethernet or E.164) also change
during
> the lifetime of their consumer and provider, and are meaningless to
> anyone not connected to a particular L2 wire/hub/cloud.
>
>L3 identifiers (IP addresses) change every time a new provider is chosen,
even
> though the web/mail/whatever server/client is still the same entity
> doing the same things they did before the change.
>
>L4 identifiers (<srcaddr,srcport,dstaddr,dstport> tuples) change every time
> a connection is made and so using them as locators is an anticoncept.
>
>Clearly we're not going to see any of those used on movie posters in a URL
>that tells folks how to buy stuffed dolls representing story characters.
>
>Right now we use domain names, since they are universally unique, and they
>are permanent. They are not, however, guessable.
>
>Sure, I can find *something* if I ask for http://WWW.PIZZA.COM/ but it's not
>likely that I can find my local pizza shop that way. I can try Alta Vista
>or Yahoo, but it's going to be hard to find my local pizza shop that way,
too.
>Therefore I use the telephone company's directory service ("can you give me
>the number for Lucia's Pizza in Woodside?") and then I use the telephone to
>call and get their URL so I can use HTTPS to order my pizza online. Then I
>keep it as a bookmark. Which is OK until I have 2,000 such bookmarks and I
>need to spend an hour per week cataloguing them.
>
>(As it happens, PIZZA.COM is held by IIS, a domain name speculator. I
digress.)
>
>What I need and what the other 98% of Internet users who have not yet signed
>on need, is a way to say "does lucia's pizza in woodside have a URL?" and get
>something useful -- an authoritative "no" or a short/accurate list of
possible
>"yes"'s.
>
>Asking Lucia's of Woodside to register as lucias.woodside.ca.us.pizza.com is
>one possible answer but does it scale to automotive transmission shops? Do
>I look under Automotive or do I look under Transmission? Keep in mind that
>a true directory service allows some fuzz in the lookups, but DNS does not.
>
>So I suppose we had better allocate .PIZZA but I don't think it will solve
>the real problem. Lucia's Pizza of Woodside probably could live happily
>with lucias.woodside.ca.us even though a lot of folks think they are in
>Redwood City since they are actually closer to it. The domain name that
>would work for them (lucias.woodside.ca.us) says nothing about their business
>and it's not particularly guessable -- but it excells at what DNS provides,
>which is universal uniqueness and permanence.
>
>The current TLD's were chosen by programmers rather than librarians. If you
>look at the average programmer's choice of file names and variable names and
>what not, you will see that programmers ought not, usually, be allowed to
>pick names -- especially names that have to map to real world objects.
>
>What we *need* in DNS is to close the current TLD's to new registrations,
>get a bunch of librarians together and let them hammer out a new schema that
>will provide better splay (.COM is too flat), get leverage out of universal
>uniqueness and permanence, and publically sacrifice (stake through the heart)
>any possible guessability. And then we need an actual, real live directory
>service that works as well as the one the telephone companies provide now.
>
>What we'll *get* is .PIZZA and a zillion other attempts to meet the nongoal
>of guessability.
>
>Any questions?
>
>(See ftp://ftp.vix.com/pri/vixie/dns-badnames.psf.gz for answers.)
>--
>Paul Vixie
>La Honda, CA "Illegitimibus non carborundum."
><paul at vix.com>
>pacbell!vixie!paul
>
>
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa05341; 11 Nov 96 8:48 EST
Received: from cnri by ietf.org id aa05256; 11 Nov 96 8:46 EST
Received: from [207.32.130.1] by CNRI.Reston.VA.US id aa03066;
11 Nov 96 8:46 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id HAA11730; Mon, 11 Nov 1996 07:40:09 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCFA3.DA8838C0 at webster.unety.net>; Mon, 11 Nov 1996 07:42:13 -0600
Message-ID: <01BBCFA3.DA8838C0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
'Paul A Vixie' <paul at vix.com>
Cc: 'New Newdom' <newdom at vrx.net>
Subject: RE: Why More TLDs
Date: Mon, 11 Nov 1996 07:42:12 -0600
Encoding: 50 TEXT
Source-Info: From (or Sender) name not authenticated.
On Sunday, November 10, 1996 2:32 PM, Paul A Vixie[SMTP:paul at vix.com] wrote:
@ The simple answer to "why more TLD's?" is that 100% of the users on the
@ Internet as of this date are abusing DNS as a directory service, and since
@ DNS somewhat predictably does not work well as a directory service these
@ people are trying to solve a "wrong technology" problem with a "more data"
@ solution. It won't work but like lemmings to the sea, we just gotta do it.
@
<snip>
@
@ Sure, I can find *something* if I ask for http://WWW.PIZZA.COM/ but it's not
@ likely that I can find my local pizza shop that way. I can try Alta Vista
@ or Yahoo, but it's going to be hard to find my local pizza shop that way, too.
@ Therefore I use the telephone company's directory service ("can you give me
@ the number for Lucia's Pizza in Woodside?") and then I use the telephone to
@ call and get their URL so I can use HTTPS to order my pizza online. Then I
@ keep it as a bookmark. Which is OK until I have 2,000 such bookmarks and I
@ need to spend an hour per week cataloguing them.
@
<snip>
Paul,
Rather than shift directory services to the DNS, you could
also consider an alternative...
You could become the webmaster for Woodside, California
and help others place your "hot links" on...
<http://comm.unety.net>
...this will allow you to dynamically build a community
directory, using descriptive categories and names. Once
people discover the value of these types of directories,
then the pressure will shift from using the DNS.
P.S. Comm.unety.net was featured in the Chicago
Tribune's Digital City project....
<http://chicago.digitalcity.com/naperville/index.htm>
...don't miss..."Pizza a slice of Naperville life."...:-)
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa07200; 11 Nov 96 9:37 EST
Received: from ietf.org by ietf.org id aa07103; 11 Nov 96 9:35 EST
To: ietf at ietf.org
Subject: CFP: Interactive Distributed Multimedia Systems & Telecomm. Services
Sender:ietf-request at ietf.org
From: Lars Wolf <Lars.Wolf at kom.th-darmstadt.de>
Date: Mon, 11 Nov 1996 09:35:22 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9611110935.aa07103 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Dear Colleague,
please find enclosed a Call for Papers for IDMS'97 to be held
September 10-12, 1997 in Darmstadt, Germany.
Apologies for duplicates you may receive through multiple mailing lists.
Best regards,
Lars
CALL FOR PAPERS
European Workshop on
Interactive Distributed Multimedia Systems and
Telecommunication Services
(IDMS'97)
10. - 12. September 1997
Darmstadt, Germany
In Cooperation with
ACM SIGMM
Gesellschaft fuer Informatik
GMD
IEEE Computer Society
VDE ITG
This Fourth International Workshop on Interactive Distributed Multimedia
Systems and Telecommunication Services follows the successful IDMS workshop
held 1996 in Berlin. The purpose of this workshop is to provide a forum for
the presentation, exploration and discussion of technologies and their
advancements in the broad field of interactive distributed multimedia
systems -- from basic system technologies such as networking and operating
system support to all kinds of multimedia applications. Furthermore, we are
also looking for work from related areas, including digital library, mobile
communication, VR, and software agents. Case studies and papers describing
experimental work are especially welcome.
Relevant topics include, but are not limited to
* High-speed and multimedia networks
* ATM networks and applications
* Mobile multimedia systems
* Multimedia communication protocols
* Compression algorithms
* Quality of service and media scaling
* Resource management
* Multimedia operating systems
* Synchronization
* Multimedia database and storage
* Video-on-demand systems, components and architectures
* Multimedia programming languages, abstractions & APIs
* Development tools for distributed multimedia applications
* Multimedia-specific intelligent agents
* Multimedia/hypermedia applications and tools, production and authoring
* Conferencing
* Computer supported collaborative work
* Digital libraries
* Interactive television
* Virtual reality systems
IDMS'97 will consist of one day of tutorials and two days of technical
presentations in an envisaged single-track. System and tool demonstrations
will be possible throughout the workshop. In order to keep the flavor of a
"workshop", participation will be restricted to about 100 participants. The
proceedings of the workshop will be published in the Springer LNCS series
and will be available during the workshop. Selected papers will be forwarded
to a special issue of the "Computer Communications" Journal.
Information for Authors
=======================
The working language of the workshop is English.
The submission process of papers will be handled electronically.
Detailed description of the electronic submission procedures are
available in the IDMS'97 web page
http://www.th-darmstadt.de/idms97/
Authors without web access may send mail to
idms97 at KOM.th-darmstadt.de
requesting electronic submission information.
Authors unable to submit electronically are invited to send 5 copies of
their full paper to the program chair:
Lars C. Wolf
Dept. of Electrical Engineering & Information Technology
Darmstadt University of Technology
Merckstr. 25, D-64283 Darmstadt, Germany
Manuscripts
-----------
Submitted manuscripts must describe original work (not submitted or
published elsewhere). The manuscripts must be no longer than 5000 words
(including references, tables, etc.), be typed double-spaced, contain an
abstract of approximately 300 words, and include title, authors and
affiliations. The author who serves as contact person must be marked
appropriately.
Panels
------
Suggestions for panels which present innovative, controversial, or otherwise
interesting ideas are welcome. Send a panel proposal of at most 3 pages
including a biographical sketch of the panelist to the general chair.
Important Dates
===============
Submissions due: 01. March 1997
Notification of acceptance: 15. May 1997
Camera-ready version due: 15. June 1997
General Chair
=============
Ralf Steinmetz, Darmstadt U., Germany
Email: Ralf.Steinmetz at KOM.th-darmstadt.de
Dept. of Electrical Engineering and Information Technology
Darmstadt University of Technology
Merckstr. 25, D-64283 Darmstadt, Germany
Fax: +49 6151 166152
Program Committee
=================
B. Butscher, DeTeBerkom, Germany
A. Danthine, U. Liege, Belgium
L. Delgrossi, Andersen Consulting, France
J. Eberspaecher, TU Munich, Germany
W. Effelsberg, U. Mannheim, Germany
J. Encarnacao, FhG-IGD, Germany
D. Ferrari, U. Cattolica, Italy
B. Furht, Florida Atlantic U., USA
N. Georganas, U. Ottawa, Canada
R.G. Herrtwich, RWE, Germany
A. Hopper, U. Cambridge / ORL, UK
J.P. Hubaux, EPFL, Switzerland
D. Hutchison, Lancaster U., UK
Y. Ip, Siemens AG, Germany
W. Kalfa, TU Chemnitz, Germany
T.D.C. Little, Boston U., USA
F. Mattern, Darmstadt U., Germany
E. Moeller, GMD FOKUS, Germany
K. Nahrstedt, U. Illinois, USA
E. Neuhold, GMD IPSI, Germany
S. Pink, SICS, Sweden
R. Popescu-Zeletin, TU Berlin, Germany
V. Rangan, U. California, USA
K. Rothermel, U. Stuttgart, Germany
J. Schweitzer, Siemens AG, Germany
J. Schweitzer, Siemens AG, Germany
H. Tokuda, Keio U., Japan
F. Williams, Ericsson, Germany
L. Wolf, Darmstadt U., Germany (Chair)
General Information
===================
For program information contact the Program Chair.
For additional information see World-Wide Web:
http://www.th-darmstadt.de/idms97
Local Organization
==================
For any details on transportation, accomodation, or any other local
arrangements please contact
Martin Karsten
Email: Martin.Karsten at KOM.th-darmstadt.de
(same address as general chair)
------------------------------------------------------------------------------
Dr.-Ing. Lars C. Wolf Email: Lars.Wolf at KOM.th-darmstadt.de
Industrial Process&System Communication http://www.th-darmstadt.de/fb/et/ipsk
Dept. Electr. Eng.&Information Techn. Tel.: +49-6151-16-6155 (Fax -6152)
Darmstadt University of Technology, Merckstr. 25, D-64283 Darmstadt, Germany
Received: from ietf.org by ietf.org id aa08163; 11 Nov 96 9:54 EST
Received: from cnri by ietf.org id aa07944; 11 Nov 96 9:52 EST
Received: from mailer1.lut.ac.uk by CNRI.Reston.VA.US id aa04800;
11 Nov 96 9:52 EST
Received: from sun-cc201.lboro.ac.uk [158.125.1.201] (root)
by mailer1.lut.ac.uk with smtp (Exim 0.56 #2)
id E0vMxhz-00004p-00; Mon, 11 Nov 1996 14:51:31 +0000
Received: from comth by sun-cc201.lboro.ac.uk with smtp (Exim 0.56 #2)
id E0vMxho-0002yw-00; Mon, 11 Nov 1996 14:51:20 +0000
Date: Mon, 11 Nov 1996 14:51:20 +0000 (GMT)
Sender:ietf-request at ietf.org
From: martin hamilton <M.T.Hamilton at lboro.ac.uk>
X-Sender: comth at sun-cc201
To: ietf at CNRI.Reston.VA.US
Subject: Re: Why More TLDs
In-Reply-To: <v03100704aeac6c671a61 at [204.179.131.85]>
Message-ID: <Pine.SOL.3.95.961111143533.29789C-100000 at sun-cc201>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 10 Nov 1996, Dave Crocker wrote:
> At 8:32 PM -0800 11/10/96, Paul A Vixie wrote:
> >Right now we use domain names, since they are universally unique, and they
> >are permanent. They are not, however, guessable.
>
> to emphasize for thos who may miss this point: guessability is the
> core characteristic of a 'directory' versus the completely deterministic
> behaviors of a mapping service like the dns. The difference between
> FINDING a name (and associated information) based on various criteria,
> possibly including the name, versus USING the name to find only and
> exactly the information associated with it is technically quite different
> tasks.
If anyone is interested in doing a little bit of practical experimentation
on the FINDING front, I'd like to volunteer a mailing list over here which
has been created for this purpose. Mail "deploy-request at mrrl.lut.ac.uk",
with the word "subscribe" on its own in the message body, if you want to
participate.
Recommended reading... RFCs 1714, 1777, 1798, 1835, 1913 and 1914, plus
draft-klensin-tld-whois-00.txt, and draft-ietf-find-new-cip-00.txt
Cheerio,
Martin
Received: from ietf.org by ietf.org id aa08526; 11 Nov 96 9:56 EST
Received: from cnri by ietf.org id aa08303; 11 Nov 96 9:55 EST
Received: from WLV.IIPO.GTEGSC.COM by CNRI.Reston.VA.US id aa04961;
11 Nov 96 9:55 EST
Received: from SPIELZEUG.IIPO.GTEGSC.COM (SPIELZEUG.IIPO.GTEGSC.COM [199.107.242.241]) by wlv.iipo.gtegsc.com (8.8.2/8.7.3) with SMTP id GAA25303; Mon, 11 Nov 1996 06:46:09 -0800 (PST)
Sender:ietf-request at ietf.org
From: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>
Message-Id: <961111064536.ZM13502 at SPIELZEUG.IIPO.GTEGSC.COM>
Date: Mon, 11 Nov 1996 06:44:56 -0700
In-Reply-To: Dave Crocker <dcrocker at brandenburg.com>
"Re: Why More TLDs" (Nov 10, 21:46)
References: lars at anchor.rns.com's message of 8 Nov 1996 00:22:46 -0800 <55uoo8$3d2 at anchor.rns.com>
<v03100704aeac6c671a61 at [204.179.131.85]>
X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996)
To: Dave Crocker <dcrocker at brandenburg.com>, Paul A Vixie <paul at vix.com>
Subject: Re: Why More TLDs
Cc: ietf at CNRI.Reston.VA.US
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
On Nov 10, 21:46, Dave Crocker wrote:
> Subject: Re: Why More TLDs
}At 8:32 PM -0800 11/10/96, Paul A Vixie wrote:
}>Right now we use domain names, since they are universally unique, and they
}>are permanent. They are not, however, guessable.
}
} to emphasize for thos who may miss this point: guessability is the
}core characteristic of a 'directory' versus the completely deterministic
}behaviors of a mapping service like the dns. The difference between
}FINDING a name (and associated information) based on various criteria,
}possibly including the name, versus USING the name to find only and
}exactly the information associated with it is technically quite different
}tasks.
We do have a rudimentary directory service: (r)whois. What is missing from
the mass-market Internet Software is a glitzy user interface and a discussion
of why and when it should be used. Using whois, one finds that BNONLINE.COM
belongs to Barnes & Noble and ORA.COM to O'Reilly & Associates. Good places
to start looking for a Web Page listing their available publications.
What we find, however, is the typical user with his Web browser open banging
away at the DNS trying different permutations of WWW.something.COM that might
lead him to where he wants to go. And, of course, he is conducting his search
using a product name instead of a manufacturer's name because he doesn't have
the Thomas Register sitting next to his computer.
As a result, we have the typical manufacturer trying to get registered under
.COM using his corporate name and each of his trademarked product names.
Increasing the number of TLDs is a "stop-gap" measure and not necessarily a
solution. If I know that O'Reilly & Associates uses ORA, the question is now
where do I find them?
ORA.COM
ORA.LTD
ORA.PTY
ORA.CIE
ORA.GMBH
ORA.CORP
ORA.AB
ORA.AG
ORA.xx.CA.US
Increasing the number of TLDs does allow us to eliminate some obscurity in
names but does not relieve the pressure on the DNS.
Assuming that there is a WWW.VOLVO.COM, what incentive is there for Volvo to
switch to WWW.VOLVO.AB?
Merton Campbell Crockett
Hasenthaler InfoSysteme
Received: from ietf.org by ietf.org id aa12683; 11 Nov 96 11:34 EST
Received: from mail.border.com by ietf.org id aa12541; 11 Nov 96 11:30 EST
Received: by janus.border.com id <18460-2>; Mon, 11 Nov 1996 11:27:19 -0500
Message-Id: <96Nov11.112719est.18460-2 at janus.border.com>
To: Skip Addison <SKIP_ADDISON at novell.com>
cc: egoshin at genesyslab.com, ietf at ietf.org
Subject: Re: Why More TLDs -Reply
References: <s2835953.058 at novell.com>
In-reply-to: Your message of "Fri, 08 Nov 1996 19:00:49 -0500".
<s2835953.058 at novell.com>
Sender:ietf-request at ietf.org
From: "C. Harald Koch" <chk at border.com>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 368 7157
X-uri: <URL:http://www.eng.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did at Pr9
Date:Mon, 11 Nov 1996 11:29:03 -0500
X-Orig-Sender: chk at border.com
Source-Info: From (or Sender) name not authenticated.
In message <s2835953.058 at novell.com>, Skip Addison writes:
> Trademarks are not at all unique, even within a geography. Two companies can use the same trademark name if
> their goods and services are unrelated. The requirement is simply that no relationship between the companies
> would be inferred by a "reasonable" consumer. I've seen some real life examples that escape me at the moment.
Apple Computer and Apple Records.
--
C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd.
chk at border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
+1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change."
+1 416 368 7789 (fax) | -Karen Murphy <karenm at descartes.com>
Received: from ietf.org by ietf.org id aa15822; 11 Nov 96 12:38 EST
Received: from cnri by ietf.org id aa15627; 11 Nov 96 12:35 EST
Received: from archimedes.inoc.sj.nec.com by CNRI.Reston.VA.US id aa09368;
11 Nov 96 12:35 EST
Received: by inoc.sj.nec.com (8.7.3/YDL1.7-930126.17)
id JAA10451(archimedes.inoc.sj.nec.com); Mon, 11 Nov 1996 09:33:59 -0800 (PST)
Received: by sj.nec.com (8.7.3/YDL1.7-940623.1)
id JAA29142(netkeeper.sj.nec.com); Mon, 11 Nov 1996 09:33:58 -0800 (PST)
Received: (from smtp at localhost) by firenode2.ibu.sj.nec.com (8.7.5/8.7.3) id JAA15534 for <ietf at cnri.reston.va.us>; Mon, 11 Nov 1996 09:31:14 -0800 (PST)
Received: from vegas.ibu.sj.nec.com (vegas.ibu.sj.nec.com [131.241.70.2]) by firenode2.ibu.sj.nec.com id rfJAA15531 for <<ietf at cnri.reston.va.us>>; Mon Nov 11 09:27:19 1996
Received: by vegas.ibu.sj.nec.com (8.6.9/YDL1.9-9507101400)
id JAA00651(vegas.ibu.sj.nec.com); Mon, 11 Nov 1996 09:29:28 -0800
Message-Id: <199611111729.JAA00651 at vegas.ibu.sj.nec.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Why More TLDs
Date: Mon, 11 Nov 1996 09:29:27 -0800
Sender:ietf-request at ietf.org
From: zen <zen at ibu.sj.nec.com>
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa19873; 11 Nov 96 14:07 EST
Received: from nacho.cisco.com by ietf.org id aa19664; 11 Nov 96 14:03 EST
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id LAA01182 for <ietf at ietf.org>; Mon, 11 Nov 1996 11:01:44 -0800
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id LAA22391 for <ietf at ietf.org>; Mon, 11 Nov 1996 11:01:41 -0800
X-Sender: fred at stilton.cisco.com
Message-Id: <v02140b00aea995443639 at [171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 11 Nov 1996 11:00:04 -0800
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Changes in the IETF Organization
Source-Info: From (or Sender) name not authenticated.
Permit me to take this opportunity to inform you of some changes in the
organization of the IETF, effective with the Memphis IETF meeting. At the
recent IESG Retreat (October 21-22) in Santa Barbara, we discussed the
direction of the Operations (formerly Operational Requirements) and the
Network Management Areas. We decided to merge them into a common Operations
and Management (O&M) Area. Mike O'Dell, the continuing Operations Area
Director, will be one of the Area Directors for O&M; the other is to be
determined by the Nominations Committee.
The purpose of this change is, as much as anything, to ensure a closer
liaison between the Network Management and the Operations communities. We
want to make very certain that network management is more than "making SNMP
work well"; it needs to be "SNMP and whatever else manages networks well" -
a strong operational focus.
All work which is currently being done in the Operations Area will be in
the O&M Area. This includes benchmarking, peformance analysis, management
of deployments and transitions, route policy, and some other issues.
Over the years, the Network Management community has developed a pool of
expertise in MIB development, embodied in the Network Management
Directorate. This important group will continue to exist in the O&M area,
and will continue to provide expertise in MIB development as a service to
their own and other areas.
Much of what has happened in the SNMP area is the development of MIBs. The
policy has been for some time that MIBs should really be developed by the
working group handling the protocol or other entity being managed.
Nonetheless, some MIB development has occurred in the Network Management
Area. The IESG will review these working groups during the transition; some
of will move to other areas, such as Internet or Applications. Those groups
that are closely tied to the evolution of management itself, like AgentX,
will move with the SNMP work to O&M. Groups that don't have a natural home
will be evaluated on a case by
case basis.
The development of SNMP itself, including the SNMP V2 Advisory Group
chaired by Russ Mundy, will be in the O&M Area. We expect that the work
identified and agreed to will be chartered in O&M, and will be carried out
with strong support from the Security community.
Thanks are due to Chuck Davin, Marshall Rose, and Deirdre Kostick for their
leadership of the area over the years, and to the many who have worked in
it. We hope that with this refocusing of vision, future network management
developments will build and improve on the groundwork that has been laid.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Fred Baker | While one person hesitates because
Cisco Systems | he feels inferior, the other is
519 Lado Drive | busy making mistakes and becoming
Santa Barbara, California 93111 | superior.
VOICE +1 408 526 4257 |
FAX +1 805 681-0115 | -- Henry C. Link
Received: from ietf.org by ietf.org id aa20088; 11 Nov 96 16:40 EST
Received: from cnri by ietf.org id aa19786; 11 Nov 96 16:34 EST
Received: from IG.CS.UTK.EDU by CNRI.Reston.VA.US id aa15593;
11 Nov 96 16:33 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id QAA21115; Mon, 11 Nov 1996 16:31:31 -0500 (EST)
Message-Id: <199611112131.QAA21115 at ig.cs.utk.edu>
X-Mailer: exmh version 1.6.7 5/3/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Paul A Vixie <paul at vix.com>
cc: ietf at CNRI.Reston.VA.US, moore at cs.utk.edu
Subject: Re: Why More TLDs
In-reply-to: Your message of "Sun, 10 Nov 1996 20:32:05 PST."
<VIXIE.96Nov10203203 at wisdom.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 11 Nov 1996 16:31:31 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> The simple answer to "why more TLD's?" is that 100% of the users on the
> Internet as of this date are abusing DNS as a directory service, and since
> DNS somewhat predictably does not work well as a directory service these
> people are trying to solve a "wrong technology" problem with a "more data"
> solution. It won't work but like lemmings to the sea, we just gotta do it.
Bingo.
> What I need and what the other 98% of Internet users who have not yet signed
> on need, is a way to say "does lucia's pizza in woodside have a URL?" and get
> something useful -- an authoritative "no" or a short/accurate list
> of possible "yes"'s.
Absolutely.
> The current TLD's were chosen by programmers rather than librarians. If you
> look at the average programmer's choice of file names and variable names and
> what not, you will see that programmers ought not, usually, be allowed to
> pick names -- especially names that have to map to real world objects.
And if you let librarians pick names, you'll get several different
names for the same object. And the schema for those names will change
over time as new topics/words are defined and the meanings of old
words change. Just like existing schema for the organization of
information, you'd generally need to be an expert in information
science to want to use them.
So I don't think this is the answer.
> What we *need* in DNS is to close the current TLD's to new registrations,
> get a bunch of librarians together and let them hammer out a new schema that
> will provide better splay (.COM is too flat), get leverage out of universal
> uniqueness and permanence, and publically sacrifice (stake through the heart)
> any possible guessability. And then we need an actual, real live directory
> service that works as well as the one the telephone companies provide now.
What we *need* is to stop trying to use DNS as a directory service.
Then we can let DNS be used for unique, transcribable, persistent
names, and let the directory services do the (inherently fuzzy)
matching.
Of course, before we can do that, we'll need a replacement that works.
Keith
Received: from ietf.org by ietf.org id aa22417; 11 Nov 96 17:24 EST
Received: from cnri by ietf.org id aa22177; 11 Nov 96 17:18 EST
Received: from nirvana.genesyslab.com by CNRI.Reston.VA.US id aa16843;
11 Nov 96 17:18 EST
Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id OAA03052; Mon, 11 Nov 1996 14:17:54 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA11043; Mon, 11 Nov 1996 14:17:22 -0800 (PST)
Date: Mon, 11 Nov 1996 14:17:22 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199611112217.OAA11043 at giant.genesyslab.com>
To: moore at cs.utk.edu, paul at vix.com
Subject: Re: Why More TLDs
Cc: ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
>From: Keith Moore <moore at cs.utk.edu>
>
>> What I need and what the other 98% of Internet users who have not yet signed
>> on need, is a way to say "does lucia's pizza in woodside have a URL?" and get
>> something useful -- an authoritative "no" or a short/accurate list
>> of possible "yes"'s.
>
>Absolutely.
>
>
>What we *need* is to stop trying to use DNS as a directory service.
>Then we can let DNS be used for unique, transcribable, persistent
>names, and let the directory services do the (inherently fuzzy)
>matching.
Service providers (not ISP, but companies with WWW-servers) need
"unique, transcribable, persistent names" to announce it, to publish it
for clients and they don't want that client will do some search in
non-unique directory service. This is the only reason of overcrowded .COM
At least this service may looks like "unique", during step up on tree
of names (city-state-country).
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa09302; 12 Nov 96 0:39 EST
Received: from cnri by ietf.org id af07398; 11 Nov 96 23:10 EST
Received: from IG.CS.UTK.EDU by CNRI.Reston.VA.US id aa20134;
11 Nov 96 20:02 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id UAA25880; Mon, 11 Nov 1996 20:00:46 -0500 (EST)
Message-Id: <199611120100.UAA25880 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Leonid Egoshin <egoshin at genesyslab.com>
cc: moore at cs.utk.edu, paul at vix.com, ietf at CNRI.Reston.VA.US
Subject: Re: Why More TLDs
In-reply-to: Your message of "Mon, 11 Nov 1996 14:17:22 PST."
<199611112217.OAA11043 at giant.genesyslab.com>
Date: Mon, 11 Nov 1996 20:00:46 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> >What we *need* is to stop trying to use DNS as a directory service.
> >Then we can let DNS be used for unique, transcribable, persistent
> >names, and let the directory services do the (inherently fuzzy)
> >matching.
>
> Service providers (not ISP, but companies with WWW-servers) need
> "unique, transcribable, persistent names" to announce it, to publish it
> for clients and they don't want that client will do some search in
> non-unique directory service.
All well and good. But if they want those names to be guessable,
or even mnemonic, they won't be unique any longer.
Keith
Received: from ietf.org by ietf.org id aa05315; 12 Nov 96 5:08 EST
Received: from cnri by ietf.org id aa05170; 12 Nov 96 5:03 EST
Received: from [194.170.125.24] by CNRI.Reston.VA.US id aa05541;
12 Nov 96 5:03 EST
Received: from [129.156.240.33] (kevin-mac [129.156.240.33]) by netcomm.NetComm.IE (8.8.0/8.7) with SMTP id IAA02421; Tue, 12 Nov 1996 08:48:41 +0400
X-Sender: kevinbr at 129.156.240.1
Message-Id: <aeadc13e030210040416 at [129.156.240.33]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 12 Nov 1996 08:57:16 +0300
To: Jim Fleming <JimFleming at unety.net>
Sender:ietf-request at ietf.org
From: Kevin Brown <kevinbr at netcomm.ie>
Subject: RE: Why More TLDs
Cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
'Paul A Vixie' <paul at vix.com>, 'New Newdom' <newdom at vrx.net>
Source-Info: From (or Sender) name not authenticated.
Paul,
The Internet will eventually follow real business practices. Today you look
in a paper yellow pages, but we believe that soon communities will have
their own yellow pages on the net.
We have done www.middle-east-pages.com that drills into each ME country,
where people may add links. When and if it gets full, we will drill down
into the City level, and then to the neighborhood. This needs to be done on
a worldwide basis. Eventually people will realise that regional directories
are superior to Yahoo.
Agreed about DNS, but like everything on the NET, Yahoo, IANA, everything
is very much US centric. I hope this will change.
regards,
Kevin
At 16:42 11/11/96, Jim Fleming wrote:
>On Sunday, November 10, 1996 2:32 PM, Paul A Vixie[SMTP:paul at vix.com] wrote:
>@ The simple answer to "why more TLD's?" is that 100% of the users on the
>@ Internet as of this date are abusing DNS as a directory service, and since
>@ DNS somewhat predictably does not work well as a directory service these
>@ people are trying to solve a "wrong technology" problem with a "more data"
>@ solution. It won't work but like lemmings to the sea, we just gotta do it.
>@
><snip>
>@
>@ Sure, I can find *something* if I ask for http://WWW.PIZZA.COM/ but it's not
>@ likely that I can find my local pizza shop that way. I can try Alta Vista
>@ or Yahoo, but it's going to be hard to find my local pizza shop that
>way, too.
>@ Therefore I use the telephone company's directory service ("can you give me
>@ the number for Lucia's Pizza in Woodside?") and then I use the telephone to
>@ call and get their URL so I can use HTTPS to order my pizza online. Then I
>@ keep it as a bookmark. Which is OK until I have 2,000 such bookmarks and I
>@ need to spend an hour per week cataloguing them.
>@
><snip>
>
>Paul,
>
>Rather than shift directory services to the DNS, you could
>also consider an alternative...
>
>You could become the webmaster for Woodside, California
>and help others place your "hot links" on...
>
> <http://comm.unety.net>
>
>...this will allow you to dynamically build a community
>directory, using descriptive categories and names. Once
>people discover the value of these types of directories,
>then the pressure will shift from using the DNS.
>
>P.S. Comm.unety.net was featured in the Chicago
>Tribune's Digital City project....
>
> <http://chicago.digitalcity.com/naperville/index.htm>
>
>...don't miss..."Pizza a slice of Naperville life."...:-)
>
>--
>Jim Fleming
>UNETY Systems, Inc.
>Naperville, IL
>
>e-mail:
>JimFleming at unety.net
>JimFleming at unety.net.s0.g0 (EDNS/IPv8)
////////////////////////////////////////////////////////////
Kevin Brown | N \ We operate in Ireland
NetComm | e / and the Middle East
Unix Training, Consultancy | t \ --IRELAND--
Networking | C / Voice: 353-1-282-7342
| o \ Fax: 353-1-282-7342
Sun Microsystems | m / --DUBAI--
Internet Associate | m \ Voice: 971-4-491476
| / Fax: 971-4-492957
| \ email: kevinbr at netcomm.ie
| / (Internet)
| \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Coming soon.......our UK office in Wokingham will open!
Received: from ietf.org by ietf.org id aa03046; 12 Nov 96 9:15 EST
Received: from taunivm.tau.ac.il by ietf.org id aa02297; 12 Nov 96 8:51 EST
Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 1808; Tue, 12 Nov 96 08:46:14 IST
Received: from VM.TAU.AC.IL (NJE origin HANK at TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2894; Tue, 12 Nov 1996 08:46:12 +0200
Date: Tue, 12 Nov 96 08:46:01 IST
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.tau.ac.il>
Subject: Re: iTLDs
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611120852.aa02297 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
>As a result, we have the typical manufacturer trying to get registered under
>..COM using his corporate name and each of his trademarked product names.
>
>Increasing the number of TLDs is a "stop-gap" measure and not necessarily a
>solution. If I know that O'Reilly & Associates uses ORA, the question is now
>where do I find them?
>
> ORA.COM
> ORA.LTD
> ORA.PTY
> ORA.CIE
> ORA.GMBH
> ORA.CORP
> ORA.AB
> ORA.AG
> ORA.xx.CA.US
>
>Increasing the number of TLDs does allow us to eliminate some obscurity in
>names but does not relieve the pressure on the DNS.
>
>Assuming that there is a WWW.VOLVO.COM, what incentive is there for Volvo to
>switch to WWW.VOLVO.AB?
Volvo may not be a good example, since you are right that they
would want to be registered in every iTLD. Local stores
do not need that global exposure.
Increasing the number of iTLDs is indeed a stopgap measure. As Paul
and others have pointed out we need to disconnect the DNS from a
directory service. The way to do this is the way Netscape has a
Net Search button built right into their browser.
What we need is for Netscape and Microsoft to build into their
4.0 versions of their browsers a 'Site Lookup' button, that
takes a user to a Web form that allows lookup for company name
by substring or phonetic match and using the Internic/RIPE/APNIC
DN databases as the base for the information supplied.
>Merton Campbell Crockett
>Hasenthaler InfoSysteme
Hank Nussbacher
Israel
Received: from cnri by ietf.org id aa05871; 12 Nov 96 10:29 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12543;
12 Nov 96 10:29 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <OAA21939 at pad-thai.cam.ov.com>; Tue, 12 Nov 1996 14:38:22 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA13420; Tue, 12 Nov 96 09:38:01 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <OAA21931 at pad-thai.cam.ov.com>; Tue, 12 Nov 1996 14:37:37 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id JAA00727; Tue, 12 Nov 1996 09:37:36 -0500
Message-Id: <199611121437.JAA00727 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Draft 1, San Jose CAT agenda
Date: Tue, 12 Nov 1996 09:37:35 -0500
From: John Linn <linn at cam.ov.com>
Here's a first draft for the San Jose CAT agenda, which is currently
rather sparse. If anyone has additional discussion topics to propose,
please make them known.
Thanks, ...
--jl
CAT agenda, 1996 San Jose IETF (Draft 1, 12 November)
Tuesday, 10 December, 0900-1130
GSS-V2 C bindings discussion
Wednesday, 11 December, 1530-1730.
1530-1545: John Myers (CMU), SASL
1545-1600: Brian Tung (ISI), pk-init
1600-1615: Denis Pinkas (Bull), updated SESAME mechanism
1615-1730: Revisited issues
Received: from ietf.org by ietf.org id aa12789; 12 Nov 96 10:49 EST
Received: from ietf.org by ietf.org id aa05520; 12 Nov 96 10:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-katsube-00.txt
Date: Tue, 12 Nov 1996 10:23:47 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611121023.aa05520 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Router Architecture Extensions for ATM : Overview
Author(s) : H. Esaki
Filename : draft-rfced-info-katsube-00.txt
Pages : 18
Date : 11/11/1996
This memo describes a new internetworking architecture which makes better
use of the property of ATM. IP datagrams are transferred along hop-by-hop
path via routers, but datagram assembly/disassembly and IP header
processing are not necessarily carried out at individual routers in the
proposed architecture. A concept of "Cell Switch Router (CSR)" is
introduced as a new internetworking equipment, which has ATM cell switching
capabilities in addition to conventional IP datagram forwarding. Proposed
architecture can provide applications with high-throughput and low-latency
ATM pipes while retaining current router-based internetworking concept. It
also provides applications with specific QoS/bandwidth by cooperating with
internetworking level resource reservation protocols such as RSVP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-katsube-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-katsube-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-katsube-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961111135510.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-katsube-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-katsube-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961111135510.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12786; 12 Nov 96 10:49 EST
Received: from ietf.org by ietf.org id aa05585; 12 Nov 96 10:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-brown-dcom-v1-spec-01.txt
Date: Tue, 12 Nov 1996 10:23:58 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611121023.aa05585 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Distributed Component Object Model Protocol -- DCOM/1.0
Author(s) : N. Brown, C. Kindel
Filename : draft-brown-dcom-v1-spec-01.txt
Pages : 34
Date : 11/11/1996
The Distributed Component Object Model protocol is an application-level
protocol for object-oriented remote procedure calls useful for distributed,
component-based systems of all types. It is a generic protocol layered on
the distributed computing environment (DCE) RPC specification and
facilitates the construction of task-specific communication protocols
through features such as: a platform neutral argument/parameter marshaling
format (NDR), the ability for objects to support multiple interfaces with a
safe, interface-level versioning scheme suited to independent evolution by
multiple parties, the ability to make authenticated connections and to
choose levels of channel security, and a transport-neutral data
representation for references (including by-value) to objects.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-brown-dcom-v1-spec-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-brown-dcom-v1-spec-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-brown-dcom-v1-spec-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961111170700.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-brown-dcom-v1-spec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-brown-dcom-v1-spec-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961111170700.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12783; 12 Nov 96 10:49 EST
Received: from ietf.org by ietf.org id aa05536; 12 Nov 96 10:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ids-iwps-schema-spec-02.txt
Date: Tue, 12 Nov 1996 10:23:49 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611121023.aa05536 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Directory
Services Working Group of the IETF.
Title : A Common Schema for the Internet White Pages Service
Author(s) : T. Genovese, B. Jennings
Filename : draft-ietf-ids-iwps-schema-spec-02.txt
Pages : 5
Date : 11/11/1996
The work is the result of the IETF Integrated Directory Services (IDS)
Working Group which proposes to establish a specification for a simple
Internet white pages service. To facilitate this effort it would be
helpful to have a common schema used by the various white page servers.
This document is designed to specify the basic set of attributes to be used
for a white page entry for an individual. This schema does not describe
how to represent other objects in the White page service. It does describe
how new objects can be defined and registered. This schema is independent
of implementations of the White Page service.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ids-iwps-schema-spec-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-iwps-schema-spec-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961111141516.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-iwps-schema-spec-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961111141516.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12800; 12 Nov 96 10:49 EST
Received: from ietf.org by ietf.org id aa05569; 12 Nov 96 10:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-lang-00.txt
Date: Tue, 12 Nov 1996 10:23:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611121023.aa05569 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Use of Language Codes in LDAP
Author(s) : M. Wahl, T. Howes
Filename : draft-ietf-asid-ldapv3-lang-00.txt
Pages : 7
Date : 11/11/1996
The Lightweight Directory Access Protocol [1] provides a means for clients
to interrogate and modify information stored in a distributed directory
system. The information in the directory is maintained as attributes [2]
of entries. Most of these attributes have syntaxes which are
human-readable strings, and it is desirable to be able to indicate the
natural language associated with attribute values.
This document describes how language codes [3] are carried in LDAP and are
to be interpreted by LDAP servers. All implementations must be prepared to
accept language codes in the LDAP protocols. Servers may or may not be
capable of storing attributes with language codes in the directory.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-lang-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-lang-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-lang-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961111150012.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-lang-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-lang-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961111150012.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12793; 12 Nov 96 10:49 EST
Received: from ietf.org by ietf.org id aa05487; 12 Nov 96 10:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-andrews-dns-hostnames-03.txt
Date: Tue, 12 Nov 1996 10:23:43 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611121023.aa05487 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Clarification on the use of Hostnames, Mail Boxes and
Mail Domains in the DNS
Author(s) : M. Andrews
Filename : draft-andrews-dns-hostnames-03.txt
Pages : 6
Date : 11/11/1996
At the protocol level, DNS domain names and records may contain arbitrary
binary data. However, many domain names and records are, or refer to,
hostnames, which are restricted by RFCs 952 and 1123 to contain only
certain characters. Similar restrictions apply to mail domain names,
RFC-821. This document identifies the types of domain names and records
which are hostnames / mail domain names, and specifies the circumstances
under which validation checks should be performed within the class IN.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-andrews-dns-hostnames-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-andrews-dns-hostnames-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-andrews-dns-hostnames-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961111133841.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-andrews-dns-hostnames-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-andrews-dns-hostnames-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961111133841.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12791; 12 Nov 96 10:49 EST
Received: from ietf.org by ietf.org id aa05552; 12 Nov 96 10:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-aboba-roam-nai-00.txt
Date: Tue, 12 Nov 1996 10:23:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611121023.aa05552 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Network Access Identifier
Author(s) : B. Aboba
Filename : draft-aboba-roam-nai-00.txt
Pages : 12
Date : 11/11/1996
This document describes issues relating to user identification in provision
of "roaming capability" for dialup Internet users. "Roaming capability"
may be loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of cases where roaming capability
might be required include ISP "confederations" and ISP-provided
corporate network access support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-aboba-roam-nai-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-aboba-roam-nai-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-aboba-roam-nai-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961111144758.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-aboba-roam-nai-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-aboba-roam-nai-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961111144758.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12796; 12 Nov 96 10:49 EST
Received: from ietf.org by ietf.org id aa05503; 12 Nov 96 10:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-almesberger-00.txt
Date: Tue, 12 Nov 1996 10:23:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611121023.aa05503 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Application REQuested IP over ATM (AREQUIPA)
Author(s) : W. Almesberger, J. Le Boudec, P. Oechslin
Filename : draft-rfced-info-almesberger-00.txt
Pages : 10
Date : 11/11/1996
This document specifies a method for allowing ATM-attached hosts that have
direct ATM connectivity to set up end-to-end IP over ATM connections within
the reachable ATM cloud, on request from applications, and for the
exclusive use by the requesting applications. This allows the requesting
applications to benefit in a straightforward way from ATM's inherent
ability to guarantee the quality of service (QoS).
Given a mapping from service classes, as defined by INTSERV[6], to
ATM traffic descriptors, Arequipa can be used to implement integrated
services over ATM link layers. Usage of Arequipa to provide integrated
services even if ATM is only available for intermediate links is not
discussed in this document but should be straight-forward.
The major advantage of using an approach like Arequipa is that it needs
to be implemented only on the hosts using it. It requires no extra service
(eg. NHRP or RSVP) to be deployed on the switches or routers of the
ATM cloud.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-almesberger-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-almesberger-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-almesberger-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961111134448.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-almesberger-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-almesberger-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961111134448.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23959; 12 Nov 96 11:59 EST
Received: from ietf.org by ietf.org id aa23440; 12 Nov 96 11:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-hmac-md5-01.txt
Date: Tue, 12 Nov 1996 11:52:19 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611121152.aa23440 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : HMAC: Keyed-Hashing for Message Authentication
Author(s) : H. Krawczyk, M. Bellare, R. Canetti
Filename : draft-ietf-ipsec-hmac-md5-01.txt
Pages : 8
Date : 11/08/1996
This document describes HMAC, a mechanism for message authentication using
cryptographic hash functions. HMAC can be used with any iterative
cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret
shared key. The cryptographic strength of HMAC depends on the properties
of the underlying hash function.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-hmac-md5-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961108101246.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-hmac-md5-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961108101246.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26598; 12 Nov 96 12:28 EST
Received: from cnri by ietf.org id aa26388; 12 Nov 96 12:26 EST
Received: from IG.CS.UTK.EDU by CNRI.Reston.VA.US id aa15930;
12 Nov 96 12:26 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id MAA29633; Tue, 12 Nov 1996 12:24:10 -0500 (EST)
Message-Id: <199611121724.MAA29633 at ig.cs.utk.edu>
X-Mailer: exmh version 1.6.7 5/3/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Leonid Egoshin <egoshin at genesyslab.com>
cc: moore at cs.utk.edu, ietf at CNRI.Reston.VA.US, paul at vix.com
Subject: Re: Why More TLDs
In-reply-to: Your message of "Mon, 11 Nov 1996 17:31:37 PST."
<199611120131.RAA14322 at giant.genesyslab.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Nov 1996 12:24:09 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> >> Service providers (not ISP, but companies with WWW-servers) need
> >> "unique, transcribable, persistent names" to announce it, to publish it
> >> for clients and they don't want that client will do some search in
> >> non-unique directory service.
> >
> >All well and good. But if they want those names to be guessable,
> >or even mnemonic, they won't be unique any longer.
> >
> Are you shure ? I know about service for money which construct
> guessable and mnemonic names for market something. Of course - unique !
> It is the purpose if you don't want a lack of potential customers attention.
Yes, there are business that do this. (New drugs especially tend to
have such synthetic names.) But there's also a general human tendency
to reuse names in such a way that their meanings change. Most of the
time, when we name something, we use words or parts of words which
already have meaning in other contexts. Even names origianlly chosen
to be unique, can be reused in this way...so that they aren't unique
any longer.
If every one who applied for a DNS name were required to make it be
globally unique, we wouldn't have nearly so many problems with
lawsuits. But most companies want their their DNS name to reflect
their company name (or their trademark, or their line of business,
e.g. "soap.com"). And most company names or trademarks weren't chosen
to be globally unique.
Keith
Received: from ietf.org by ietf.org id aa23854; 12 Nov 96 13:32 EST
Received: from refuge.Colorado.EDU by ietf.org id aa23609; 12 Nov 96 13:29 EST
Received: from refuge.Colorado.EDU (bevo at localhost [127.0.0.1]) by refuge.Colorado.EDU (8.7.5/8.7.3) with ESMTP id LAA18740; Tue, 12 Nov 1996 11:28:13 -0700 (MST)
Message-Id: <199611121828.LAA18740 at refuge.Colorado.EDU>
To: Hank Nussbacher <HANK at taunivm.tau.ac.il>
cc: ietf at ietf.org
Subject: Re: iTLDs
In-reply-to: Your message of "Tue, 12 Nov 1996 08:46:01 +0700."
<9611120852.aa02297 at ietf.org>
Date: Tue, 12 Nov 1996 11:28:12 -0700
Sender:ietf-request at ietf.org
From: John Bevilacqua <bevo at refuge.colorado.edu>
Source-Info: From (or Sender) name not authenticated.
Yes, and that 'Site Lookup' button should be a whois client, since whois
is the functional, embedded directory service. Perhaps the whois client
could be enhanced a bit to include the search types you have identified.
--bevo
UnixOps/University of Colorado
--------
> Increasing the number of iTLDs is indeed a stopgap measure. As Paul
> and others have pointed out we need to disconnect the DNS from a
> directory service. The way to do this is the way Netscape has a
> Net Search button built right into their browser.
>
> What we need is for Netscape and Microsoft to build into their
> 4.0 versions of their browsers a 'Site Lookup' button, that
> takes a user to a Web form that allows lookup for company name
> by substring or phonetic match and using the Internic/RIPE/APNIC
> DN databases as the base for the information supplied.
>
> >Merton Campbell Crockett
> >Hasenthaler InfoSysteme
>
> Hank Nussbacher
> Israel
--------
Received: from ietf.org by ietf.org id aa28645; 12 Nov 96 14:50 EST
Received: from morgan.cnu.edu by ietf.org id aa28384; 12 Nov 96 14:46 EST
Received: from redbeard.cnu.edu (redbeard.cnu.edu [137.155.12.211]) by morgan.cnu.edu (8.7.3/8.6.9) with SMTP id OAA23791; Tue, 12 Nov 1996 14:45:02 -0500 (EST)
Date: Tue, 12 Nov 1996 14:48:22 -0500 (EST)
Sender:ietf-request at ietf.org
From: "J. Patrick Narkinsky" <patrick at cnu.edu>
To: John Bevilacqua <bevo at refuge.colorado.edu>
cc: ietf at ietf.org
Subject: Re: iTLDs
In-Reply-To: <199611121828.LAA18740 at refuge.Colorado.EDU>
Message-ID: <Pine.GSO.3.95.961112144737.3197b-100000 at redbeard.cnu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 12 Nov 1996, John Bevilacqua wrote:
>
> Yes, and that 'Site Lookup' button should be a whois client, since whois
> is the functional, embedded directory service. Perhaps the whois client
> could be enhanced a bit to include the search types you have identified.
>
hrrrmmm... As a caveat - it should be a whois client that is smart
enough to look in multiple databases.
Patrick
---------------------------------------------------------------------------
J. Patrick Narkinsky |
<patrick at cnu.edu> | Over the router, through the bridge,
Comp. Systems Sr. Engineer | past the T1, bounce off MAE-East,
CNU Computer Center | nothing but net.
(804)594-7180 |
---------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa29085; 12 Nov 96 14:54 EST
Received: from zephyr.isi.edu by ietf.org id aa28663; 12 Nov 96 14:50 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA06416>; Tue, 12 Nov 1996 11:49:14 -0800
Message-Id: <199611121949.AA06416 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2011 on SNMPv2 MIB for IP
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 12 Nov 96 11:49:13 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2011:
Title: SNMPv2 Management Information Base
for the Internet Protocol using SMIv2
Author: K. McCloghrie, Editor
Date: November 1996
Mailbox: kzm at cisco.com
Pages: 18
Characters: 31,168
Updates/Obsoletes: 1213
URL: ftp://ds.internic.net/rfc/rfc2011.txt
This document is the MIB module which defines managed objects for
managing implementations of the Internet Protocol (IP) and its
associated Internet Control Message Protocol (ICMP). This RFC is
the product of the SNMP Working Group of the IETF.
IESG Note: The IP, UDP, and TCP MIB modules currently support only
IPv4. These three modules use the IpAddress type defined as an OCTET
STRING of length 4 to represent the IPv4 32-bit internet addresses.
(See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit
IPv6 internet addresses.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961112103144.RFC at ISI.EDU>
SEND /rfc/rfc2011.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2011.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961112103144.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01441; 12 Nov 96 15:18 EST
Received: from core.atmnet.net by ietf.org id aa01224; 12 Nov 96 15:17 EST
Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id MAA10860 for <ietf at ietf.org>; Tue, 12 Nov 1996 12:15:50 -0800 (PST)
Received: by jfbb.atmnet.net with Microsoft Mail
id <01BBD093.38277320 at jfbb.atmnet.net>; Tue, 12 Nov 1996 12:15:40 -0800
Message-ID: <01BBD093.38277320 at jfbb.atmnet.net>
Sender:ietf-request at ietf.org
From: Jim Browning <jfbb at atmnet.net>
To: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: iTLDs
Date: Tue, 12 Nov 1996 12:15:39 -0800
Encoding: 33 TEXT
Source-Info: From (or Sender) name not authenticated.
>From: John Bevilacqua[SMTP:bevo at refuge.colorado.edu]
>Sent: Tuesday, November 12, 1996 10:28 AM
>
>Yes, and that 'Site Lookup' button should be a whois client, since whois
>is the functional, embedded directory service. Perhaps the whois client
>could be enhanced a bit to include the search types you have identified.
Are you suggesting that domains at levels below those administered by the
registries be included in the whois database? Otherwise, wouldn't this
create an even greater desire for every entity to have a level two domain,
so that it would be found with a whois search? Any comprehensive directory
service must include those entities who have accepted domains that do not
currently appear in the whois directory, including addresses such as
"boulder.colorado.edu/~bevo/". A whois search for bevilacqua does not
currently provide this info...
Do we want a whois database that large, which the infrastructure
surrounding it which would be required to handle the traffic?
It is clear that the ability to guess a domain will erode over time, and
any successful introduction of additional TLDs will only serve to hasten
that erosion. As the ability to guess erodes, those commercial ventures
who are dealing with these problems will enjoy greater success, and enhance
their ability to locate specific entities, whereas right now they appear
focused on content oriented searches.
I think it best to spread the directory effort among the many commercial
enterprises who want to provide the service, with IETF ensuring that the
DNS system supports a reasonable technical approach that also accepts the
realities of the business environment.
--
Jim Browning
Received: from ietf.org by ietf.org id aa04992; 12 Nov 96 16:15 EST
Received: from ZAFU.BBN.COM by ietf.org id aa04775; 12 Nov 96 16:12 EST
Received: from [128.89.30.23] (ARA23.BBN.COM [128.89.30.23]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id QAA11545; Tue, 12 Nov 1996 16:10:39 -0500 (EST)
X-Sender: kent at po1.bbn.com (Unverified)
Message-Id: <v0300780baeae8e97f31c at [128.89.30.21]>
In-Reply-To: <199611101951.OAA03116 at raptor.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 12 Nov 1996 15:30:55 -0500
To: Steven Bellovin <smb at research.att.com>
Sender:ietf-request at ietf.org
From: Stephen Kent <kent at bbn.com>
Subject: Re: The cartel begins to crumble?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
I believe that Massachusetts is another state with a similar two-party
approval law re recording phone conversations.
Received: from ietf.org by ietf.org id aa05437; 12 Nov 96 16:24 EST
Received: from zephyr.isi.edu by ietf.org id aa05137; 12 Nov 96 16:20 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA12694>; Tue, 12 Nov 1996 13:18:58 -0800
Message-Id: <199611122118.AA12694 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2012 on SNMPv2 MIB for TCP
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 12 Nov 96 13:18:57 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2012:
Title: SNMPv2 Management Information Base for the
Transmission Control Protocol using SMIv2
Author: K. McCloghrie, Editor
Date: November 1996
Mailbox: kzm at cisco.com
Pages: 10
Characters: 16,792
Updates/Obsoletes: 1213
URL: ftp://ds.internic.net/rfc/rfc2012.txt
This document is the MIB module which defines managed objects for
managing implementations of the Transmission Control Protocol (TCP).
This RFC is the product of the SNMP Version 2 Working Group of the
IETF.
IESG Note: The IP, UDP, and TCP MIB modules currently support only
IPv4. These three modules use the IpAddress type defined as an OCTET
STRING of length 4 to represent the IPv4 32-bit internet addresses.
(See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit
IPv6 internet addresses.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961112131208.RFC at ISI.EDU>
SEND /rfc/rfc2012.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2012.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961112131208.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05676; 12 Nov 96 16:26 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa05520; 12 Nov 96 16:25 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id QAA15821; Tue, 12 Nov 1996 16:23:18 -0500 (EST)
Message-Id: <199611122123.QAA15821 at ig.cs.utk.edu>
X-Mailer: exmh version 1.6.7 5/3/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Hank Nussbacher <HANK at taunivm.tau.ac.il>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: iTLDs
In-reply-to: Your message of "Tue, 12 Nov 1996 08:46:01 +0700."
<9611120852.aa02297 at ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Nov 1996 16:23:18 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> What we need is for Netscape and Microsoft to build into their
> 4.0 versions of their browsers a 'Site Lookup' button, that
> takes a user to a Web form that allows lookup for company name
> by substring or phonetic match and using the Internic/RIPE/APNIC
> DN databases as the base for the information supplied.
Yes, this is precisely what's needed.
Keith
Received: from ietf.org by ietf.org id aa05834; 12 Nov 96 16:28 EST
Received: from cnri by ietf.org id aa05746; 12 Nov 96 16:27 EST
Received: from IG.CS.UTK.EDU by CNRI.Reston.VA.US id aa22908;
12 Nov 96 16:27 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id QAA15828; Tue, 12 Nov 1996 16:21:44 -0500 (EST)
Message-Id: <199611122121.QAA15828 at ig.cs.utk.edu>
X-Mailer: exmh version 1.6.7 5/3/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Zheng Wang <Z.Wang at cs.ucl.ac.uk>
cc: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>,
Dave Crocker <dcrocker at brandenburg.com>, Paul A Vixie <paul at vix.com>,
ietf at CNRI.Reston.VA.US, moore at cs.utk.edu
Subject: Re: Why More TLDs
In-reply-to: Your message of "Mon, 11 Nov 1996 23:24:37 GMT."
<13243.847754677 at cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Nov 1996 16:21:44 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> DNS is not a directory
> service but having easy to remember names is important. You dont
> want to search a directory or bookmarks (most people's
> bookmarks are rapidly becoming large directories) each time when you
> go to a web site. We want domain names like sun.com, not
> s8ssdk349.com. It can be done. All we need is some reasonable
> classification as TLDs.
>
> Yes, I agree we should get librarians and classification people
> to design the TLDs.
I don't think this is the answer, either. What we'd get is a set of
domain names which can be navigated, menu-style, but are not easy to
remember for those who aren't experts in the classification system.
Keith
p.s. The closest "real world" analogs to domain name labels that I've
found are stock ticker symbols and alphabetic telex addresses. Both
of these are short, unique (within their domain), and mnemonic, and
both of them tend to have rather strained mappings between the "real
world" name and the label. Maybe we should limit domain labels to six
characters?
Received: from ietf.org by ietf.org id aa08429; 12 Nov 96 16:57 EST
Received: from zephyr.isi.edu by ietf.org id aa08152; 12 Nov 96 16:54 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA13097>; Tue, 12 Nov 1996 13:27:53 -0800
Message-Id: <199611122127.AA13097 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2013 on SNMPv2 MIB for UDP
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 12 Nov 96 13:27:53 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2013:
Title: SNMPv2 Management Information Base
for the User Datagram Protocol using SMIv2
Author: K. McCloghrie, Editor
Date: November 1996
Mailbox: kzm at cisco.com
Pages: 6
Characters: 9,333
Updates/Obsoletes: 1213
URL: ftp://ds.internic.net/rfc/rfc2013.txt
This document is the MIB module which defines managed objects for
managing implementations of the User Datagram Protocol (UDP). This RFC
is a product of the SNMP Version 2 Working Group of the IETF.
IESG Note: The IP, UDP, and TCP MIB modules currently support only
IPv4. These three modules use the IpAddress type defined as an OCTET
STRING of length 4 to represent the IPv4 32-bit internet addresses.
(See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit
IPv6 internet addresses.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961112132028.RFC at ISI.EDU>
SEND /rfc/rfc2013.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2013.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961112132028.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09851; 12 Nov 96 17:11 EST
Received: from rip.psg.com by ietf.org id aa09685; 12 Nov 96 17:10 EST
Received: by rip.psg.com
id m0vNR0I-0007zZC; Tue, 12 Nov 96 14:08 PST (Smail3.1.29.1#1)
Message-Id: <m0vNR0I-0007zZC at rip.psg.com>
Date: Tue, 12 Nov 96 14:08 PST
Sender:ietf-request at ietf.org
From: Randy Bush <randy at psg.com>
To: Keith Moore <moore at cs.utk.edu>
Cc: ietf at ietf.org
Subject: Re: iTLDs
References: <9611120852.aa02297 at ietf.org>
<199611122123.QAA15821 at ig.cs.utk.edu>
Source-Info: From (or Sender) name not authenticated.
>> What we need is for Netscape and Microsoft to build into their
>> 4.0 versions of their browsers a 'Site Lookup' button, that
>> takes a user to a Web form that allows lookup for company name
>> by substring or phonetic match and using the Internic/RIPE/APNIC
>> DN databases as the base for the information supplied.
> Yes, this is precisely what's needed.
s/precisely/one example of/
I can think of other data bases which might transform interesting search
strings into URLs. I could see a market in such providers of mappings.
randy
Received: from ietf.org by ietf.org id aa11010; 12 Nov 96 17:20 EST
Received: from aspen.wwsi.com by ietf.org id aa10852; 12 Nov 96 17:18 EST
Received: from aspen.wwsi.com (localhost [127.0.0.1]) by aspen.wwsi.com (8.7.6/8.7.3) with ESMTP id QAA02827; Tue, 12 Nov 1996 16:17:05 -0700
Message-Id: <199611122317.QAA02827 at aspen.wwsi.com>
To: Keith Moore <moore at cs.utk.edu>
cc: Hank Nussbacher <HANK at taunivm.tau.ac.il>, ietf at ietf.org
Subject: Re: iTLDs
In-reply-to: Your message of "Tue, 12 Nov 1996 16:23:18 EST."
<199611122123.QAA15821 at ig.cs.utk.edu>
Mime-Version: 1.0 (generated by tm-edit 7.78)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 12 Nov 1996 16:17:05 -0700
Sender:ietf-request at ietf.org
From: Steve Hultquist <ssh at wwsi.com>
Source-Info: From (or Sender) name not authenticated.
>>>>> "Keith" == Keith Moore <moore at cs.utk.edu> writes:
>> What we need is for Netscape and Microsoft to build into their 4.0
>> versions of their browsers a 'Site Lookup' button, that takes a user
>> to a Web form that allows lookup for company name by substring or
>> phonetic match and using the Internic/RIPE/APNIC DN databases as the
>> base for the information supplied.
Keith> Yes, this is precisely what's needed.
Hmmm... Shouldn't the response be to build that search engine and then
suggest to either one of those companies or a third party search engine
provider that they host it for the "good of the 'net"? I'm not sure I
want the "browser wars" to turn into the "site lookup wars", with
incompatibility and redundancy all over the place. We have more
difficult problems to solve that need that kind of energy.
I agree, however, that this capability will go a long way towards making
the new TLDs actually usable. Without it, I see massive end-user
frustration as the initial result from the new domains. And that's
something we definitely *don't* need!
ssh
--
Steve Hultquist Business, system, network, and Internet
Worldwide Solutions, Inc. Engineering
Boulder, Colorado, USA 303.581.0800 http://www.wwsi.com
Received: from ietf.org by ietf.org id aa13002; 12 Nov 96 17:44 EST
Received: from [207.32.130.1] by ietf.org id aa12835; 12 Nov 96 17:42 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id QAA15921 for <ietf at ietf.org>; Tue, 12 Nov 1996 16:35:51 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBD0B7.DBFE76A0 at webster.unety.net>; Tue, 12 Nov 1996 16:37:57 -0600
Message-ID: <01BBD0B7.DBFE76A0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: ISOC IAHC
Date: Tue, 12 Nov 1996 16:37:55 -0600
Encoding: 32 TEXT
Source-Info: From (or Sender) name not authenticated.
@@@@ http://www.isoc.org/whatsnew/iahcmembers.html
"NEW INTERNATIONAL COMMITTEE NAMED
TO RESOLVE DOMAIN NAME SYSTEM ISSUES"
Dr. Donald N. Telage, president of the Herndon, Virginia - based
Network Solutions, Inc., which manages the InterNIC Registry
administering the .com, .net, .edu, and .org top level domains,
said: "Network Solutions has supported the registration process
and the growth of the Internet since 1991. We have seen its
evolution from a research and education tool to a powerful medium
for global communication and collaboration. The National Science
Foundation has played a critical role in the early governance activities,
and we support the Internet Society's efforts to review issues critical
to the future of Internet growth, evolution and governance. Network
Solutions will participate and support this effort enthusiastically
supplying our extensive operational knowledge as needed."
@@@@
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa18777; 13 Nov 96 8:27 EST
Received: from ng.netgate.net by ietf.org id aa17768; 13 Nov 96 8:23 EST
Received: from [204.179.132.128] ([204.179.128.254]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id PAA07185; Tue, 12 Nov 1996 15:56:12 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100705aeaeba76da05 at [204.179.132.128]>
In-Reply-To: <199611122123.QAA15821 at ig.cs.utk.edu>
References: Your message of "Tue, 12 Nov 1996 08:46:01 +0700."
<9611120852.aa02297 at ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Nov 1996 15:36:52 -0800
To: Keith Moore <moore at cs.utk.edu>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: iTLDs
Cc: Hank Nussbacher <HANK at taunivm.tau.ac.il>, ietf at ietf.org,
moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
At 1:23 PM -0800 11/12/96, Keith Moore wrote:
>> What we need is for Netscape and Microsoft to build into their
>> 4.0 versions of their browsers a 'Site Lookup' button, that
>
>Yes, this is precisely what's needed.
uhh, what data bases are to be consulted? How are they found?
What standards are used to consult them?
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa18784; 13 Nov 96 8:27 EST
Received: from ng.netgate.net by ietf.org id aa17439; 13 Nov 96 8:22 EST
Received: from [205.214.160.148] (d107.netgate.net [205.214.160.145]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id XAA03768; Tue, 12 Nov 1996 23:33:42 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100706aeaf272f4475 at [205.214.160.148]>
In-Reply-To: <199611130658.BAA01251 at ig.cs.utk.edu>
References: Your message of "Tue, 12 Nov 1996 22:03:11 PST."
<v0310070aaeaf1467d8a7 at [205.214.160.82]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Nov 1996 23:23:07 -0800
To: Keith Moore <moore at cs.utk.edu>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: iTLDs
Cc: Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 10:58 PM -0800 11/12/96, Keith Moore wrote:
>The server is implemented using "big flat server technology"
ahh. this is the "one true data base" model. All companies in the
world need to be listed in it. sounds ambitious. can wait to see the
scaling behavior. Keeping it up to date is going to be another interesting
exercise.
By the way, where does it get its data from?
>> Seems to me either the user knows a heck of a lot, so they can go to a
>> correct, specialized data base, or else we have the requirement for a
=2E..
>Neither one. How many different kinds of telephone books do we need?
>Do users have to know "a heck of a lot" to decide whether to use the
>yellow pages or the white pages, or to decide whether to call
You have to know the city, or at least the metropolitan area.
That's a heck of a lot.
using a yellow pages can get pretty interesting, too, but yes, I
think it's a dandy model to start with.
d.
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa18793; 13 Nov 96 8:27 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa16453; 13 Nov 96 8:17 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id BAA01251; Wed, 13 Nov 1996 01:58:39 -0500 (EST)
Message-Id: <199611130658.BAA01251 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Dave Crocker <dcrocker at brandenburg.com>
cc: Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
Subject: Re: iTLDs
In-reply-to: Your message of "Tue, 12 Nov 1996 22:03:11 PST."
<v0310070aaeaf1467d8a7 at [205.214.160.82]>
Date: Wed, 13 Nov 1996 01:58:39 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> At 6:20 PM -0800 11/12/96, Keith Moore wrote:
> >Nah. We don't have to solve the general distributed directory problem.
> >And for a single-purpose database, like one that matches company names
> >and returns pointers to their web pages, the solution can be quite simple.
> >
> >We're quite capable of building large centralized databases and replicating
> >them at multiple sites. The interface to these can be as simple as a
> >profile of whois or http.
>
> Keith, I guess I just plain don't understand the usage scenario.
> What does a user have to know?
He has to know how to use a web browser, and the (approximate) name of
the company he wants to search for (say, as good as he'd have to give
to telephone directory assistance).
> How do they use it?
Probably, the user just has to type in the company name into his
web browser's "go to" blank. The web browser will notice that
it doesn't look like a URI or domain name, and will send the query
to the directory service.
Present day web browsers would store the URL for the directory service
as a bookmark.
> How does it work.
The browser sends an http POST request to one of the locations of
the directory service, and gets back html. If the original query
was too ambiguous to return a small number of possible matches, the
response either asks the user to be more specific (just like
telephone directory assistance), or lets the user browse through
an list of possible matches (just like a telephone directory).
The server is implemented using "big flat server technology"
(altavista or lycos or whatever, except that only the names
and acronyms of companies are indexed, rather than the full
text of articles like we're used to seeing from these servers.)
> Seems to me either the user knows a heck of a lot, so they can go to a
> correct, specialized data base, or else we have the requirement for a
> highly integrated, global, distributed system. If the former, we really
> are requiring the end user to have quite a lot of information. Otherwise,
> we are requiring the data base service to do a lot.
Neither one. How many different kinds of telephone books do we need?
Do users have to know "a heck of a lot" to decide whether to use the
yellow pages or the white pages, or to decide whether to call
"800 number directory assistance" versus "local directory assistance"?
Which is not to say that there won't be other ways to search for
web pages, but this is a special-purpose server that happens to
be useful in a large number of situations.
Keith
Received: from ietf.org by ietf.org id aa18776; 13 Nov 96 8:27 EST
Received: from ng.netgate.net by ietf.org id aa17451; 13 Nov 96 8:22 EST
Received: from [205.214.160.148] (d110.netgate.net [205.214.160.148]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id WAA01580; Tue, 12 Nov 1996 22:42:51 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v0310070aaeaf1467d8a7 at [205.214.160.82]>
In-Reply-To: <199611130220.VAA27470 at ig.cs.utk.edu>
References: Your message of "Tue, 12 Nov 1996 17:26:31 PST."
<v03100700aeaed3a19de9 at [204.179.132.128]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Nov 1996 22:03:11 -0800
To: Keith Moore <moore at cs.utk.edu>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: iTLDs
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 6:20 PM -0800 11/12/96, Keith Moore wrote:
>Nah. We don't have to solve the general distributed directory problem.
>And for a single-purpose database, like one that matches company names
>and returns pointers to their web pages, the solution can be quite simple.
>
>We're quite capable of building large centralized databases and replicating
>them at multiple sites. The interface to these can be as simple as a profi=
le
>of whois or http.
Keith, I guess I just plain don't understand the usage scenario.
What does a user have to know? How do they use it? How does it work.
Seems to me either the user knows a heck of a lot, so they can go to a
correct, specialized data base, or else we have the requirement for a
highly integrated, global, distributed system. If the former, we really
are requiring the end user to have quite a lot of information. Otherwise,
we are requiring the data base service to do a lot.
What am I missing (and how do I figure out what data base to go to
to get the answer...)
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa18757; 13 Nov 96 8:27 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa16490; 13 Nov 96 8:17 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id VAA27470; Tue, 12 Nov 1996 21:20:55 -0500 (EST)
Message-Id: <199611130220.VAA27470 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Dave Crocker <dcrocker at brandenburg.com>
cc: Keith Moore <moore at cs.utk.edu>, Hank Nussbacher <HANK at taunivm.tau.ac.il>,
ietf at ietf.org
Subject: Re: iTLDs
In-reply-to: Your message of "Tue, 12 Nov 1996 17:26:31 PST."
<v03100700aeaed3a19de9 at [204.179.132.128]>
Date: Tue, 12 Nov 1996 21:20:54 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> At 4:12 PM -0800 11/12/96, Keith Moore wrote:
> >> uhh, what data bases are to be consulted? How are they found?
> >
> >The data bases should be selectable by the client. Users will
> >find out about them the same way they find out about other
> >information services.
>
> Oh? So the solution to the fuzzy searching problem is moved from
> trying to figure out what your company's domain name is to trying to figure
> out what data bases your company is listed in? (No. Really. I mean the
> question seriously.)
The solution is to encourage the development/deployment of extensive
data bases of company names that happen to have a presence on
the Internet.
Actually, several companies have managed to develop such services
already; what we need is a standard interface between these services
and web browsers.
> >We need to develop standards (or more likely, profiles of existing
> >standards) for them.
>
> ahh. that's fine. It also means that we won't have a deployed
> solution available for at least a couple of years.
Nah. We don't have to solve the general distributed directory problem.
And for a single-purpose database, like one that matches company names
and returns pointers to their web pages, the solution can be quite simple.
We're quite capable of building large centralized databases and replicating
them at multiple sites. The interface to these can be as simple as a profile
of whois or http.
Keith
Received: from ietf.org by ietf.org id aa18787; 13 Nov 96 8:27 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa16496; 13 Nov 96 8:17 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id TAA19356; Tue, 12 Nov 1996 19:12:59 -0500 (EST)
Message-Id: <199611130012.TAA19356 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Dave Crocker <dcrocker at brandenburg.com>
cc: Keith Moore <moore at cs.utk.edu>, Hank Nussbacher <HANK at taunivm.tau.ac.il>,
ietf at ietf.org
Subject: Re: iTLDs
In-reply-to: Your message of "Tue, 12 Nov 1996 15:36:52 PST."
<v03100705aeaeba76da05 at [204.179.132.128]>
Date: Tue, 12 Nov 1996 19:12:59 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> uhh, what data bases are to be consulted? How are they found?
The data bases should be selectable by the client. Users will
find out about them the same way they find out about other
information services.
> What standards are used to consult them?
We need to develop standards (or more likely, profiles of existing
standards) for them.
Keith
Received: from ietf.org by ietf.org id aa18790; 13 Nov 96 8:27 EST
Received: from ng.netgate.net by ietf.org id aa17725; 13 Nov 96 8:23 EST
Received: from [205.214.160.82] (d48.netgate.net [205.214.160.82]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id SAA16010; Tue, 12 Nov 1996 18:08:53 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100700aeaed3a19de9 at [204.179.132.128]>
In-Reply-To: <199611130012.TAA19356 at ig.cs.utk.edu>
References: Your message of "Tue, 12 Nov 1996 15:36:52 PST."
<v03100705aeaeba76da05 at [204.179.132.128]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Nov 1996 17:26:31 -0800
To: Keith Moore <moore at cs.utk.edu>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: iTLDs
Cc: Keith Moore <moore at cs.utk.edu>, Hank Nussbacher <HANK at taunivm.tau.ac.il>,
ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 4:12 PM -0800 11/12/96, Keith Moore wrote:
>> uhh, what data bases are to be consulted? How are they found?
>
>The data bases should be selectable by the client. Users will
>find out about them the same way they find out about other
>information services.
Oh? So the solution to the fuzzy searching problem is moved from
trying to figure out what your company's domain name is to trying to figure
out what data bases your company is listed in? (No. Really. I mean the
question seriously.)
>> What standards are used to consult them?
>
>We need to develop standards (or more likely, profiles of existing
>standards) for them.
ahh. that's fine. It also means that we won't have a deployed
solution available for at least a couple of years. (Lest folks miss the
history, there have been efforts at global data base service underway since
1984. No doubt we will yet get one, but the history says it will take
awhile. Probably not soon enough to eliminate the immediate domain name
problem.)
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa18758; 13 Nov 96 8:27 EST
Received: from WLV.IIPO.GTEGSC.COM by ietf.org id aa17906; 13 Nov 96 8:24 EST
Received: from MCC.IIPO.GTEGSC.COM (MCC.IIPO.GTEGSC.COM [199.107.242.254]) by wlv.iipo.gtegsc.com (8.8.2/8.7.3) with SMTP id QAA08651; Tue, 12 Nov 1996 16:28:31 -0800 (PST)
Sender:ietf-request at ietf.org
From: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>
Message-Id: <961112162812.ZM3302 at MCC.IIPO.GTEGSC.COM>
Date: Tue, 12 Nov 1996 16:28:09 -0700
In-Reply-To: Hank Nussbacher <HANK at taunivm.tau.ac.il>
"Re: iTLDs" (Nov 12, 8:46)
References: <9611120852.aa02297 at ietf.org>
X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996)
To: Hank Nussbacher <HANK at taunivm.tau.ac.il>, ietf at ietf.org
Subject: Re: iTLDs
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
On Nov 12, 8:46, Hank Nussbacher wrote:
> Subject: Re: iTLDs
|
|Increasing the number of iTLDs is indeed a stopgap measure. As Paul
|and others have pointed out we need to disconnect the DNS from a
|directory service. The way to do this is the way Netscape has a
|Net Search button built right into their browser.
|
|What we need is for Netscape and Microsoft to build into their
|4.0 versions of their browsers a 'Site Lookup' button, that
|takes a user to a Web form that allows lookup for company name
|by substring or phonetic match and using the Internic/RIPE/APNIC
|DN databases as the base for the information supplied.
Jon Postel forwarded the following URL. This is based on the RS.INTERNIC.NET
whois database.
http://netpart.com/free/search.html
It provides a list of possible Web Servers and Anonymous FTP servers based on
the assumption there is, at least, a CNAME for WWW and FTP in the domain.
This would be a start for Netscape, Microsoft, Spyglass, etc. to include a
lookup feature with this type of information. Also, something that online
services should be doing as well.
While this does eliminate some of the DNS guessing traffic, its principal
advantage is that it makes other TLDs more appealing. If there someway for
the home user to determine what there is besides .com, one might entice movie
production companies to join an .mpc domain.
|
|Hank Nussbacher
|Israel
|
>-- End of excerpt from Hank Nussbacher
Merton Campbell Crockett
Hasenthaler InfoSysteme
Received: from ietf.org by ietf.org id aa20072; 13 Nov 96 8:31 EST
Received: from core.atmnet.net by ietf.org id aa19764; 13 Nov 96 8:30 EST
Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id UAA19868; Tue, 12 Nov 1996 20:38:25 -0800 (PST)
Received: by jfbb.atmnet.net with Microsoft Mail
id <01BBD0D9.713B1A40 at jfbb.atmnet.net>; Tue, 12 Nov 1996 20:38:20 -0800
Message-ID: <01BBD0D9.713B1A40 at jfbb.atmnet.net>
Sender:ietf-request at ietf.org
From: Jim Browning <jfbb at atmnet.net>
To: "'davidk at ISI.EDU'" <davidk at isi.edu>
Cc: "ietf at ietf.org" <ietf at ietf.org>,
'IAHC Mailing List' <iahc-discuss at imc.org>
Subject: RE: iTLDs
Date: Tue, 12 Nov 1996 20:38:19 -0800
Encoding: 95 TEXT
Source-Info: From (or Sender) name not authenticated.
>From: davidk at ISI.EDU[SMTP:davidk at ISI.EDU]
>Sent: Tuesday, November 12, 1996 7:38 AM
>
>> Jim Browning writes :
>>
>> >From: John Bevilacqua[SMTP:bevo at refuge.colorado.edu]
>>
>> Are you suggesting that domains at levels below those administered by
the
>> registries be included in the whois database? Otherwise, wouldn't this
>> create an even greater desire for every entity to have a level two
domain,
>> so that it would be found with a whois search?
>
>The RIPE database that is used by the European IP registry and many TLD
>administrators in Europe and other parts of the world supports creation
>of lower-level domain objects including a hierarchical authorization
>model for creating the entries. So yes, this is already being done and
>possible.
>
>However, why do you need sub-level domain information registered for this
?!?
>
>You are looking for information on a company/person when doing a query
>for a company/person name whether you want to find out about his/her
>Internet phone number, E-mail address or web URL. This can be done with
>any whois service by adding URL data to each company/person entry (in
>fact people are already finding out how usefull this is and are doing
>this in the RIPE database although it's not designed and *intended* to be
>used as a white/yellow pages service for the Internet). You don't need to
>have sub-level domains registered with a registry for this approach.
In other words, a return to the days when most people with Email addresses
were in the database and could be located with a simple lookup...
>The problem remains (and might be insolvable) that person/company name
>indices are a flat name space and cannot very easily be distributed to
>more different *and* competing companies, and still keep a transparent
>and efficient system for the user, ISPs and webbrowser implementor.
>
>A not-for-profit consortium might be a much better organization type for
>such a service (note: this doesn't mean that Jim Fleming is not allowed
>to start his own service, in contrary some competion will keep the
>consortium awake) since every member can accept to handle a part of the
>flat name space (example: all keys ab[a-z]*) and gets approval for adding
>data to the directory services of other members (ISPs) that are managing
>other parts of the index name space when becoming a member (ISP).
I may be missing something (more), but if there is a single database where
the information is originally entered (the whois database), can it not then
be made available to any number of entities who might want to provide
lookup services for the entire database? This would provide competition to
develop the best set of tools. Of course, given that the providers of the
directory systems would not be building their own proprietary (lucrative)
database, it might be necessary to have a not-for-profit entity provide the
service, thus encouraging *everyone* to register in the official database.
I suspect that if the not-for-profit entity tackled the database, it could
be licensed (probably without fee) to multiple directory providers,
enabling the desired competition without splintering the database.
>And yes, the importance of having your own nice looking DNS name will
>decrease and the importance of being registered at the root or lower
>down is not so much important anymore and thus running a TLD might not
>be that much of a revenue source as some business people hope it will be.
How awful that would be.. ;-) But OTOH competition is good..
>Solutions that only involve new TLDs might very well increase the costs
>for most of us since more popular TLDs will be able to ask *higher*
>prices then they do now and you need to register in more then one popular
>TLD to keep up with the competion... (My elektricien is now paying $100.-
>a month to get registered in all local yellow pages phone services with
>just a single line *and* his customers (me) are paying that).
I agree that the new TLDs will increase the need for a directory service,
and think that this is one of the sources of revenue the new registries
will pursuing.
>However, it's our own fault if this happens because there is no reason
>what so ever that we cannot design a good directory service that will
>diminish the value of having a nice short recognizable/trademarked domain
>name whether there are a few or thousands of TLDs. So let's use our
>(valuable) time to get a good and cheap directory service running instead
>of wasting our time on discussing the inevitable evolution towards more
TLDs.
New TLDs are inevitable for a variety of reasons, not the least of which is
the desire for registry competition and the need to dilute the
impact/benefit of having the appropriate .com domain. I am cross-posting
this to the new IAHC list. Perhaps participation in a directory service
can be made a requirement for new TLD registries, or the funds derived from
the new registries can be used to fund a directory service.
--
Jim Browning
Received: from cnri by ietf.org id aa22419; 13 Nov 96 8:48 EST
Received: from ietf.org by CNRI.Reston.VA.US id aa09442; 13 Nov 96 8:48 EST
Received: from ietf.org by ietf.org id aa22411; 13 Nov 96 8:48 EST
Received: from venera.isi.edu by ietf.org id aa22407; 13 Nov 96 8:48 EST
Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-25)
id <AA13244>; Tue, 12 Nov 1996 18:03:25 -0800
Received: from zen.isi.edu (zen-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA05084>; Tue, 12 Nov 1996 18:03:09 -0800
Date: Tue, 12 Nov 1996 18:03:01 -0800
Sender:iesg-request at ietf.org
From: postel at isi.edu
Posted-Date: Tue, 12 Nov 1996 18:03:01 -0800
Message-Id: <199611130203.AA07631 at zen.isi.edu>
Received: by zen.isi.edu (5.65c/4.0.3-6)
id <AA07631>; Tue, 12 Nov 1996 18:03:01 -0800
To: iesg at isi.edu, iab at isi.edu, ietf at ietf.org
Subject: IAHC Members Announced
Subject: IAHC Members Announced
Date: Tue, 12 Nov 96 14:50:00 EST
From: major at linus.isoc.org
Contact:
Internet Society
12020 Sunrise Valley Drive
Reston, VA 20191-3429
TEL 703-648-9888
FAX 703-648-9887
E-mail info at isoc.org
http://www.isoc.org
NEW INTERNATIONAL COMMITTEE NAMED
TO STUDY DOMAIN NAME SYSTEM ISSUES
WASHINGTON, DC, November 12, 1996 -- An Internet International Ad Hoc
Committee (IAHC) has been named to resolve issues resulting from
current international debate over a proposal to establish additional
global registries and international Top Level Domain (iTLDs).
"We are pleased to have attracted such a high level of leading
international experts in their fields to examine these questions that
are critical to the current and future growth of the Internet," Donald
M. Heath, president and CEO of the Internet Society said in announcing
the eleven-member committee. Heath will serve as chairman.
Deliberations of the committee may lead to the establishment of new
international Top Level Domains (iTLDs), adding to the current
three-letter tags, such as .com, .net, and .org, that end many Internet
email and World Wide Web addresses.
Dr. Donald N. Telage, president of the Herndon, Virginia - based
Network Solutions, Inc., which manages the InterNIC Registry
administering the .com, .net, .edu, and .org top level domains, said:
"Network Solutions has supported the registration process and the
growth of the Internet since 1991. We have seen its evolution from a
research and education tool to a powerful medium for global
communication and collaboration. The National Science Foundation has
played a critical role in the early governance activities, and we
support the Internet Society's efforts to review issues critical to the
future of Internet growth, evolution and governance. Network Solutions
will participate and support this effort enthusiastically supplying our
extensive operational knowledge as needed."
Named to the new IAHC are:
o Sally M. Abel, specializes in international trademark and trade name
counseling, chairs the Internet Subcommittee of the International
Trademark Association (INTA), and will represent that organization on
the IAHC. Ms. Abel is the partner in charge of the Trademark Group
of the law firm of Fenwick and West, a Palo Alto, Ca. firm
specializing in high technology matters.
O Dave Crocker, is co-founder of the Internet Mail Consortium, an
industry trade association. He is also a principal with Brandenburg
Consulting in Sunnyvale, Ca., a firm specializing in guiding the
development and use of Internet applications. With ten years in the
ARPA research community, ten years developing commercial network
products and services, and extensive contributions to the Internet
Engineering Task Force, he is considered an expert about the
Internet, e-mail, electronic commerce, Internet operation and the
Internet standards process.
o Geoff Huston is the technical manager of Australia's Telstra
Internet and is responsible for the architecture and operations of
its service. He formerly was technical manager of the Australian
Academic and Research Network, and was largely responsible for the
introduction and subsequent development of the Internet into
Australia.
o David W. Maher, is a partner at the law firm of Sonnenschein Nath &
Rosenthal, of Chicago, IL, is a registered patent attorney and has
extensive experience in intellectual property and entertainment law.
Principal outside trademark counsel for several nationwide companies,
he has served as special counsel to the American Bar Association for
telecommunications matters.
o Perry E. Metzger is the president of New York - based Piermont
Information Systems Inc., a consulting firm specializing in
communications and computer systems security. He has worked with the
New York financial community for many years and is active in the
Internet Engineering Task Force's (IETF) security area, chairing the
group's Simple Public Key Infrastructure working group.
o Jun Murai is associate professor of Faculty of Environmental
Information at Keio University in Tokyo. He developed JUNET, Japan's
first UUCP network and the WIDE Internet, Japan's first IP network.
He is president of the Japan Network Information Center (JPNIC) and
serves as adjunct professor at the Institute of Advanced Studies of
the United Nations University in Tokyo.
o Hank Nussbacher, is an independent networking consultant, currently
works with IBM Israel as Internet Technology Manager and has been
responsible for all aspects in establishing IBM Israel as a major ISP
in Israel. He also consults to the Israeli inter-university
consortium and is on the board of directors of the Internet Society
of Israel.
o Robert Shaw is an advisor on Global Information Infrastructure (GII)
issues at the International Telecommunication Union (ITU). The ITU,
based in Geneva, Switzerland, is a United Nations treaty organization
within which governments and the private sector coordinate global
telecom networks and services.
o George Strawn is with the US National Science Foundation (NSF),
which has funded Internet development for research and education.
Mr. Strawn has been involved with the NSF's Internet activities for
the last five years and also co-chairs the Federal Networking
Council, a US government committee coordinating inter-agency Internet
activities, including funding for administrative activities, such as
the Internet Assigned Numbers Authority (IANA).
o Albert Tramposch is senior legal counsellor at the World
Intellectual Property Organization (WIPO) in Geneva. WIPO is a United
Nations organization which has responsibility for the promotion of
the protection of intellectual property throughout the world. It
also administers various treaties dealing with legal and
administrative aspects of intellectual property, including the
international registration of trademarks.
In addition, Stuart Levi, a partner in the New York Office of Skadden,
Arps, Slate, Meagher & Flom, and the head of the firm's Computer and
Information Technology Practice, will serve as outside counsel
supporting the IAHC.
"The IAHC will be charged with fairly and openly looking at the complex
issues surrounding the current domain name and registry situation,
including trademark and infringement, economics and administration of
registry operations, dispute policies, fees and iTLDs," Heath said. He
anticipates the Committee reaching reasonable consensus on issues
surfaced, sometime in January. A subset of the IAHC will seek to
implement its recommendations very shortly after that.
To meet its aggressive schedule, the widely dispersed group will
primarily operate online, over the Internet. Interested parties
throughout the Internet world will be able to participate in the IAHC's
process, through an electronic mail list service and a Web site that
are being established. Discussions, evaluations and decisions will be
available for public inspection. An archive, and relevant documents,
will be available public comment at the Web site which will be
established by November 15 at http://www.iahc.org. To subscribe to the
IAHC's email list service, send email with the word "subscribe" to:
iahc-discuss-request at iahc.org.
# # # # # # #
Received: from ietf.org by ietf.org id aa24275; 13 Nov 96 8:51 EST
Received: from zephyr.isi.edu by ietf.org id aa23443; 13 Nov 96 8:50 EST
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA13370>; Tue, 12 Nov 1996 20:12:57 -0800
Date: Tue, 12 Nov 1996 20:12:57 -0800
Sender:ietf-request at ietf.org
From: Jon Postel <postel at isi.edu>
Message-Id: <199611130412.AA13370 at zephyr.isi.edu>
To: ietf at ietf.org
Subject: directory of companies (was Re: iTLDs)
Source-Info: From (or Sender) name not authenticated.
Hi.
Here is a service that can reduce the pressure on domain names to be a
directory service. Try this out!
http://netpart.com/free/search.html
It is not perfect, but it is an indication of something that can be
done to make life better, and reduce the importance of having an
obvious domain name.
--jon.
Received: from ietf.org by ietf.org id aa24287; 13 Nov 96 8:51 EST
Received: from zephyr.isi.edu by ietf.org id aa23577; 13 Nov 96 8:50 EST
Received: from brind.isi.edu (old-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA24639>; Tue, 12 Nov 1996 15:40:40 -0800
Sender:ietf-request at ietf.org
From: davidk at isi.edu
Posted-Date: Tue, 12 Nov 1996 15:37:38 -0800 (PST)
Message-Id: <9611122337.AA00892 at brind.isi.edu>
Received: by brind.isi.edu (4.1/4.0.3-6)
id <AA00892>; Tue, 12 Nov 96 15:37:38 PST
Subject: Re: iTLDs
To: Jim Browning <jfbb at atmnet.net>
Date: Tue, 12 Nov 1996 15:37:38 -0800 (PST)
Cc: ietf at ietf.org
In-Reply-To: <01BBD093.38277320 at jfbb.atmnet.net> from "Jim Browning" at Nov 12, 96 12:15:39 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 3324
Source-Info: From (or Sender) name not authenticated.
Hi Jim,
> Jim Browning writes :
>
> >From: John Bevilacqua[SMTP:bevo at refuge.colorado.edu]
>
> Are you suggesting that domains at levels below those administered by the
> registries be included in the whois database? Otherwise, wouldn't this
> create an even greater desire for every entity to have a level two domain,
> so that it would be found with a whois search?
The RIPE database that is used by the European IP registry and many TLD
administrators in Europe and other parts of the world supports creation
of lower-level domain objects including a hierarchical authorization
model for creating the entries. So yes, this is already being done and
possible.
However, why do you need sub-level domain information registered for this ?!?
You are looking for information on a company/person when doing a query
for a company/person name whether you want to find out about his/her
Internet phone number, E-mail address or web URL. This can be done with
any whois service by adding URL data to each company/person entry (in
fact people are already finding out how usefull this is and are doing
this in the RIPE database although it's not designed and *intended* to be
used as a white/yellow pages service for the Internet). You don't need to
have sub-level domains registered with a registry for this approach.
The problem remains (and might be insolvable) that person/company name
indices are a flat name space and cannot very easily be distributed to
more different *and* competing companies, and still keep a transparent
and efficient system for the user, ISPs and webbrowser implementor.
A not-for-profit consortium might be a much better organization type for
such a service (note: this doesn't mean that Jim Fleming is not allowed
to start his own service, in contrary some competion will keep the
consortium awake) since every member can accept to handle a part of the
flat name space (example: all keys ab[a-z]*) and gets approval for adding
data to the directory services of other members (ISPs) that are managing
other parts of the index name space when becoming a member (ISP).
And yes, the importance of having your own nice looking DNS name will
decrease and the importance of being registered at the root or lower
down is not so much important anymore and thus running a TLD might not
be that much of a revenue source as some business people hope it will be.
Solutions that only involve new TLDs might very well increase the costs
for most of us since more popular TLDs will be able to ask *higher*
prices then they do now and you need to register in more then one popular
TLD to keep up with the competion... (My elektricien is now paying $100.-
a month to get registered in all local yellow pages phone services with
just a single line *and* his customers (me) are paying that).
However, it's our own fault if this happens because there is no reason
what so ever that we cannot design a good directory service that will
diminish the value of having a nice short recognizable/trademarked domain
name whether there are a few or thousands of TLDs. So let's use our
(valuable) time to get a good and cheap directory service running instead
of wasting our time on discussing the inevitable evolution towards more TLDs.
David K.
Disclaimer: this is my personal opinion at this point in time.
---
Received: from ietf.org by ietf.org id aa24744; 13 Nov 96 8:52 EST
Received: from taunivm.tau.ac.il by ietf.org id aa24068; 13 Nov 96 8:51 EST
Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 5282; Wed, 13 Nov 96 07:37:11 IST
Received: from VM.TAU.AC.IL (NJE origin HANK at TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2441; Wed, 13 Nov 1996 07:37:11 +0200
Date: Wed, 13 Nov 96 07:34:57 IST
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.tau.ac.il>
Subject: Re: iTLDs
To: Steve Hultquist <ssh at wwsi.com>, Keith Moore <moore at cs.utk.edu>
cc: Hank Nussbacher <HANK at taunivm.tau.ac.il>, ietf at ietf.org
In-Reply-To: Message of Tue, 12 Nov 1996 16:17:05 -0700 from <ssh at wwsi.com>
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611130852.aa24068 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
On Tue, 12 Nov 1996 16:17:05 -0700 you said:
>Hmmm... Shouldn't the response be to build that search engine and then
>suggest to either one of those companies or a third party search engine
>provider that they host it for the "good of the 'net"? I'm not sure I
>want the "browser wars" to turn into the "site lookup wars", with
>incompatibility and redundancy all over the place. We have more
>difficult problems to solve that need that kind of energy.
See:
http://netpart.com/free/search.html
as an example of what might be done (got this link from Jon).
It has a long way to go but it is a start in the right direction.
>I agree, however, that this capability will go a long way towards making
>the new TLDs actually usable. Without it, I see massive end-user
>frustration as the initial result from the new domains. And that's
>something we definitely *don't* need!
>
>ssh
>--
>Steve Hultquist Business, system, network, and Internet
>Worldwide Solutions, Inc. Engineering
>Boulder, Colorado, USA 303.581.0800 http://www.wwsi.com
Hank Nussbacher
Israel
Received: from ietf.org by ietf.org id aa24752; 13 Nov 96 8:52 EST
Received: from weeble.lut.ac.uk by ietf.org id aa24411; 13 Nov 96 8:52 EST
Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1)
id E0vNd4C-0006zV-00; Wed, 13 Nov 1996 11:01:12 +0000
Date: Wed, 13 Nov 1996 11:01:12 +0000 (GMT)
Sender:ietf-request at ietf.org
From: Jon Knight <jon at net.lut.ac.uk>
X-Sender: jon at weeble.lut.ac.uk
To: Keith Moore <moore at cs.utk.edu>
cc: Hank Nussbacher <HANK at taunivm.tau.ac.il>, ietf at ietf.org
Subject: Re: iTLDs
In-Reply-To: <199611122123.QAA15821 at ig.cs.utk.edu>
Message-ID: <Pine.SUN.3.95.961113105829.18764O-100000 at weeble.lut.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 12 Nov 1996, Keith Moore wrote:
> > What we need is for Netscape and Microsoft to build into their
> > 4.0 versions of their browsers a 'Site Lookup' button, that
> > takes a user to a Web form that allows lookup for company name
> > by substring or phonetic match and using the Internic/RIPE/APNIC
> > DN databases as the base for the information supplied.
>
> Yes, this is precisely what's needed.
Sounds a bit like WHOIS++ with its query routing/referals is called for
here. And crumbs, its a technology that's already got RFCs written about
it and software being deployed (and tested for interoperability). Sounds
just like what the doctor ordered*.
Tatty bye,
Jim'll
* Well this doctor anyway, but I'm a big WHOIS++ fan so that's not
surprising really.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU.
* I've found I now dream in Perl. More worryingly, I enjoy those dreams. *
Received: from ietf.org by ietf.org id aa24860; 13 Nov 96 8:53 EST
Received: from taunivm.tau.ac.il by ietf.org id aa24681; 13 Nov 96 8:52 EST
Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 5288; Wed, 13 Nov 96 07:40:06 IST
Received: from VM.TAU.AC.IL (NJE origin HANK at TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 2460; Wed, 13 Nov 1996 07:40:06 +0200
Date: Wed, 13 Nov 96 07:38:36 IST
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.tau.ac.il>
Subject: Re: iTLDs
To: Dave Crocker <dcrocker at brandenburg.com>, moore at cs.utk.edu
cc: Hank Nussbacher <HANK at taunivm.tau.ac.il>, ietf at ietf.org
In-Reply-To: Message of Tue, 12 Nov 1996 15:36:52 -0800 from
<dcrocker at brandenburg.com>
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611130853.aa24681 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
On Tue, 12 Nov 1996 15:36:52 -0800 you said:
>At 1:23 PM -0800 11/12/96, Keith Moore wrote:
>>> What we need is for Netscape and Microsoft to build into their
>>> 4.0 versions of their browsers a 'Site Lookup' button, that
>>
>>Yes, this is precisely what's needed.
>
> uhh, what data bases are to be consulted? How are they found?
>What standards are used to consult them?
Which databases: All whois/rwhois databases run by iTLD registries.
How are they found: All those registered in the root nameservers must
be running one.
Standard: BCP.
>
>d/
>
>--------------------
>Dave Crocker +1 408 246 8253
>Brandenburg Consulting fax: +1 408 249 6205
>675 Spruce Dr. dcrocker at brandenburg.com
>Sunnyvale CA 94086 USA http://www.brandenburg.com
>
>Internet Mail Consortium http://www.imc.org, info at imc.org
>
>
Hank Nussbacher
Israel
Received: from ietf.org by ietf.org id aa27684; 13 Nov 96 9:08 EST
Received: from mailer.dir.org by ietf.org id aa26776; 13 Nov 96 9:05 EST
Received: from nassau.dir.org (nassau.dir.org [194.205.62.19]) by mailer.dir.org (8.6.12/8.6.9) with SMTP id JAA01236; Wed, 13 Nov 1996 09:05:03 -0500
Message-ID: <3289FEC6.1907 at dir.org>
Date: Wed, 13 Nov 1996 09:00:54 -0800
Sender:ietf-request at ietf.org
From: John Harvey <john.harvey at dir.org>
Reply-To: john.harvey at dir.org
Organization: Directory Corporation
X-Mailer: Mozilla 3.0 (Win16; I)
MIME-Version: 1.0
To: Steve Hultquist <ssh at wwsi.com>
CC: paul at vix.com, moore at cs.utk.edu, ietf at ietf.org
Subject: Re: iTLDs - Directory.
References: <199611122317.QAA02827 at aspen.wwsi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Increasing TLD to address ***.COM or ***.CAR or ***.PTY, if left
unchecked would invite multiple registrations in each TLD.
As new TLDs are introduced there will emerge the associated
phychological kudos of being represented in all domains, increasing the
TLD hop and search mentality, whilst confounding and frustrating the TLD
functionality even more.
To use the well quoted verse Paul A Vixie wrote, Sun Nov 10:
> What I need and what the other 98% of Internet users who have not yet
> signed on need, is a way to say "does lucia's pizza in woodside have a
> URL?" and get something useful -- an authoritative "no" or a short/accurate
> list of possible "yes"'s.
>
I agree 100%. This would also make multiple TLD registrations pointless.
In monopolistic times, Telcos operated directory assistance services to
stimulate call revenue. In the competitive Internet environment, users
want a centralized directory service, but do their Access Providers?
The bottom line is, how do Access Providers profit from, and "virtual
site customers" be included in, a universal directory service?
What have Access Providers got to do with top tier functionality.
Inviting Access Providers to "service" their customer base, would
significantly reduce the intense market demand for multiple TLD name
space - overnight.
Steve Hultquist wrote Tue Nov 12:
>
> >>>>> "Keith" == Keith Moore <moore at cs.utk.edu> writes:
>
> >> What we need is for Netscape and Microsoft to build into their 4.0
> >> versions of their browsers a 'Site Lookup' button, that takes a user
> >> to a Web form that allows lookup for company name by substring or
> >> phonetic match and using the Internic/RIPE/APNIC DN databases as the
> >> base for the information supplied.
>
> Keith> Yes, this is precisely what's needed.
>
> Hmmm... Shouldn't the response be to build that search engine and then
> suggest to either one of those companies or a third party search engine
> provider that they host it for the "good of the 'net"? I'm not sure I
> want the "browser wars" to turn into the "site lookup wars", with
> incompatibility and redundancy all over the place. We have more
> difficult problems to solve that need that kind of energy.
>
> I agree, however, that this capability will go a long way towards making
> the new TLDs actually usable. Without it, I see massive end-user
> frustration as the initial result from the new domains. And that's
> something we definitely *don't* need!
>
Absolutely.
John.
--
__________________________________________________________________
John Harvey - Director of On-line Information Services.
mailto:john.harvey at dir.org Fax + 1 242 326 4105 http://www.dir.org
Directory Corporation, Universal House, Nassau, PO N-3401, Bahamas
__________________________________________________________________
Received: from ietf.org by ietf.org id aa29435; 13 Nov 96 9:14 EST
Received: from cnri by ietf.org id al29057; 13 Nov 96 9:13 EST
Received: from ng.netgate.net by CNRI.Reston.VA.US id aa03307;
13 Nov 96 2:16 EST
Received: from [205.214.160.148] (d107.netgate.net [205.214.160.145]) by ng.netgate.net (8.8.2/8.6.9) with ESMTP id XAA03483 for <IETF at cnri.reston.va.us>; Tue, 12 Nov 1996 23:26:12 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100700aeaf1c79bf23 at [205.214.160.148]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 12 Nov 1996 22:35:21 -0800
To: IETF at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Donald Heath <heath at linus.isoc.org>
Subject: Press Release
Source-Info: From (or Sender) name not authenticated.
NEW INTERNATIONAL COMMITTEE NAMED
TO RESOLVE DOMAIN NAME SYSTEM ISSUES
WASHINGTON, DC, November 12, 1996 -- An Internet International
Ad Hoc Committee (IAHC) has been named to resolve issues resulting
from current international debate over a proposal to establish additional
global registries and international Top Level Domains (iTLDs).
"We are pleased to have attracted such a high level of leading
international experts in their fields to examine these questions that are
critical to the current and future growth of the Internet," Donald M. Heath,
president and CEO of the Internet Society said in announcing the
eleven-member committee. Heath will serve as chairman.
Deliberations of the committee may lead to the establishment
of new international Top Level Domains (iTLDs), adding to the current
three-letter tags, such as .com, .net, and .org, that end many Internet email
and World Wide Web addresses.
Dr. Donald N. Telage, president of the Herndon, Virginia - based
Network Solutions, Inc., which manages the InterNIC Registry administering
the .com, .net, .edu, and .org top level domains, said: "Network Solutions has
supported the registration process and the growth of the Internet since 1991.
We have seen its evolution from a research and education tool to a powerful
medium for global communication and collaboration. The National Science
Foundation has played a critical role in the early governance activities, and
we support the Internet Society's efforts to review issues critical to the
future of Internet growth, evolution and governance. Network Solutions will
participate and support this effort enthusiastically supplying our extensive
operational knowledge as needed."
Named to the new IAHC are:
.Sally M. Abel, specializes in international trademark and trade
name counseling, chairs the Internet Subcommittee of the International
Trademark Association (INTA), and will represent that organization on
the IAHC. Ms. Abel is the partner in charge of the Trademark Group of
the law firm of Fenwick and West, a Palo Alto, Ca. firm specializing in
high technology matters.
.Dave Crocker, is co-founder of the Internet Mail Consortium, an
industry trade association. He is also a principal with Brandenburg
Consulting in Sunnyvale, Ca., a firm specializing in guiding the development
and use of Internet applications. With ten years in the ARPA research
community, ten years developing commercial network products and services,
and extensive contributions to the Internet Engineering Task Force, he is
considered an expert about the Internet, email, electronic commerce, Internet
operation and the Internet standards process.
.Geoff Huston is the technical manager of Australia's Telstra
Internet
and is responsible for the architecture and operations of its service. He
formerly
was technical manager of the Australian Academic and Research Network,
and was largely responsible for the introduction and subsequent development
of the Internet into Australia.
.David W. Maher, a partner at the law firm of Sonnenschein Nath &
Rosenthal, of Chicago, IL, is a registered patent attorney and has extensive
experience in intellectual property and entertainment law. Principal outside
trademark counsel for several nationwide companies, he has served as special
counsel to the American Bar Association for telecommunications matters.
.Perry E. Metzger is the president of New York - based Piermont
Information Systems Inc., a consulting firm specializing in communications
and computer systems security. He has worked with the New York financial
community for many years and is active in the Internet Engineering Task
Force's (IETF) security area, chairing the group's Simple Public Key
Infrastructure working group.
.Jun Murai is an associate professor on the Faculty of
Environmental
Information at Keio University in Tokyo. He developed JUNET, Japan's first
UUCP network and the WIDE Internet, Japan's first IP network. He is president
of the Japan Network Information Center (JPNIC) and serves as adjunct professor
at the Institute of Advanced Studies of the United Nations University in
Tokyo.
.Hank Nussbacher, an independent networking consultant, currently
works with IBM Israel as Internet Technology Manager and has been responsible
for all aspects in establishing IBM Israel as a major ISP in Israel. He also
consults for the Israeli inter-university consortium and is on the board of
directors
of the Internet Society of Israel.
.Robert Shaw is an advisor on Global Information
Infrastructure (GII)
issues at the International Telecommunication Union (ITU). The ITU, based in
Geneva, Switzerland, is a United Nations treaty organization within which
governments and the private sector coordinate global telecom networks and
services.
.George Strawn is with the US National Science Foundation (NSF),
which has funded Internet development for research and education. Mr. Strawn
has been involved with the NSF's Internet activities for the last five
years and
also co-chairs the Federal Networking Council, a US government committee
coordinating inter-agency Internet activities, including funding for
administrative
activities, such as the Internet Assigned Numbers Authority (IANA).
.Albert Tramposch is senior legal counsellor at the World
Intellectual
Property Organization (WIPO) in Geneva. WIPO is a United Nations organization
which has responsibility for the promotion of the protection of
intellectual property
throughout the world. It also administers various treaties dealing with
legal and
administrative aspects of intellectual property, including the international
registration of trademarks.
In addition, Stuart Levi, a partner in the New York Office of
Skadden,
Arps, Slate, Meagher & Flom, and the head of the firm's Computer and
Information
Technology Practice, will serve as outside counsel supporting the IAHC.
"The IAHC will be charged with fairly and openly looking at
the complex
issues surrounding the current domain name and registry situation, including
trademark and infringement, economics and administration of registry
operations,
dispute resolution policies, fees and iTLDs," Heath said. He anticipates
the Committee reaching reasonable consensus on issues identified, sometime
in
January. A subset of the IAHC will seek to implement its recommendations
very shortly after that.
To meet its aggressive schedule, the widely dispersed group will
primarily operate online, over the Internet. Interested parties throughout the
Internet world will be able to participate in the IAHC's process, through an
electronic mail list service and a Web site that are being established.
Discussions, evaluations and decisions will be available for public inspection.
An archive, and relevant documents, will be available for public comment at the
Web site which will be established by November 15 at http://www.iahc.org.
To subscribe to the IAHC's email list service, send email with the word
"subscribe" to: iahc-discuss-request at iahc.org.
# # # # # # #
Received: from ietf.org by ietf.org id aa03548; 13 Nov 96 10:08 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa03169; 13 Nov 96 10:06 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id KAA11021; Wed, 13 Nov 1996 10:00:09 -0500 (EST)
Message-Id: <199611131500.KAA11021 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Jon Knight <jon at net.lut.ac.uk>
cc: Keith Moore <moore at cs.utk.edu>, Hank Nussbacher <HANK at taunivm.tau.ac.il>,
ietf at ietf.org
Subject: Re: iTLDs
In-reply-to: Your message of "Wed, 13 Nov 1996 11:01:12 GMT."
<Pine.SUN.3.95.961113105829.18764O-100000 at weeble.lut.ac.uk>
Date: Wed, 13 Nov 1996 10:00:08 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> > > What we need is for Netscape and Microsoft to build into their
> > > 4.0 versions of their browsers a 'Site Lookup' button, that
> > > takes a user to a Web form that allows lookup for company name
> > > by substring or phonetic match and using the Internic/RIPE/APNIC
> > > DN databases as the base for the information supplied.
> >
> > Yes, this is precisely what's needed.
>
> Sounds a bit like WHOIS++ with its query routing/referals is called for
> here.
That would work, but it would probably be overkill.
The nice thing about this approach is that very simple protocols
(not to mention protocols that are already deployed) will do.
Keith
Received: from ietf.org by ietf.org id aa06253; 13 Nov 96 10:42 EST
Received: from cnri by ietf.org id aa05960; 13 Nov 96 10:39 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa13209;
13 Nov 96 10:39 EST
Received: by ginger.lcs.mit.edu
id AA22021; Wed, 13 Nov 96 10:38:26 -0500
Date: Wed, 13 Nov 96 10:38:26 -0500
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9611131538.AA22021 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: iTLDs
Cc: jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
Umm, guys'n'gals, this discussion, while initially one with policy
implications of broad interest, seems to have moved into an area (distributed
lookups) that don't really seem like an issue for the main IEFT list. Maybe
you could take it elsewhere? Thanks...
Noel
Received: from ietf.org by ietf.org id aa07097; 13 Nov 96 11:00 EST
Received: from ietf.org by ietf.org id aa06271; 13 Nov 96 10:41 EST
To: IETF-Announce: ;
Subject: IETF PGP Key Signing Party
Sender:ietf-announce-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Wed, 13 Nov 1996 10:41:56 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9611131041.aa06271 at ietf.org>
Once again, we will be holding a PGP Key signing party at the IETF
meeting in San Jose. We have been scheduled to meet at 10:30pm on the
evening of Wednesday, December 11, 1996, in the Garden room. The
procedure we will use is the following:
o People who wish to participate should email an ASCII extract of their
PGP public key to <tytso at mit.edu> by NOON on Wednesday of the week
of the IETF meeting. Please include a subject line of "IETF PGP
KEY". (Note, this is earlier than I was accepting keys than before.
Please get them in on-time!!)
Sending your key to me before the IETF meeting is appreciated, since
it reduces the number of keys that I have to collect during the
meeting. (In fact, why don't you send me your key right now if you
know will be attending, so you won't forget?)
o By 10pm on Wednesday, you will be able to ftp a complete key ring
from tsx-11.mit.edu with all of the keys that were submitted; it will
be in the file /pub/tytso/ietf.asc and /pub/tytso/ietf.pgp.
o At 10:30pm, come prepared with the PGP Key fingerprint of your PGP
public key; we will have handouts with all of the key fingerprints of
the keys that people have mailed in.
o In turn, readers at the front of the room will recite people's keys;
as your key fingerprint is read, stand up, and at the end of reading
of your PGP key fingerprint, acknowledge that the fingerprint as read
was correct.
o Later that evening, or perhaps when you get home, you can sign the
keys corresponding to the fingerprints which you were able to verify
on the handout; note that it is advisable that you only sign keys of
people when you have personal knowledge that the person who stood up
during the reading of his/her fingerprint really is the person which
he/she claimed to be.
o Submit the keys you have signed to the PGP keyservers. A good one to
use is the one at MIT: simply send mail containing the ascii armored
version of your PGP public key to <pgp at pgp.mit.edu>.
Note that you don't have a laptop with you; if you don't have any
locally trusted computing resources during the key signing party, you
can make notes on the handout, and then take the handout home and sign
the keys later.
- Ted
Received: from ietf.org by ietf.org id aa08959; 13 Nov 96 11:18 EST
Received: from cnri by ietf.org id aa08607; 13 Nov 96 11:16 EST
Received: from m-ws.vol.cz by CNRI.Reston.VA.US id aa14371; 13 Nov 96 11:16 EST
Received: from nvasa (tabor2.vol.cz [194.166.38.195]) by m-ws.vol.cz (8.7.5/8.6.9) with SMTP id RAA16390 for <ietf at cnri.reston.va.us>; Wed, 13 Nov 1996 17:15:05 +0100
Message-Id: <199611131615.RAA16390 at m-ws.vol.cz>
Comments: Authenticated sender is <nvasa at popserver.vol.cz>
Sender:ietf-request at ietf.org
From: "Nabytek VASA s. r. o." <nvasa at m-ws.vol.cz>
Organization: Nabytek VASA s. r. o.
To: ietf at CNRI.Reston.VA.US
Date: Wed, 13 Nov 1996 17:14:54 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject:
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42a)
Source-Info: From (or Sender) name not authenticated.
help
Received: from ietf.org by ietf.org id aa13090; 13 Nov 96 12:01 EST
Received: from zephyr.isi.edu by ietf.org id aa12452; 13 Nov 96 11:59 EST
Received: from zen.isi.edu (zen-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA08866>; Wed, 13 Nov 1996 08:58:12 -0800
Date: Wed, 13 Nov 1996 08:58:04 -0800
Sender:ietf-request at ietf.org
From: postel at isi.edu
Posted-Date: Wed, 13 Nov 1996 08:58:04 -0800
Message-Id: <199611131658.AA12025 at zen.isi.edu>
Received: by zen.isi.edu (5.65c/4.0.3-6)
id <AA12025>; Wed, 13 Nov 1996 08:58:04 -0800
To: dcrocker at brandenburg.com, moore at cs.utk.edu, HANK at taunivm.tau.ac.il
Subject: Re: iTLDs
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Hi.
Who cares what databases are consulted by what methods.
Let the market decide.
What i want (an maybe what a lot of users want) is a way to enter a
company name and get back a link to its home page.
The seract tool at
http://netpart.com/free/search.html
does this, to some extent. It needs to be better. Let's encourage
others to develop similar tools. Let's have some competition. Let the
tool that best makes the users happy win.
--jon.
Received: from ietf.org by ietf.org id aa17330; 13 Nov 96 13:04 EST
Received: from cnri by ietf.org id aa17201; 13 Nov 96 13:01 EST
Received: from hail.ncr.disa.mil by CNRI.Reston.VA.US id aa17073;
13 Nov 96 13:01 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id MAA10809; Wed, 13 Nov 1996 12:49:28 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA847918151; Wed, 13 Nov 96 12:19:08 EST
Date: Wed, 13 Nov 96 12:19:08 EST
Sender:ietf-request at ietf.org
From: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>
Message-Id: <9610138479.AA847918151 at ncr.disa.mil>
To: IETF at CNRI.Reston.VA.US, poised at tis.com, newdom at vrx.net
Subject: "Thank You" Jim Fleming !
Source-Info: From (or Sender) name not authenticated.
Mr FLEMING -
As a 'lurker' for the most part, I want you to know that your many
messages concerning DNS, etc to various lists in recent days have had
one positive effect on me.
I have come away with increased respect for, and confidence in, the
many senior members and leaders of the I* community for the
extraordinary patience and thoroughness with which they have responded
to your many unfounded personal attacks and generally destructive
comments.
For my part, I wish that you would 'leave' these lists and come back
after you have time to reflect on the courtesy they have extended to
you, and which I hope you would reciprocate.
For your consideration,
C.Joe Pasquariello
US/DoD/DISA
Received: from ietf.org by ietf.org id aa21440; 13 Nov 96 14:00 EST
Received: from gw.home.vix.com by ietf.org id aa21065; 13 Nov 96 13:58 EST
Received: by gw.home.vix.com id KAA13818; Wed, 13 Nov 1996 10:57:29 -0800 (PST)
X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us
Received: from localhost (localhost [127.0.0.1]) by wisdom.home.vix.com (8.8.2/8.8.2) with SMTP id KAA13087 for <ietf at ietf.org>; Wed, 13 Nov 1996 10:57:27 -0800 (PST)
Message-Id: <199611131857.KAA13087 at wisdom.home.vix.com>
X-Authentication-Warning: wisdom.home.vix.com: localhost [127.0.0.1] didn't use HELO protocol
To: ietf at ietf.org
Subject: Re: iTLDs - Directory.
In-reply-to: Your message of "Wed, 13 Nov 1996 09:00:54 PST."
<3289FEC6.1907 at dir.org>
Date: Wed, 13 Nov 1996 10:57:27 -0800
Sender:ietf-request at ietf.org
From: Paul A Vixie <paul at vix.com>
Source-Info: From (or Sender) name not authenticated.
> Increasing TLD to address ***.COM or ***.CAR or ***.PTY, if left
> unchecked would invite multiple registrations in each TLD.
> As new TLDs are introduced there will emerge the associated
> phychological kudos of being represented in all domains, increasing the
> TLD hop and search mentality, whilst confounding and frustrating the TLD
> functionality even more.
Agreed. This is why I so strongly support the creation of new iTLD's: it
will make all attempts to trademark lion-king.<itld> as obviously silly as
trademarking lion-king.cs.berkeley.edu is now. Let a thousand points of
confusion bloom, let the namespace be driven the rest of the way to hell
(in a handbasket I shall help weave) and then let folks discover that the
Internet has no directory service and then let us go about solving that.
Some folks want COM to have competition because they want some of the money.
I want COM to have competition so that the idea of using DNS as a directory
service will be more obviously absurd to more and more and more people.
Received: from ietf.org by ietf.org id aa23854; 13 Nov 96 14:39 EST
Received: from Kitten.mcs.com by ietf.org id aa23728; 13 Nov 96 14:37 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id NAA27818; Wed, 13 Nov 1996 13:36:41 -0600 (CST)
Received: from Jupiter.Mcs.Net (karl at Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA07225; Wed, 13 Nov 1996 13:36:38 -0600 (CST)
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id NAA18226; Wed, 13 Nov 1996 13:36:37 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611131936.NAA18226 at Jupiter.Mcs.Net>
Subject: Re: iTLDs - Directory.
To: Paul A Vixie <paul at vix.com>
Date: Wed, 13 Nov 1996 13:36:36 -0600 (CST)
Cc: ietf at ietf.org
In-Reply-To: <199611131857.KAA13087 at wisdom.home.vix.com> from "Paul A Vixie" at Nov 13, 96 10:57:27 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
>
> > Increasing TLD to address ***.COM or ***.CAR or ***.PTY, if left
> > unchecked would invite multiple registrations in each TLD.
> > As new TLDs are introduced there will emerge the associated
> > phychological kudos of being represented in all domains, increasing the
> > TLD hop and search mentality, whilst confounding and frustrating the TLD
> > functionality even more.
>
> Agreed. This is why I so strongly support the creation of new iTLD's: it
> will make all attempts to trademark lion-king.<itld> as obviously silly as
> trademarking lion-king.cs.berkeley.edu is now. Let a thousand points of
> confusion bloom, let the namespace be driven the rest of the way to hell
> (in a handbasket I shall help weave) and then let folks discover that the
> Internet has no directory service and then let us go about solving that.
>
> Some folks want COM to have competition because they want some of the money.
> I want COM to have competition so that the idea of using DNS as a directory
> service will be more obviously absurd to more and more and more people.
Actually, I want COM to have competition because I believe it will do ALL
of the following:
1) Destroy an improper monopoly.
2) Improve service to customers of the TLD registries.
3) Drop prices by anywhere from 50 to 90%.
4) FORCE the implementation of a REAL directory service as a
"front-end" to the DNS.
That is, I want the Yellow Pages (more or less) to show up.
DNS names have value. But that value is SYNTHETIC (ie: you have it now and
500,000 people know what it is, that's valuable -- just like your ADDRESS is
in the real world).
Right now the synthesis of things is such that we have (1) high prices, (2)
poor service, (3) dictatorial implementations, (4) DNS as a battlefield
for corporations who only have one possible place to reasonably register,
and (5) no incentive for a WG to form that will address point (4) above.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa24300; 13 Nov 96 14:47 EST
Received: from nirvana.genesyslab.com by ietf.org id aa24185;
13 Nov 96 14:46 EST
Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id LAA29938; Wed, 13 Nov 1996 11:45:33 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id LAA16732; Wed, 13 Nov 1996 11:44:57 -0800 (PST)
Date: Wed, 13 Nov 1996 11:44:57 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199611131944.LAA16732 at giant.genesyslab.com>
To: dcrocker at brandenburg.com, moore at cs.utk.edu
Subject: Re: iTLDs
Cc: HANK at taunivm.tau.ac.il, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: Keith Moore <moore at cs.utk.edu>
>
>The solution is to encourage the development/deployment of extensive
>data bases of company names that happen to have a presence on
>the Internet.
>Nah. We don't have to solve the general distributed directory problem.
>And for a single-purpose database, like one that matches company names
>and returns pointers to their web pages, the solution can be quite simple.
>
We find some-company in the following cases:
1) We already have a business with it. We try find letters/e-mails/or some
documentation to obtain street address or Internet name. Without any
doubts directory service can help us in this case.
2) We haven't business with it but we know company profile or another additional
information. Also dircetory service can help us.
3) We read ads about some product and try to find company to obtain more information.
In many cases we don't remember any coordinates about company exclude some bright
"names" in this ads. What we would find ? This name. It is the company deal to
support me (as customer) this distinctive name and search system for it.
Just now it is company.com in DNS.
Can central directory service help us in this ? No - we know about problem with
duplicated company names in different regions. We need to setup some search system
in some division (regional or trade sectors) which can find company on single
word (may be composed). And it can be connected to DNS wthout doubts - if this
will not be done then using of .COM for this purpose would continue - DNS has
attribute to simple and universal search. Unfortunately DNS has also problem
with duplicated company/trademarks/etc names.
And In my mind a focusing on WWW only is error - there is also non-interactive
E-mail, FTP, etc.
Just now I think about trademark due to very correlation in point (3) and trademark
behaviour - it has the same trade sector and can die with loss of interest to it.
But if somebody can suggest any another naming it would be also beautifull.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa27372; 13 Nov 96 15:33 EST
Received: from cnri by ietf.org id aa27225; 13 Nov 96 15:31 EST
Received: from fractal.chaos.com by CNRI.Reston.VA.US id aa21664;
13 Nov 96 15:31 EST
Received: from fractal.chaos.com by fractal.chaos.com (NTMail 3.02.11) with ESMTP id na003575 for <IETF at cnri.reston.va.us>; Wed, 13 Nov 1996 15:29:45 -0500
Message-Id: <3.0.32.19961113152945.00a92550 at fractal.chaos.com>
X-Sender: amr at fractal.chaos.com
X-Mailer: Windows Eudora Pro Version 3.0 Demo (32)
Date: Wed, 13 Nov 1996 15:29:45 -0500
To: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>
Sender:ietf-request at ietf.org
From: Tony Rutkowski <amr at chaos.com>
Subject: Re: "Thank You" Jim Fleming !
Cc: IETF at CNRI.Reston.VA.US, poised at tis.com, newdom at vrx.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Joe,
> I have come away with increased respect for, and confidence in, the
> many senior members and leaders of the I* community for the
> extraordinary patience and thoroughness with which they have responded
> to your many unfounded personal attacks and generally destructive
> comments.
>
> For my part, I wish that you would 'leave' these lists and come back
> after you have time to reflect on the courtesy they have extended to
> you, and which I hope you would reciprocate.
Giorno..
As another senior member of the world community, I'd like
to suggest that Jim is actually undertaking the valuable task
of asking questions about existing institutions and roles
from an alternative perspective. OK - he's been incredibly
"productive" and sometimes bothersome, but nothing that warrants
the characterization of "personal attacks and...destructive
comments." He's been questioning direction, roles and
authority, not personal integrity or competence. That's
the sort of reaction we used to hear in the CCITT about
the Internet community not too long ago.
It's not going to serve the IETF well to force out people
because they ask questions you don't like. I certainly wouldn't
expect this in an organization that takes pride in accommodating
diverse views and adapting to change. If nothing else, life
on these lists (such as it is) would be much duller without Jim.
ciao,
--tony
Received: from ietf.org by ietf.org id aa00004; 13 Nov 96 16:37 EST
Received: from cnri by ietf.org id aa29831; 13 Nov 96 16:33 EST
Received: from hail.ncr.disa.mil by CNRI.Reston.VA.US id aa23330;
13 Nov 96 16:33 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id QAA13637; Wed, 13 Nov 1996 16:21:03 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA847931491; Wed, 13 Nov 96 16:29:09 EST
Date: Wed, 13 Nov 96 16:29:09 EST
Sender:ietf-request at ietf.org
From: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>
Message-Id: <9610138479.AA847931491 at ncr.disa.mil>
To: Tony Rutkowski <amr at chaos.com>
Cc: IETF at CNRI.Reston.VA.US, poised at tis.com, newdom at vrx.net
Subject: Re[2]: "Thank You" Jim Fleming !
Source-Info: From (or Sender) name not authenticated.
OH REALLY TONY !
I'm surprised that you don't find the following Fleming comment of
today [like others over recent days] anything BUT unfounded, personal
and destructive!
" 3. The appointed leaders in the IETF (and other I* leaders) have not
necessarily signed up to be anything more than figureheads.
As they are "pushed" from below, by the membership, they
have a difficult time devoting their life to some cause when the
reality of the world is that they mostly work for some
company and mainly protect that company's interests,
instead of the Internet's interest, or the people's interest."
- Jim Fleming; 13 Nov 96
See also Eastlake's comments of today on this point.
I fail to see your point on the old CCITT/Internet animosity. Happily
there is currently a growing degree of respect and cooperation today
between the Internet community and the ITU-T. This has come about
through mutual respect and civility on both sides - NOT through the
sort of dialog being fostered by Mr Fleming. "Valuable" indeed !
C.Joe P-->
US/DoD/DISA
______________________________ Reply Separator _________________________________
Subject: Re: "Thank You" Jim Fleming !
Author: Tony Rutkowski <amr at chaos.com> at smtp
Date: 11/13/96 3:54 PM
Joe,
> I have come away with increased respect for, and confidence in, the >
many senior members and leaders of the I* community for the
> extraordinary patience and thoroughness with which they have responded >
to your many unfounded personal attacks and generally destructive
> comments.
>
> For my part, I wish that you would 'leave' these lists and come back
> after you have time to reflect on the courtesy they have extended to
> you, and which I hope you would reciprocate.
Giorno..
As another senior member of the world community, I'd like
to suggest that Jim is actually undertaking the valuable task
of asking questions about existing institutions and roles
from an alternative perspective. OK - he's been incredibly
"productive" and sometimes bothersome, but nothing that warrants
the characterization of "personal attacks and...destructive
comments." He's been questioning direction, roles and
authority, not personal integrity or competence. That's
the sort of reaction we used to hear in the CCITT about
the Internet community not too long ago.
It's not going to serve the IETF well to force out people
because they ask questions you don't like. I certainly wouldn't
expect this in an organization that takes pride in accommodating
diverse views and adapting to change. If nothing else, life
on these lists (such as it is) would be much duller without Jim.
ciao,
--tony
Received: from ietf.org by ietf.org id aa02474; 13 Nov 96 17:32 EST
Received: from zephyr.isi.edu by ietf.org id aa02301; 13 Nov 96 17:30 EST
Received: from brind.isi.edu (old-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA01887>; Wed, 13 Nov 1996 14:29:20 -0800
Sender:ietf-request at ietf.org
From: davidk at isi.edu
Posted-Date: Wed, 13 Nov 1996 14:29:19 -0800 (PST)
Message-Id: <9611132229.AA02518 at brind.isi.edu>
Received: by brind.isi.edu (4.1/4.0.3-6)
id <AA02518>; Wed, 13 Nov 96 14:29:19 PST
Subject: Re: iTLDs - Directory.
To: Karl Denninger <karl at mcs.net>
Date: Wed, 13 Nov 1996 14:29:19 -0800 (PST)
Cc: paul at vix.com, ietf at ietf.org
In-Reply-To: <199611131936.NAA18226 at Jupiter.Mcs.Net> from "Karl Denninger" at Nov 13, 96 01:36:36 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1889
Source-Info: From (or Sender) name not authenticated.
Hi Karl,
> Karl Denninger writes :
>
> Actually, I want COM to have competition because I believe it will do ALL
> of the following:
>
> 1) Destroy an improper monopoly.
Agreed.
> 2) Improve service to customers of the TLD registries.
Agreed, but note that it doesn't necessarely means better service for the
*users* of the Internet.
> 3) Drop prices by anywhere from 50 to 90%.
This remains to be seen.
There is good chance that the administrator of the .COM domain can ask
higher prices (at least in the short term) just because people are
willing to pay that for such a popular domain. Until recently many
foreign companies could easily register in their mothercountry TLD for
free but they still decided to pay for a .COM address because it is
better known and that $50.- is not that much ... And even if competition
drives down the prices, you will probably need to register in more then
one domain or pay for directory services possibly owned by Micro$oft or
Netscape. And guess where you will have to buy your web browsers ... you
will not get them for free anymore ...
> 4) FORCE the implementation of a REAL directory service as a
> "front-end" to the DNS.
This will certainly happen, but who is doing it ?!? Is it a cheap service ?!?
Do you need to subscribe to 20 different services ?!? There are
enough examples in recent computer history that not always the
best/cheapest system wins in the free market.
However, having more TLDs is inevitable, whether we like it or not.
Nobody can stop other people creating other domains and government
intervention (domain taxes or regulations) become much more unlikely
with a non-monopolistic system.
Let's focuss on getting a cheap, open & easy directory service to assure
that the pricedrop in service fees and user convenience really happens.
And let's discuss this on another more appropriate list ;-),
David K.
---
Received: from ietf.org by ietf.org id aa03960; 13 Nov 96 18:00 EST
Received: from ietf.org by ietf.org id aa03690; 13 Nov 96 17:58 EST
To: ietf at ietf.org
Subject: Re: iTLDs
Sender:ietf-request at ietf.org
From: marshall eubanks <tme at casa.usno.navy.mil>
Date: Wed, 13 Nov 1996 17:58:40 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9611131758.aa03690 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
RE:
>>> What we need is for Netscape and Microsoft to build into their
>>> 4.0 versions of their browsers a 'Site Lookup' button, that
>>
>>Yes, this is precisely what's needed.
> uhh, what data bases are to be consulted? How are they found?
> What standards are used to consult them?
I proposed on the new domain mailing list (in one of
its varients) that each new i-TLD be required to maintain
a web site (and/or a database) of the second
level domains below it, containing, with the domain name, the
name of the underlying company, the type of business offered, a
URL for further information, etc. This would
1.) Relieve the need for one centralized database &
2.) Make the new iTLDs much easier to navigate than .com, and
thus more attractive.
I still think this sounds like a good idea - Since no i-TLDs
exist officially as yet,, it would not seem too onerous to
require them to keep up with this from the start.
Regards
Marshall Eubanks
tme at casa.usno.navy.mil
Received: from ietf.org by ietf.org id aa08442; 13 Nov 96 18:51 EST
Received: from Kitten.mcs.com by ietf.org id aa08275; 13 Nov 96 18:48 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id RAA09732; Wed, 13 Nov 1996 17:46:54 -0600 (CST)
Received: from Jupiter.Mcs.Net (karl at Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id RAA28339; Wed, 13 Nov 1996 17:46:51 -0600 (CST)
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id RAA25946; Wed, 13 Nov 1996 17:46:50 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611132346.RAA25946 at Jupiter.Mcs.Net>
Subject: Re: iTLDs - Directory.
To: davidk at isi.edu
Date: Wed, 13 Nov 1996 17:46:50 -0600 (CST)
Cc: karl at mcs.net, paul at vix.com, ietf at ietf.org
In-Reply-To: <9611132229.AA02518 at brind.isi.edu> from "davidk at ISI.EDU" at Nov 13, 96 02:29:19 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> Hi Karl,
>
> > Karl Denninger writes :
> >
> > Actually, I want COM to have competition because I believe it will do ALL
> > of the following:
> >
> > 1) Destroy an improper monopoly.
>
> Agreed.
>
> > 2) Improve service to customers of the TLD registries.
>
> Agreed, but note that it doesn't necessarely means better service for the
> *users* of the Internet.
>
> > 3) Drop prices by anywhere from 50 to 90%.
>
> This remains to be seen.
>
> There is good chance that the administrator of the .COM domain can ask
> higher prices (at least in the short term) just because people are
> willing to pay that for such a popular domain.
Sure.
But it also means that if there are 20 companies out there (or 200)
registering for $10.00/year, and NSI stays at $50.00, it won't be long
before critical mass is achieved at those other entities and NSI is kaput.
Especially if they counted on that revenue stream and did something silly
like, oh, say, sold stock to the public :-)
That's the problem with a competitive market. You just can't count on
people staying out. However, for this to happen we *MUST* open the doors to
basically all comers on terms that are sufficiently easy to satisfy that we
end up with *lots* (hundreds) of registries.
If we only get dozens, it won't happen. The dozens will all be big
companies, and they have every interest in seeing that charge stay high.
Ever wonder why cellular use is so outrageous?
> > 4) FORCE the implementation of a REAL directory service as a
> > "front-end" to the DNS.
>
> This will certainly happen, but who is doing it ?!? Is it a cheap service ?!?
> Do you need to subscribe to 20 different services ?!? There are
> enough examples in recent computer history that not always the
> best/cheapest system wins in the free market.
So what?
Again, open markets and open competition have a way of fixing this problem.
> Let's focuss on getting a cheap, open & easy directory service to assure
> that the pricedrop in service fees and user convenience really happens.
> And let's discuss this on another more appropriate list ;-),
>
> David K.
> ---
Sounds reasonable.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa20982; 13 Nov 96 23:50 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa20822; 13 Nov 96 23:47 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id XAA17688; Wed, 13 Nov 1996 23:46:06 -0500
Message-Id: <199611140446.XAA17688 at black-ice.cc.vt.edu>
To: marshall eubanks <tme at casa.usno.navy.mil>
cc: ietf at ietf.org
Subject: Re: iTLDs
In-reply-to: Your message of "Wed, 13 Nov 1996 17:58:40 EST."
<9611131758.aa03690 at ietf.org>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="<Valdis.Kletnieks at vt.edu>"
X-URL: http://black-ice.cc.vt.edu/~valdis/
References: <9611131758.aa03690 at ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <36112.847946765.1 at black-ice.cc.vt.edu>
Date: Wed, 13 Nov 1996 23:46:06 -0500
Source-Info: From (or Sender) name not authenticated.
On Wed, 13 Nov 1996 17:58:40 EST, you said:
> I proposed on the new domain mailing list (in one of
> its varients) that each new i-TLD be required to maintain
> a web site (and/or a database) of the second
> level domains below it, containing, with the domain name, the
> name of the underlying company, the type of business offered, a
> URL for further information, etc. This would
An interesting idea. It would however probably prove useful
to ponder some of these data items, and ask if we *really* need them,
or if they should be optional. Obviously, the domain name and
the owner thereof should be public information, just as it is in the
current WHOIS database.
However, note that a "URL for further information" may or may not
exist (the company may be a startup and not be up to speed yet,
or may for policy reasons wish to be an e-mail only participant
behind a firewall). Also, "type of business offered" may be
problematic for inclusion in a database, unless we specifically
remember to be *very* flexible. What business is Phillip Morris
in (or any other conglomerate)? What about the company in
Florida that was recently in the news, who as *one* of their
specialty cleaning services, remove the evidence from crime scenes?
Note - they come in and clean bloodstains and the like *after*
the police are satisfied, not clean up for organized crime figures
before the police arrive ;) I suspect that there's a *really* fat
Ph.D. thesis in it for anybody who figures out how to make this
anywhere near natural-language searchable, for more than just English.
Actually, I take that back. If *I* knew how to do it, I'd say
"<explitive> the sheepskin", hack code, make a killing on the IPO,
and then relax. ;)
I admit to senility - is there an active list for discussing these
sorts of directory issues, or should I look at creating one so
we can move this whole thread there?
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.org by ietf.org id aa20981; 13 Nov 96 23:50 EST
Received: from cnri by ietf.org id aa20722; 13 Nov 96 23:45 EST
Received: from access.netaxs.com by CNRI.Reston.VA.US id aa00925;
13 Nov 96 23:45 EST
Received: from unix1.netaxs.com (cook at unix1.netaxs.com [207.8.186.3]) by access.netaxs.com (8.7.6/8.6.11) with ESMTP id XAA03176; Wed, 13 Nov 1996 23:43:50 -0500 (EST)
Received: (from cook at localhost) by unix1.netaxs.com (8.7.6/8.7.3) id XAA05439; Wed, 13 Nov 1996 23:43:48 -0500 (EST)
Date: Wed, 13 Nov 1996 23:43:47 -0500 (EST)
Sender:ietf-request at ietf.org
From: Gordon Cook <cook at netaxs.com>
To: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>
cc: Tony Rutkowski <amr at chaos.com>, IETF at CNRI.Reston.VA.US, poised at tis.com,
newdom at vrx.net
Subject: Re: Re[2]: "Thank You" Jim Fleming !
In-Reply-To: <9610138479.AA847931491 at ncr.disa.mil>
Message-ID: <Pine.SUN.3.94.961113233941.4723G-100000 at unix1.netaxs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Tony..... are you really aware of the totality of the inane blathering of
Fleming??? And the number of people who are kill filing him or
automatically deleting him? If you were aware surely you'd be giving your
own arguments rather than urging that he be listened to!?
************************************************************************
The COOK Report on Internet For subsc. pricing & more than
431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material
(609) 882-2572 (phone & fax) visit http://pobox.com/cook/
Internet: cook at cookreport.com For case study of MercerNet &
TIIAP induced harm to local community http://pobox.com/cook/mercernet.html
************************************************************************
On Wed, 13 Nov 1996, C.Joe Pasquariello wrote:
> OH REALLY TONY !
>
> I'm surprised that you don't find the following Fleming comment of
> today [like others over recent days] anything BUT unfounded, personal
> and destructive!
>
> " 3. The appointed leaders in the IETF (and other I* leaders) have not
> necessarily signed up to be anything more than figureheads.
> As they are "pushed" from below, by the membership, they
> have a difficult time devoting their life to some cause when the
> reality of the world is that they mostly work for some
> company and mainly protect that company's interests,
> instead of the Internet's interest, or the people's interest."
> - Jim Fleming; 13 Nov 96
>
> See also Eastlake's comments of today on this point.
>
> I fail to see your point on the old CCITT/Internet animosity. Happily
> there is currently a growing degree of respect and cooperation today
> between the Internet community and the ITU-T. This has come about
> through mutual respect and civility on both sides - NOT through the
> sort of dialog being fostered by Mr Fleming. "Valuable" indeed !
>
> C.Joe P-->
> US/DoD/DISA
>
> ______________________________ Reply Separator _________________________________
> Subject: Re: "Thank You" Jim Fleming !
> Author: Tony Rutkowski <amr at chaos.com> at smtp
> Date: 11/13/96 3:54 PM
>
>
> Joe,
>
> > I have come away with increased respect for, and confidence in, the >
> many senior members and leaders of the I* community for the
> > extraordinary patience and thoroughness with which they have responded >
> to your many unfounded personal attacks and generally destructive
> > comments.
> >
> > For my part, I wish that you would 'leave' these lists and come back
> > after you have time to reflect on the courtesy they have extended to
> > you, and which I hope you would reciprocate.
>
> Giorno..
>
> As another senior member of the world community, I'd like
> to suggest that Jim is actually undertaking the valuable task
> of asking questions about existing institutions and roles
> from an alternative perspective. OK - he's been incredibly
> "productive" and sometimes bothersome, but nothing that warrants
> the characterization of "personal attacks and...destructive
> comments." He's been questioning direction, roles and
> authority, not personal integrity or competence. That's
> the sort of reaction we used to hear in the CCITT about
> the Internet community not too long ago.
>
> It's not going to serve the IETF well to force out people
> because they ask questions you don't like. I certainly wouldn't
> expect this in an organization that takes pride in accommodating
> diverse views and adapting to change. If nothing else, life
> on these lists (such as it is) would be much duller without Jim.
>
> ciao,
> --tony
>
>
>
Received: from ietf.org by ietf.org id aa00038; 14 Nov 96 7:52 EST
Received: from cnri by ietf.org id aa29669; 14 Nov 96 7:46 EST
Received: from mercury.Sun.COM by CNRI.Reston.VA.US id aa09006;
14 Nov 96 7:46 EST
Received: from Canada.Sun.COM ([129.155.1.11]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA07769; Thu, 14 Nov 1996 04:43:19 -0800
Received: from scooter.canada.sun.com by Canada.Sun.COM (4.1/SMI-4.1)
id AA00965; Thu, 14 Nov 96 07:43:18 EST
Received: from elsbeth.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
id HAA13748; Thu, 14 Nov 1996 07:43:13 -0500
Received: from elsbeth by elsbeth.canada.sun.com (SMI-8.6/SMI-SVR4)
id HAA08746; Thu, 14 Nov 1996 07:43:17 -0500
X-Orig-Sender: davecb at canada.sun.com
Message-Id: <328B13E5.B92 at scooter.canada.sun.com>
Date: Thu, 14 Nov 1996 07:43:17 -0500
Sender:ietf-request at ietf.org
From: David Collier-Brown <davecb at canada.sun.com>
Organization: The Orville Torpid Family and Friends
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.6 sun4m)
Mime-Version: 1.0
To: Tony Rutkowski <amr at chaos.com>
Cc: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>, IETF at CNRI.Reston.VA.US,
poised at tis.com, newdom at vrx.net
Subject: Re: "Thank You" Jim Fleming !
References: <3.0.32.19961113152945.00a92550 at fractal.chaos.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Tony Rutkowski wrote:
> [...] I'd like
> to suggest that Jim is actually undertaking the valuable task
> of asking questions about existing institutions and roles
> from an alternative perspective. OK - he's been incredibly
> "productive" and sometimes bothersome, but nothing that warrants
> the characterization of "personal attacks and...destructive
> comments." He's been questioning direction, roles and
> authority, not personal integrity or competence. That's
> the sort of reaction we used to hear in the CCITT about
> the Internet community not too long ago.
Alas, he's doing both.
I like his content, actually, but could do with
fewer colorfull adjectives (:-))
> It's not going to serve the IETF well to force out people
> because they ask questions you don't like. I certainly wouldn't
> expect this in an organization that takes pride in accommodating
> diverse views and adapting to change.
The House of Commons' task is almost entirely
to deal with change, and they **certainly** have a diversity
of views, yet even they throw out members who scream
at the speaker...
Seriously, though, the English nobility long ago emphasized
civility: not because they were particularly nice people, but as
an evil plot to make everyone think **everyone** else was a nice
person.
This lead to some debates over very contentious subjects
actually taking place: previously raising the question would have led to
bloodshead (people still wore daggers in those days).
If someone really wanted to prevent consideration of the points
Jim makes, he would be well advised to act just has Jim has. That
is sufficient to turn debate in **this** commons into a shouting
match.
And yes, this is exactly how the former newsgroup soc.women
was rendered ``nonthreatening'' by some commentators.
--dave
[and no, I don't think Jim or Bob are agents provacateurs, just a bit
high on adrenalin]
--
David Collier-Brown, | Cherish your enemies: they're harder
185 Ellerslie Ave., | to come by than friends, and MUCH more
Willowdale, Ontario | motivated.
CANADA M2N 1Y3 | -- me.
Received: from ietf.org by ietf.org id aa01710; 14 Nov 96 8:47 EST
Received: from mailer1.lut.ac.uk by ietf.org id aa01512; 14 Nov 96 8:44 EST
Received: from sun-cc201.lboro.ac.uk [158.125.1.201] (root)
by mailer1.lut.ac.uk with smtp (Exim 0.56 #2)
id E0vO241-0005II-00; Thu, 14 Nov 1996 13:42:41 +0000
Received: from comth by sun-cc201.lboro.ac.uk with smtp (Exim 0.56 #2)
id E0vO23q-0004qk-00; Thu, 14 Nov 1996 13:42:30 +0000
Date: Thu, 14 Nov 1996 13:42:28 +0000 (GMT)
Sender:ietf-request at ietf.org
From: martin hamilton <M.T.Hamilton at lboro.ac.uk>
X-Sender: comth at sun-cc201
Reply-To: martin hamilton <M.T.Hamilton at lboro.ac.uk>
To: ietf at ietf.org
Subject: Re: iTLDs
In-Reply-To: <199611140446.XAA17688 at black-ice.cc.vt.edu>
Message-ID: <Pine.SOL.3.95.961114131109.3569B-100000 at sun-cc201>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Wed, 13 Nov 1996 Valdis.Kletnieks at vt.edu wrote:
> However, note that a "URL for further information" may or may not
> exist (the company may be a startup and not be up to speed yet,
> or may for policy reasons wish to be an e-mail only participant
> behind a firewall). Also, "type of business offered" may be
> problematic for inclusion in a database, unless we specifically
> remember to be *very* flexible. What business is Phillip Morris
> in (or any other conglomerate)? What about the company in
> Florida that was recently in the news, who as *one* of their
> specialty cleaning services, remove the evidence from crime scenes?
It's perhaps also worth bearing in mind that there isn't necessarily a
one-to-one correspondence between organisations and domain names ?
> Note - they come in and clean bloodstains and the like *after*
> the police are satisfied, not clean up for organized crime figures
> before the police arrive ;) I suspect that there's a *really* fat
> Ph.D. thesis in it for anybody who figures out how to make this
> anywhere near natural-language searchable, for more than just English.
>
> Actually, I take that back. If *I* knew how to do it, I'd say
> "<explitive> the sheepskin", hack code, make a killing on the IPO,
> and then relax. ;)
:-))
> I admit to senility - is there an active list for discussing these
> sorts of directory issues, or should I look at creating one so
> we can move this whole thread there?
Well... I created the deploy list (see below) because I hadn't been able
to find an existing forum, though there are a number of directory services
and New Domain ;-) type lists. The thread would be welcome to move over
in this direction.
Cheerio,
Martin
| If anyone is interested in doing a little bit of practical experimentation
| on the FINDING front, I'd like to volunteer a mailing list over here which
| has been created for this purpose. Mail "deploy-request at mrrl.lut.ac.uk",
| with the word "subscribe" on its own in the message body, if you want to
| participate.
|
| Recommended reading... RFCs 1714, 1777, 1798, 1835, 1913 and 1914, plus
| draft-klensin-tld-whois-00.txt, and draft-ietf-find-new-cip-00.txt
Received: from ietf.org by ietf.org id aa01996; 14 Nov 96 8:59 EST
Received: from cnri by ietf.org id aa01855; 14 Nov 96 8:55 EST
Received: from ester.dsv.su.se by CNRI.Reston.VA.US id aa10520;
14 Nov 96 8:55 EST
Received: from localhost (jpalme at localhost)
by ester.dsv.su.se (8.7.1/8.7.1) with SMTP
id OAA03887;
Thu, 14 Nov 1996 14:53:34 +0100 (MET)
Date: Thu, 14 Nov 1996 14:53:34 +0100 (MET)
Sender:ietf-request at ietf.org
From: Jacob Palme <jpalme at dsv.su.se>
To: ietf-types at uninett.no
cc: ietf at CNRI.Reston.VA.US
Subject: ISO 639 Standardised Language Codes
Message-ID: <Pine.SUN.3.94.961114141910.3173B-100000 at ester.dsv.su.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Apparently, there are two versions of the ISO 639 standard
specifying codes for languages. Version 1 specifies two-letter
language codes, while version 2 specifies three-letter language
codes. I guess in practice this means that you must in input
support both the two and the three-letter code for each
language, or should we in IETF only accept the two letter
codes, since that is what is specified in RFC 1766?
The ISO codes can be found on the following web page:
http://www.dsv.su.se/~jpalme/ietf/language-codes.html
That web page contains an index for rapid retrieval of the ISO
language codes and links to other pages with the ISO codes
in other formats.
------------------------------------------------------------------------
Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Received: from ietf.org by ietf.org id aa04982; 14 Nov 96 9:42 EST
Received: from cnri by ietf.org id aa04640; 14 Nov 96 9:39 EST
Received: from callandor.cybercash.com by CNRI.Reston.VA.US id aa11565;
14 Nov 96 9:39 EST
Received: by callandor.cybercash.com; id JAA10289; Thu, 14 Nov 1996 09:32:38 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma010287; Thu, 14 Nov 96 09:32:37 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA16798; Thu, 14 Nov 96 09:35:42 EST
Date: Thu, 14 Nov 1996 09:35:41 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Jacob Palme <jpalme at dsv.su.se>
Cc: ietf-types at uninett.no, ietf at CNRI.Reston.VA.US
Subject: Re: ISO 639 Standardised Language Codes
In-Reply-To: <Pine.SUN.3.94.961114141910.3173B-100000 at ester.dsv.su.se>
Message-Id: <Pine.SUN.3.91.961114092601.16551A-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
My first inclination was to say that recognizing three letter language codes
where it's unambiguous seems fine, following the general "be liberal in what
you receive" principle. But for use in protocols, I thought we should
mandate generation only of two letter codes, the same way we only actually
use two letter country codes in DNS, even though there are also official
three letter country codes. [X.509 also mandates two letter country codes.]
However, on actually looking at your web page, there seem to be lots of
languages that *only* have three letter codes. Given that, I think both
two and three letters have to be generally acceptable for generation or
receipt.
Donald
On Thu, 14 Nov 1996, Jacob Palme wrote:
> Date: Thu, 14 Nov 1996 14:53:34 +0100 (MET)
> From: Jacob Palme <jpalme at dsv.su.se>
> To: ietf-types at uninett.no
> Cc: ietf at CNRI.Reston.VA.US
> Subject: ISO 639 Standardised Language Codes
>
> Apparently, there are two versions of the ISO 639 standard
> specifying codes for languages. Version 1 specifies two-letter
> language codes, while version 2 specifies three-letter language
> codes. I guess in practice this means that you must in input
> support both the two and the three-letter code for each
> language, or should we in IETF only accept the two letter
> codes, since that is what is specified in RFC 1766?
>
> The ISO codes can be found on the following web page:
> http://www.dsv.su.se/~jpalme/ietf/language-codes.html
>
> That web page contains an index for rapid retrieval of the ISO
> language codes and links to other pages with the ISO codes
> in other formats.
>
> ------------------------------------------------------------------------
> Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
> for more info see URL: http://www.dsv.su.se/~jpalme
>
>
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa05466; 14 Nov 96 9:47 EST
Received: from ietf.org by ietf.org id aa04031; 14 Nov 96 9:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-01.txt
Date: Thu, 14 Nov 1996 09:27:10 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611140927.aa04031 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : Security Architecture for the Internet Protocol
Author(s) : R. Atkinson
Filename : draft-ietf-ipsec-arch-sec-01.txt
Pages : 24
Date : 11/12/1996
This memo describes the security protocols for IP version 4 (IPv4) and IP
version 6 (IPv6) and the services that they provide. Each security
protocol is specified in a separate document. This document also describes
key management requirements for systems implementing these security
protocols. This document is not an overall Security Architecture for the
Internet; it addresses only IP-layer security.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-arch-sec-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-arch-sec-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961112150209.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-arch-sec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-arch-sec-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961112150209.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05492; 14 Nov 96 9:47 EST
Received: from ietf.org by ietf.org id aa03987; 14 Nov 96 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-thaler-interop-00.txt, .ps
Date: Thu, 14 Nov 1996 09:26:23 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611140926.aa03987 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Interoperability Rules for Multicast Routing Protocols
Author(s) : D. Thaler
Filename : draft-thaler-interop-00.txt, .ps
Pages : 16
Date : 11/12/1996
The rules described in this document will allow efficient interoperation
among multiple independent multicast routing domains. Specific
instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM,
PIM-SM, and CBT multicast routing protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-thaler-interop-00.txt".
Or
"get draft-thaler-interop-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-thaler-interop-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
