[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Received: from ietf.org by ietf.org id aa22819; 30 Oct 96 14:35 EST
Received: from zephyr.isi.edu by ietf.org id aa22461; 30 Oct 96 14:30 EST
Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA24006>; Wed, 30 Oct 1996 11:29:36 -0800
Message-Id: <199610301929.AA24006 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2032 on RTP Payload Format for H.261 Video
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 30 Oct 96 11:32:25 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 2032:
Title: RTP Payload Format for H.261 Video Streams
Author: T. Turletti, C. Huitema
Date: October 1996
Mailbox: turletti at sophia.inria.fr, huitema at bellcore.com
Pages: 11
Characters: 27,488
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2032.txt
This memo describes a scheme to packetize an H.261 video stream for
transport using the Real-time Transport Protocol, RTP, with any of the
underlying protocols that carry RTP. This RFC is a product of the
Audio/Video Transport Working Group of the IETF.
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: <961030112635.RFC at ISI.EDU>
SEND /rfc/rfc2032.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2032.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961030112635.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23281; 30 Oct 96 14:42 EST
Received: from zephyr.isi.edu by ietf.org id aa23069; 30 Oct 96 14:39 EST
Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA24536>; Wed, 30 Oct 1996 11:38:51 -0800
Message-Id: <199610301938.AA24536 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2051 on SNANAU APPC MIB using SMIv2
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 30 Oct 96 11:41:40 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 2051:
Title: Definitions of Managed Objects for APPC using
SMIv2
Author: M. Allen, B. Clouston, Z. Kielczewski, W. Kwan,
B. Moore
Date: October 1996
Mailbox: mallen at hq.walldata.com, clouston at cisco.com,
zbig at cisco.com, billk at jti.com,
remoore at ralvm6.vnet.ibm.com
Pages: 124
Characters: 239,359
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2051.txt
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing the configuration,
monitoring and controlling of network devices with APPC (Advanced
Program-to-Program Communications) capabilities. This memo identifies
managed objects for the SNA LU6.2 protocols. This RFC is a product of
the SNA NAU MIB Working Group of the IETF.
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: <961030113634.RFC at ISI.EDU>
SEND /rfc/rfc2051.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2051.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961030113634.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23855; 30 Oct 96 14:54 EST
Received: from smtp2.erols.com by ietf.org id aa23547; 30 Oct 96 14:47 EST
Received: from .erols.com (spg-as40s59.erols.com [207.96.17.59]) by smtp2.erols.com (8.7.5/8.7.3) with SMTP id OAA11678; Wed, 30 Oct 1996 14:46:33 -0500 (EST)
Date: Wed, 30 Oct 1996 14:46:33 -0500 (EST)
Message-Id: <199610301946.OAA11678 at smtp2.erols.com>
X-Sender: ghopkins at pop.erols.com
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Bill Frezza <frezza at interramp.com>
Sender:ietf-request at ietf.org
From: "Gerald L. Hopkins" <ghopkins at erols.com>
Subject: Re: The cartel begins to crumble?
Cc: ietf at ietf.org, namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Source-Info: From (or Sender) name not authenticated.
Bill,
As Dave Crocker and Tony and others have indicated, it's thru enlightened
self-interest rather than compulsion. Standards activity, even in the more
"traditional" standards-setting bodies such as ANSI are voluntary. To make
them compulsory may seem like a good idea to ensure interoperability or some
other desirable goal, but in practice it only stifles competition, inhibits
innovation, and encourages technological tyranny. We wouldn't want that, now
would we?
(Sidenote: most of my previous experience is in the more traditional
standards organizations, but I have to concur with the views and comments
I've seen expressed from these IETFers.)
At 10:03 AM 10/30/96 -0500, you wrote:
>Dave Crocker writes:
>
>>You may have concerns over the current operation of IANA. You may
>>have specific changes in mind. But rest assured that the solution will
>>require a central authority, if the solution is to be viable.
>
>HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
>Please describe how this central authority will compel people around the
>world to obey its edicts.
>
>Thanks you,
>
>Bill Frezza
>CommunicationsWeek
>frezza at interramp.com
>http://techweb.cmp.com/nc/frezza/frezza.html
>
>
>
>
Gerald L. Hopkins
The ISDN Literacy Book
Addison-Wesley
Received: from ietf.org by ietf.org id aa00208; 30 Oct 96 16:03 EST
Received: from [165.121.1.55] by ietf.org id aa28374; 30 Oct 96 15:55 EST
Received: from Pinchas.sprynet.com (ad54-029.compuserve.com [199.174.187.29]) by m3.sprynet.com (8.6.12/8.6.12) with SMTP id MAA07443 for <ietf at ietf.org>; Wed, 30 Oct 1996 12:52:23 -0800
Message-ID: <3277C059.7617 at sprynet.com>
Date: Wed, 30 Oct 1996 12:53:45 -0800
Sender:ietf-request at ietf.org
From: Phillip Charles Oliff <pinchas at sprynet.com>
Reply-To: pinchas at sprynet.com
Organization: PCO Research, Inc.
X-Mailer: Mozilla 3.0Gold (Win95; U)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: Re: The Cartel Begins to Crumble
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Gentlemen/Ladies:
I wanted to point out that it is NOT the standards bodies
that set the industry standards but the OEM and user contingencies
who really set the pace. Although the standards bodies exist to
set a standard, they are not the dinfinative real-world rules to
live by.
Major companies have their own agenda and are able to influence
the market into accepting their version of the "standard".
I firmly believe that the stregnth of standards bodies is contingent
upon its members. If the body wishes for a standard to be followed
and enforced, its members must influence their employers to do so.
The best way for standards bodies to be effective is for its members
to take part in decision making processes of the OEM's and software
houses.
Remember that standards cannot be viewed in a vaccume as a static
academic endevor. We cannot simply mill-out scientific theory for the
sake of our existance. we cannot just sit on our hands and pray that the
industry forces will come our way. Many very good ideas have been
lost to the bowels of history simply because the inventors have
made improper effort in marketing and enforcing their "brain-child".
One final observation, as the Internet grows, the efforts of the
IETF will seem insignificant as compared to the industry giants.
It seems that the computer industry has a short memory and will
soon forget about our efforts if not properly reminded.
Thank You for your time and patience.
Regards:
Phill
--
------------------------------------------------------------
Phillip Charles Oliffpinchas at sprynet.com
PCO Research, Inc.PinchasSJM at aol.com
Post Office Box 3308
Beverly Hills, CA 90212-0308
http://members.aol.com/PinchasSJM/index.html
------------------------------------------------------------
Received: from ietf.org by ietf.org id aa03428; 30 Oct 96 16:21 EST
Received: from coral.llnl.gov by ietf.org id aa03309; 30 Oct 96 16:19 EST
Received: from [128.115.96.72] (jedsmac.llnl.gov [128.115.96.72]) by coral.llnl.gov (8.7.5/8.7.3/LLNL-Jun96) with ESMTP id NAA23165; Wed, 30 Oct 1996 13:17:45 -0800 (PST)
X-Sender: jed at coral.llnl.gov
Message-Id: <v0300785aae9d84cb8f51 at [128.115.96.72]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 30 Oct 1996 14:20:16 -0800
To: Wolfgang Henke <wolfgang at netcom.com>
Sender:ietf-request at ietf.org
From: "James E. [Jed] Donnelley" <jed at llnl.gov>
Subject: Re: The cartel begins to crumble?
Cc: Bill Frezza <frezza at interramp.com>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Bill Frezza:
> HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
> Please describe how this central authority will compel people around the
> world to obey its edicts.
Wolfgang Henke:
>It cant compel anything. It works more like the ITU which issues
>*recommendations* (like for example ITU-T V.34 modem standards).
>Companies or users decide voluntarily to use these recommendations
>if they see a benefit in them. Some ITU recommendations get generally
>bypassed, others are widely implemented.
Hmmm. I think perhaps this is a bit of a simplification
(if I am correctly tuned into the debate). When it comes
to the registration of and authorization for use of DNS names,
there is more than a recommendation (which can be ignored
or not) involved.
Regardless, I think Mr. Crocker said it best:
>...rest assured that the solution will
>require a central authority, if the solution is to be viable.
Vince Wolodkin:
>Hmmmm, possibly suspension of domain name???
Of course.
--Jed http://www-atp.llnl.gov/atp/jed-signature.html
Received: from ietf.org by ietf.org id aa03736; 30 Oct 96 16:22 EST
Received: from coral.llnl.gov by ietf.org id aa03401; 30 Oct 96 16:21 EST
Received: from [128.115.96.72] (jedsmac.llnl.gov [128.115.96.72]) by coral.llnl.gov (8.7.5/8.7.3/LLNL-Jun96) with ESMTP id NAA23222 for <ietf at ietf.org>; Wed, 30 Oct 1996 13:19:19 -0800 (PST)
X-Sender: jed at coral.llnl.gov
Message-Id: <v03007856ae9d74d6cee9 at [128.115.96.72]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 30 Oct 1996 14:21:51 -0800
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "James E. [Jed] Donnelley" <jed at llnl.gov>
Subject: English is it -> was: Re: The cartel begins to crumble?
Source-Info: From (or Sender) name not authenticated.
I have been following this discussion r.e. English and the
IETF, but am at a loss to know what it might hope to
achieve.
There has been no debate in the discussion about whether
English is the language of choice for IETF (and more
generally scientific and international commerce) communication.
It is.
Are we trying to make it easier for people with weak English
skills (perhaps because they are not native English speakers)
to participate in the IETF? That seems a laudable goal.
However, I haven't seen any discussion in this thread
that directly addressed this goal.
Hiring translators was mentioned, but I don't believe
seriously. I certainly think it would not be worthwhile
translating all the e-mail that flys by - it's value
(this message included) is not sufficient to justify
the costs. While I think translators at meetings can
be handled on a case by case basis, I also don't think
that more translators are generally justified. I
certainly don't think it is worthwhile to go in the
direction of the European Commission - any to any
language translation.
So then, other than deploring the sort of boorish behavior
that Mr. Ohta mentioned (which English speaking people have
perhaps a deserved reputation for, but by no means a
monopoly position on), what do we have left? The issue
of the location of the meetings? It seems to me that
is dealt with on a case by case basis - though I am sure
this language (or is it national?) neutrality
aspect is a reasonable topic to come in the discussion
of sites.
--Jed http://www-atp.llnl.gov/atp/jed-signature.html
Received: from ietf.org by ietf.org id aa05620; 30 Oct 96 16:55 EST
Received: from netcom20.netcom.com by ietf.org id aa05398; 30 Oct 96 16:53 EST
Received: (from wolfgang at localhost) by netcom20.netcom.com (8.6.13/Netcom)
id NAA14340; Wed, 30 Oct 1996 13:52:16 -0800
Date: Wed, 30 Oct 1996 13:52:16 -0800
Sender:ietf-request at ietf.org
From: Wolfgang Henke <wolfgang at netcom.com>
Message-Id: <199610302152.NAA14340 at netcom20.netcom.com>
To: jed at llnl.gov, wolfgang at netcom.com
Subject: Re: The cartel begins to crumble?
Cc: frezza at interramp.com, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Bill Frezza:
> HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
> Please describe how this central authority will compel people around the
> world to obey its edicts.
Wolfgang Henke:
>It cant compel anything. It works more like the ITU which issues
>*recommendations* (like for example ITU-T V.34 modem standards).
>Companies or users decide voluntarily to use these recommendations
>if they see a benefit in them. Some ITU recommendations get generally
>bypassed, others are widely implemented.
Hmmm. I think perhaps this is a bit of a simplification
(if I am correctly tuned into the debate). When it comes
to the registration of and authorization for use of DNS names,
there is more than a recommendation (which can be ignored
or not) involved.
It's not more than a commonly accepted communication standard. A single
user can not easily ignore such standards if he intends to communicate
with others, but a group of users may well be able to do so and
communicate among themselves.
Regardless, I think Mr. Crocker said it best:
>...rest assured that the solution will
>require a central authority, if the solution is to be viable.
All communication requires some commonly accepted standards, like the
English language, or Japanese, or V.34 or TCP/IP to be useful. There is
no central authority required to enforce the use of the English language
that I know of, but it's very useful nonetheless.
Vince Wolodkin:
>Hmmmm, possibly suspension of domain name???
Of course.
So? Anybody can invent another communication standard and try to convince a
group of users that it's useful. Companies and users will switch to your
system voluntarily only if they see a benefit. Or do you want to compel
users into a new system unvoluntarily?
--Jed http://www-atp.llnl.gov/atp/jed-signature.html
Wolfgang
Wolfgang Henke wolfgang at whnet.com . http://www.whnet.com
WH Networks ... ftp://ftp.whnet.com
2672 Bayshore Parkway, Suite 503 .......... fax (415) 390 9317
Mountain View, CA 94043 .................. (415) 390 9316
Received: from ietf.org by ietf.org id aa07062; 30 Oct 96 17:10 EST
Received: from nacho.cisco.com by ietf.org id aa06191; 30 Oct 96 17:07 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 OAA13657; Wed, 30 Oct 1996 14:05:13 -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 OAA00800; Wed, 30 Oct 1996 14:05:10 -0800
X-Sender: fred at stilton.cisco.com
Message-Id: <v02140b04ae9d7d17e389 at [171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 30 Oct 1996 14:03:34 -0800
To: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Re: The cartel begins to crumble?
Cc: perry at piermont.com, dcrocker at brandenburg.com, frezza at interramp.com,
ietf at ietf.org, namedroppers at internic.net
Source-Info: From (or Sender) name not authenticated.
At 11:10 AM 10/30/96, Masataka Ohta wrote:
>> You can even almost fully participate simply over email.
>
>Only in theory, yes.
You might ask Vernon Schryver's opinion there. He's been doing exactly that
for about a decade.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I don't suffer from insanity. I enjoy every minute of it.
Received: from ietf.org by ietf.org id aa07319; 30 Oct 96 17:16 EST
Received: from faui40.informatik.uni-erlangen.de by ietf.org id aa07222;
30 Oct 96 17:15 EST
Received: from faui45r.informatik.uni-erlangen.de (eckert at faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP
id XAA19815 (8.7.6/7.5b-FAU); Wed, 30 Oct 1996 23:10:09 +0100 (MET)
Sender:ietf-request at ietf.org
From: Toerless Eckert <Toerless.Eckert at informatik.uni-erlangen.de>
Message-Id: <199610302210.XAA19815 at faui40.informatik.uni-erlangen.de>
Subject: Re: The cartel begins to crumble?
To: Tony Li <tli at jnx.com>
Date: Wed, 30 Oct 1996 23:10:05 +0100 (MET)
Cc: frezza at interramp.com, ietf at ietf.org, namedroppers at internic.net,
com-pri at psi.com, newdom at ar.com
In-Reply-To: <199610301806.KAA10762 at chimp.jnx.com> from "Tony Li" at Oct 30, 96 10:06:57 am
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> Remember that the Internet is a cooperative anarchy, not a dictatorship.
And the top-level domain defines the corporate identity of this
dictatorship, huh ? eh "anarchy" ;-))
We just happen to see the end of this anarchy as it is challenged
by legal actions.
Received: from ietf.org by ietf.org id aa08108; 30 Oct 96 17:21 EST
Received: from nirvana.genesyslab.com by ietf.org id aa07968;
30 Oct 96 17:20 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 OAA26374; Wed, 30 Oct 1996 14:19:32 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA06915; Wed, 30 Oct 1996 14:19:11 -0800 (PST)
Date: Wed, 30 Oct 1996 14:19:11 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199610302219.OAA06915 at giant.genesyslab.com>
To: frezza at interramp.com, kre at munnari.oz.au
Subject: Re: The cartel begins to crumble?
Cc: com-pri at psi.com, ietf at ietf.org, newdom at ar.com
Source-Info: From (or Sender) name not authenticated.
>From: Robert Elz <kre at munnari.oz.au>
> From: Bill Frezza <frezza at interramp.com>
>
> Please describe how this central authority will compel people around the
> world to obey its edicts.
>
>It won't compel anyone to do anything, just as the international
>phone numbering people neither do (nor can) compel me to number
>my phones in accordance with the number schemes that they set.
Oh, no - phone example is not in place: let's wait the FCC rules
about local phone competition get force and after that you can see
that happens with "phone numbering" !
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa09295; 30 Oct 96 17:34 EST
Received: from mh1.well.com by ietf.org id aa09180; 30 Oct 96 17:32 EST
Received: from [206.15.64.249] (sr-tty28-ppp.well.com [206.15.64.238]) by mh1.well.com (8.7.6/8.7.5) with ESMTP id OAA19223 for <ietf at ietf.org>; Wed, 30 Oct 1996 14:31:38 -0800 (PST)
Date: Wed, 30 Oct 1996 14:31:38 -0800 (PST)
X-Sender: rreed at mail.well.com
Message-Id: <v03007821ae9d25d32766 at [206.15.64.249]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robin Reed <robin at reedgroup.com>
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa10345; 30 Oct 96 17:42 EST
Received: from red.jnx.com by ietf.org id aa10044; 30 Oct 96 17:40 EST
Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.7.6/8.7.3) with ESMTP id OAA21275; Wed, 30 Oct 1996 14:39:54 -0800 (PST)
Received: (from tli at localhost) by chimp.jnx.com (8.7.5/8.7.3) id OAA11441; Wed, 30 Oct 1996 14:39:46 -0800 (PST)
Date: Wed, 30 Oct 1996 14:39:46 -0800 (PST)
Message-Id: <199610302239.OAA11441 at chimp.jnx.com>
Sender:ietf-request at ietf.org
From: Tony Li <tli at jnx.com>
To: Toerless.Eckert at informatik.uni-erlangen.de
CC: frezza at interramp.com, ietf at ietf.org, namedroppers at internic.net,
newdom at ar.com
In-reply-to: <199610302210.XAA19815 at faui40.informatik.uni-erlangen.de>
(message from Toerless Eckert on Wed, 30 Oct 1996 23:10:05 +0100
BAD MSG:
(MET))
ubject: Re: The cartel begins to crumble?
Source-Info: From (or Sender) name not authenticated.
We just happen to see the end of this anarchy as it is challenged
by legal actions.
Possibly, but I hope not. The end of this anarchy implies that the
Internet partitions (more anarchy, more lawsuits) or is over-regulated
(less anarchy, more lawsuits). Hopefully what we're seeing is a wee bit of
negative feedback in the system.
Tony
p.s. The lawyers will win. ;-(
Received: from ietf.org by ietf.org id aa14528; 30 Oct 96 18:41 EST
Received: from bast.livingston.com by ietf.org id aa14357; 30 Oct 96 18:39 EST
Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id PAA07576; Wed, 30 Oct 1996 15:38:46 -0800 (PST)
Received: (from megazone at localhost) by server.livingston.com (8.7.1/8.6.9) id PAA10804; Wed, 30 Oct 1996 15:37:29 -0800 (PST)
Message-Id: <199610302337.PAA10804 at server.livingston.com>
Subject: Re: The cartel begins to crumble?
To: Bill Frezza <frezza at interramp.com>
Date: Wed, 30 Oct 1996 15:37:29 -0800 (PST)
Cc: dcrocker at brandenburg.com, ietf at ietf.org, namedroppers at internic.net,
com-pri at psi.com, newdom at ar.com
In-Reply-To: <v03007804ae9cd2f9dbf1 at [38.26.44.118]> from "Bill Frezza" at Oct 30, 96 10:03:41 am
Sender:ietf-request at ietf.org
From: MegaZone <megazone at livingston.com>
Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Once upon a time Bill Frezza shaped the electrons to say...
>Dave Crocker writes:
>>You may have concerns over the current operation of IANA. You may
>>have specific changes in mind. But rest assured that the solution will
>>require a central authority, if the solution is to be viable.
>HONEST QUESTION (please cc: me as I do not monitor all these groups)
>Please describe how this central authority will compel people around the
>world to obey its edicts.
Market force.
If you start AlterNIC2 and start selling DNS access and maybe a few others
decide to use your services - and then they discover that only less that 1% of
the people online use an AlterNIC2 DNS, so the other 99%+ can't get to their
site. I expect a business would be very upset, and I would too. Which is
why as an experienced user I am registering a domain with the IANA, NOT
AlterNIC. You register a domain for a reason - you want people to be able
to see it.
NOTHING is stopping ANYONE from creating a new TLD. YOu just have to put it
in your DNS server and let it fly. But only people using your server can
access it, and you have to convince other people that this is a good thing
to carry. AlterNIC is not well received, and not one of the sysadmins I know
(And that is a large number, because of the work I do) is supporting it.
Without support it is just a joke, the average user doesn't even know what
DNS *is* let alone how it works or what they do to use another one.
Unless someone can develop some holistic name resolution protocol that can
pull names off the ether without some hierarchy, alternative TLDs will remain
a fringe item, a joke. DNS requires a preconfigured fall back, and it
has to stop somewhere: A asks B who asks C who asks D - D doesn't know it
doesn't exist, the end.
As a systems administrator I don't trust AlterNIC, so I will never set DNS
to use their service. And I'm certainly not in the minority on that one.
So anyone who really wants to have their domain usable will use the IANA.
I DO feel that we need new name space, it is damn crowded now. I think
a .per domain (personal sites) would be useful, so many people have personal
domains (Heck, I just applied for a .org for personal use). It would also
be nices to have some differentiation between ISPs and corporations online.
.com is already to fixed, maybe a new .isp and .cor TLDs.
A friend of mine runs Righteous Babe Records - so I tried to get them a
domain for business: rbr.com, righteous.com are taken. righteousbabe.com is
taken by a fan, I'm trying to get him to sell to me. Right now I'm looking
at having to go with righteousbaberecords.com - and that's long enough to
be ugly. (I can't use rigtheousrecords.com - well, can't/won't - there is
another company by that name, even if they don't have it I'm not rude enough
to take it.)
Things are getting crowded.
But even with this AlterNIC isn't even in the running as a viable alternative.
It is like newsgroups in a way - it is dirt easy to create an alt group,
and you have to deal with all kinds of rules for other hierarchies. Yet
if you want things to be taken seriously and have a better chance at
distribution, you deal with the rules and run the RFD/CFV.
-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone at livingston.com
For support requests: support at livingston.com <http://www.livingston.com/>
Snail mail: 6920 Koll Center Parkway #220, Pleasanton, CA 94566
Received: from cnri by ietf.org id aa20832; 30 Oct 96 19:54 EST
Received: from granola.Cisco.COM by CNRI.Reston.VA.US id aa26167;
30 Oct 96 19:53 EST
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by granola.cisco.com (8.6.12/8.6.5) with ESMTP id QAA05115 for <snanaumib at aliashost.cisco.com>; Wed, 30 Oct 1996 16:47:06 -0800
Received: from jti.com (bart.jti.com [198.22.30.1]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id QAA14802 for <snanaumib at cisco.com>; Wed, 30 Oct 1996 16:46:56 -0800 (PST)
Resent-Message-Id: <199610310046.QAA14802 at hubbub.cisco.com>
Received: from charon.jti.com by jti.com with SMTP id AA06464
(5.65c/IDA-1.5 for <snanaumib at cisco.com>); Wed, 30 Oct 1996 19:46:40 -0500
Received: From JUP-NOVA1/WORKQUEUE by charon.jti.com
via Charon-4.0-VROOM with IPX id 100.961030194614.448;
30 Oct 96 19:46:45 +500
Message-Id: <MAILQUEUE-101.961030194611.416 at jup-nova1.jti.com>
Resent-From: Bill Kwan <billk at jup-nova1.jti.com>
Resent-To: snanaumib at cisco.com
Resent-Date: Wed, 30 Oct 1996 19:46:12 EST5EDT
Received: from jti.com (bart.jti.com [198.22.30.1]) by home.gis.net (8.8.0/8.6.11) with SMTP id TAA18974 for <kwan at gis.net>; Wed, 30 Oct 1996 19:39:14 -0500 (EST)
Received: from ietf.org by jti.com with SMTP id AA06448
(5.65c/IDA-1.5 for <billk at jti.com>); Wed, 30 Oct 1996 19:39:22 -0500
Received: from ietf.org by ietf.org id aa23107; 30 Oct 96 14:40 EST
Received: from zephyr.isi.edu by ietf.org id aa23069; 30 Oct 96 14:39 EST
Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA24536>; Wed, 30 Oct 1996 11:38:51 -0800
Message-Id: <199610301938.AA24536 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2051 on SNANAU APPC MIB using SMIv2
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Date: Wed, 30 Oct 96 11:41:40 PST
Sender: ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
Content-Type: Multipart/Mixed; Boundary=NextPart
X-Uidl: 0c46ca59a520dc40cebf0ab550345163
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2051:
Title: Definitions of Managed Objects for APPC using
SMIv2
Author: M. Allen, B. Clouston, Z. Kielczewski, W. Kwan,
B. Moore
Date: October 1996
Mailbox: mallen at hq.walldata.com, clouston at cisco.com,
zbig at cisco.com, billk at jti.com,
remoore at ralvm6.vnet.ibm.com
Pages: 124
Characters: 239,359
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2051.txt
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing the configuration,
monitoring and controlling of network devices with APPC (Advanced
Program-to-Program Communications) capabilities. This memo identifies
managed objects for the SNA LU6.2 protocols. This RFC is a product of
the SNA NAU MIB Working Group of the IETF.
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: <961030113634.RFC at ISI.EDU>
SEND /rfc/rfc2051.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2051.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961030113634.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25998; 30 Oct 96 21:11 EST
Received: from ns.research.att.com by ietf.org id aa25622; 30 Oct 96 21:07 EST
Received: from research.att.com by ns; Wed Oct 30 21:05:07 EST 1996
Received: from smb.research.att.com by research; Wed Oct 30 21:02:33 EST 1996
Received: from smb.research.att.com (smb at localhost) by smb.research.att.com (8.6.12/8.6.10) with ESMTP id SAA03384; Wed, 30 Oct 1996 18:14:11 -0500
Message-Id: <199610302314.SAA03384 at smb.research.att.com>
X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs
To: Bill Frezza <frezza at interramp.com>
cc: Dave Crocker <dcrocker at brandenburg.com>, ietf at ietf.org,
namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Subject: Re: The cartel begins to crumble?
Date: Wed, 30 Oct 1996 18:06:40 -0500
Sender:ietf-request at ietf.org
From: Steve Bellovin <smb at research.att.com>
Source-Info: From (or Sender) name not authenticated.
Dave Crocker writes:
>You may have concerns over the current operation of IANA. You may
>have specific changes in mind. But rest assured that the solution wi
ll
>require a central authority, if the solution is to be viable.
HONEST QUESTION (please cc: me as I do not monitor all these groups)
Please describe how this central authority will compel people around
the world to obey its edicts.
This is indeed a problem. Unfortunately, it's one without an answer --
*any* policy has to be accepted; none are enforceable. And please
believe me that for technical reasons (which I'll be glad to spell
out), the creation of alternate DNS roots *will* cause trouble, even
for those who choose not to accept their authority.
--Steve Bellovin
Received: from ietf.org by ietf.org id aa27670; 30 Oct 96 21:48 EST
Received: from ns.research.att.com by ietf.org id aa27399; 30 Oct 96 21:46 EST
Received: from research.att.com by ns; Wed Oct 30 21:44:07 EST 1996
Received: from raptor.research.att.com by research; Wed Oct 30 21:43:18 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 VAA25606; Wed, 30 Oct 1996 21:43:16 -0500 (EST)
Message-Id: <199610310243.VAA25606 at raptor.research.att.com>
To: Fred Baker <fred at cisco.com>
cc: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>, perry at piermont.com,
dcrocker at brandenburg.com, frezza at interramp.com, ietf at ietf.org,
namedroppers at internic.net
Subject: Re: The cartel begins to crumble?
Date: Wed, 30 Oct 1996 21:43:16 -0500
Sender:ietf-request at ietf.org
From: Steven Bellovin <smb at research.att.com>
Source-Info: From (or Sender) name not authenticated.
At 11:10 AM 10/30/96, Masataka Ohta wrote:
>> You can even almost fully participate simply over email.
>
>Only in theory, yes.
You might ask Vernon Schryver's opinion there. He's been doing exactly
that for about a decade.
I'm another example. While I attend IETF meetings regularly now (and
am an IAB member), at the time I was asked to serve on the IPng directorate
I had never been to a single IETF. My first one, in fact, was only three
years ago, in Houston.
--Steve Bellovin
Received: from ietf.org by ietf.org id aa29140; 30 Oct 96 21:55 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa29052;
30 Oct 96 21:53 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199610310251.LAA11198 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id LAA11198; Thu, 31 Oct 1996 11:51:19 +0900
Subject: Re: The cartel begins to crumble?
To: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
Date: Thu, 31 Oct 96 11:51:18 JST
Cc: ietf at ietf.org
In-Reply-To: <9610301639.AA31904 at dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Oct 30, 96 5:39 pm
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
Brian;
> Just in case my words in French were misinterpreted -
No. As I replied in Japanese, that was fine.
> Having worked for 20 years about half in my native
> language and half in a foreign language, I feel great
> sympathy for non-English speakers who are willing
> to step up to the microphone in IETF meetings.
You are wrong.
We are OK.
You should and I do feel sympathy for those who can't step up to the
microphone in IETF meetings even though they are there and have
their own opinion.
Masataka Ohta
Received: from ietf.org by ietf.org id aa00311; 30 Oct 96 22:05 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa00188;
30 Oct 96 22:04 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199610310302.MAA11296 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id MAA11296; Thu, 31 Oct 1996 12:01:50 +0859
Subject: Re: The cartel begins to crumble?
To: Valdis.Kletnieks at vt.edu
Date: Thu, 31 Oct 96 12:01:49 JST
Cc: mohta at necom830.hpcl.titech.ac.jp, ietf at ietf.org
In-Reply-To: <199610301731.MAA23928 at black-ice.cc.vt.edu>; from "Valdis.Kletnieks at vt.edu" at Oct 30, 96 12:31 pm
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
> > But, what I have experienced so far in IETF, instead, is that
> > technically cornered people suddenly attacked my English was
> > not perfect.
> Masataka: I can appreciate the problems you face sometimes making
> yourself understood. Dealing with *any* non-native language can
> create a grammatical hodgepodge that the listener is unable to parse
> effectively(*).
Listener? It happens with e-mail discussion, after I realize the
attackers perfectly understand the technical points.
Masataka Ohta
Received: from ietf.org by ietf.org id aa00493; 30 Oct 96 22:09 EST
Received: from mist.marimo.or.jp by ietf.org id aa00393; 30 Oct 96 22:07 EST
Received: from kushiro-53.sems.co.jp by mist.marimo.or.jp (NX5.67f/3.5Wbeta)
id AA13927; Thu, 31 Oct 96 12:03:14 +0900
Message-Id: <3279065A.14FA at sems.co.jp>
Date: Thu, 31 Oct 1996 12:04:42 -0800
Sender:ietf-request at ietf.org
From: Daniel Minoru Saito <daniel at sems.co.jp>
Reply-To: daniel at sems.co.jp
Organization: SanEsu Management Systems, INC. (SEMS)
X-Mailer: Mozilla 3.0 (Win95; I)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: unsubscribe <daniel at sems.co.jp>
References: <v03007821ae9d25d32766 at [206.15.64.249]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa01402; 30 Oct 96 22:17 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa01211;
30 Oct 96 22:15 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199610310312.MAA11382 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id MAA11382; Thu, 31 Oct 1996 12:11:52 +0859
Subject: Re: The cartel begins to crumble?
To: Steven Bellovin <smb at research.att.com>
Date: Thu, 31 Oct 96 12:11:51 JST
Cc: fred at cisco.com, mohta at necom830.hpcl.titech.ac.jp, perry at piermont.com,
dcrocker at brandenburg.com, frezza at interramp.com, ietf at ietf.org,
namedroppers at internic.net
In-Reply-To: <199610310243.VAA25606 at raptor.research.att.com>; from "Steven Bellovin" at Oct 30, 96 9:43 pm
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
> >> You can even almost fully participate simply over email.
> >
> >Only in theory, yes.
>
> You might ask Vernon Schryver's opinion there. He's been doing exactly
> that for about a decade.
>
> I'm another example. While I attend IETF meetings regularly now
Why?
> (and
> am an IAB member), at the time I was asked to serve on the IPng directorate
> I had never been to a single IETF. My first one, in fact, was only three
> years ago, in Houston.
And you decided to regularly join meetings to fully participate,
didn't you?
Masataka Ohta
Received: from ietf.org by ietf.org id aa03404; 30 Oct 96 22:29 EST
Received: from ns.research.att.com by ietf.org id aa03320; 30 Oct 96 22:27 EST
Received: from research.att.com by ns; Wed Oct 30 22:26:01 EST 1996
Received: from raptor.research.att.com by research; Wed Oct 30 22:24:02 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 WAA29275; Wed, 30 Oct 1996 22:24:02 -0500 (EST)
Message-Id: <199610310324.WAA29275 at raptor.research.att.com>
To: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
cc: fred at cisco.com, perry at piermont.com, dcrocker at brandenburg.com,
frezza at interramp.com, ietf at ietf.org, namedroppers at internic.net
Subject: Re: The cartel begins to crumble?
Date: Wed, 30 Oct 1996 22:24:02 -0500
Sender:ietf-request at ietf.org
From: Steven Bellovin <smb at research.att.com>
Source-Info: From (or Sender) name not authenticated.
> >> You can even almost fully participate simply over email.
> >
> >Only in theory, yes.
>
> You might ask Vernon Schryver's opinion there. He's been doing
exactly
> that for about a decade.
>
> I'm another example. While I attend IETF meetings regularly now
Why?
As an IAB member, it's more or less my obligation...
> (and
> am an IAB member), at the time I was asked to serve on the IPng dire
ctorate
> I had never been to a single IETF. My first one, in fact, was only
three
> years ago, in Houston.
And you decided to regularly join meetings to fully participate,
didn't you?
It's certainly easier to participate in person. If nothing else, being
there for a week focuses one's attention on the Internet protocols.
But an equal factor was a change in my personal circumstances -- my
children were enough older that my absences were much easier on my
wife. (Not that it's easy now for my wife -- just easier...) It's only
since my youngest started school that I've started attending every IETF
meeting.
No one said that email was a full substitute. I've retained the
quoted text so that the word ``almost'' still appears.
Btw -- as someone who isn't fluent in any other language than English,
I have nothing but the greatest admiration for people who can function
well in other languages. To my knowledge, I've never once commented
on errors in English grammar or spelling by non-native speakers -- they're
meeting me far more than half-way, and it's up to me to extend every
effort I can to understand them.
Received: from ietf.org by ietf.org id aa04743; 30 Oct 96 22:51 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id ab04400;
30 Oct 96 22:49 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199610310347.MAA11537 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id MAA11537; Thu, 31 Oct 1996 12:46:59 +0859
Subject: Re: The cartel begins to crumble?
To: Steven Bellovin <smb at research.att.com>
Date: Thu, 31 Oct 96 12:46:57 JST
Cc: mohta at necom830.hpcl.titech.ac.jp, fred at cisco.com, perry at piermont.com,
dcrocker at brandenburg.com, frezza at interramp.com, ietf at ietf.org,
namedroppers at internic.net
In-Reply-To: <199610310324.WAA29275 at raptor.research.att.com>; from "Steven Bellovin" at Oct 30, 96 10:24 pm
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
Steve;
> No one said that email was a full substitute. I've retained the
> quoted text so that the word ``almost'' still appears.
And it is a subjective matter of how almost it is.
> To my knowledge, I've never once commented
> on errors in English grammar or spelling by non-native speakers
Please don't hesitate to correct my English errors, especially
those in Internet Drafts, publicly or privately.
I don't mind if someone says I can't use a not-so-elegant (IMO :-)
trade language so well.
Masataka Ohta
Received: from ietf.org by ietf.org id aa10318; 30 Oct 96 23:12 EST
Received: from mist.marimo.or.jp by ietf.org id aa10058; 30 Oct 96 23:10 EST
Received: from kushiro-53.sems.co.jp by mist.marimo.or.jp (NX5.67f/3.5Wbeta)
id AA15743; Thu, 31 Oct 96 13:06:04 +0900
Message-Id: <3279150E.4632 at sems.co.jp>
Date: Thu, 31 Oct 1996 13:07:26 -0800
Sender:ietf-request at ietf.org
From: Daniel Minoru Saito <daniel at sems.co.jp>
Reply-To: daniel at sems.co.jp
Organization: SanEsu Management Systems, INC. (SEMS)
X-Mailer: Mozilla 3.0 (Win95; I)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: Sorry to intrude.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I hate to protrude into this nice little conversation in regards to `The
cartel begins to crumble...` but if anyone could show me the way out of
this listserver. It isn`t the type of conversation that I was looking
for.
I tried various times requesting the listserver to UNSUBSCRIBE me but no
luck.
So I have three options:
1.) Ask politely on the listserver newsgroup in how to get out.
2.) Be a complete ASSHOLE in my efforts and get kicked out.
3.) Hack into the listserver and then crash the whole listserver at
listproc at wugate.wustl.edu.
Received: from ietf.org by ietf.org id aa16613; 31 Oct 96 2:38 EST
Received: from ginger.lcs.mit.edu by ietf.org id aa16249; 31 Oct 96 2:33 EST
Received: by ginger.lcs.mit.edu
id AA09048; Thu, 31 Oct 96 02:31:47 -0500
Date: Thu, 31 Oct 96 02:31:47 -0500
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9610310731.AA09048 at ginger.lcs.mit.edu>
To: Valdis.Kletnieks at vt.edu, mohta at necom830.hpcl.titech.ac.jp
Subject: Re: The cartel begins to crumble?
Cc: ietf at ietf.org, jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
> Dealing with *any* non-native language can create a grammatical
> hodgepodge that the listener is unable to parse effectively(*).
Listener? It happens with e-mail discussion, after I realize the
attackers perfectly understand the technical points.
Well, in the IETF, I find that sometimes you get mass confusion even with
native English speakers trying to communicate! :-) Then again, there are times
there when the misunderstood thing is in crystal-clear English... :-(
Noel
Received: from ietf.org by ietf.org id aa25157; 31 Oct 96 9:54 EST
Received: from relay1.smtp.psi.net by ietf.org id aa24315; 31 Oct 96 9:42 EST
Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI)
id JAA18353; Thu, 31 Oct 1996 09:41:10 -0500
Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. )
id AA10279; Thu, 31 Oct 1996 09:41:18 -0500
Date: Thu, 31 Oct 1996 09:40:10 EST
Sender:ietf-request at ietf.org
From: Bob Natale <natale at acec.com>
Subject: Re: The cartel begins to crumble?
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at ietf.org
Message-Id: <ECS9610310910A at acec.com>
Priority: Normal
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
> Date: Thu, 31 Oct 96 02:31:47 -0500
Hi Noel,
I know a lot of us probably want to see this thread fade
away from this list, but your comment caused me to reflect...
> Well, in the IETF, I find that sometimes you get mass
> confusion even with native English speakers trying to
> communicate! :-) Then again, there are times there when
> the misunderstood thing is in crystal-clear English... :-(
Worse yet is when the participants have clearly heard
different interpretations of an ambiguous statement in
English and, nonetheless, walk away thinking that they
have come to agreement!
Cordially,,
BobN
------ ISO 9000 Registered, Hardware and Software Divsions -----
Bob Natale | ACE*COMM | 301-258-9850 [v]
Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f]
natale at acec.com | Gaithersburg MD 20877 | http://www.acec.com
---------- WinSNMP DLL, SDK, and Apps for Win16/Win32 ----------
------- NetPlus (r) "FCAPS" Telemanagement Applications --------
Received: from ietf.org by ietf.org id aa27243; 31 Oct 96 10:14 EST
Received: from localhost by ietf.org id aa25602; 31 Oct 96 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: urn-ietf at bunyip.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-urn-syntax-00.txt
Date: Thu, 31 Oct 1996 10:01:29 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610311001.aa25602 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 Uniform Resource Names
Working Group of the IETF.
Title : URN Syntax
Author(s) : R. Moats
Filename : draft-ietf-urn-syntax-00.txt
Pages : 5
Date : 10/30/1996
Uniform Resource Names (URNs) are intended to serve as persistent resource
identifiers. This document presents the syntax for URNs. Support for
existing legacy namespaces is discussed. URN transmission encoding
requirements are presented. Finally, there is a discussion of URN
equivalence and how to determine it.
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-urn-syntax-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-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-urn-syntax-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: <19961030141208.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-syntax-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-syntax-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030141208.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27246; 31 Oct 96 10:14 EST
Received: from localhost by ietf.org id aa25671; 31 Oct 96 10:01 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-ah-hmac-sha-03.txt
Date: Thu, 31 Oct 1996 10:01:47 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610311001.aa25671 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.
Note: This revision reflects comments received during the last call period.
Title : HMAC-SHA IP Authentication with Replay Prevention
Author(s) : S. Chang, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-sha-03.txt
Pages : 7
Date : 10/30/1996
This document describes a keyed-SHA transform to be used in conjunction
with the IP Authentication Header [RFC-1826]. The particular transform is
based on [HMAC-MD5]. An option is also specified to guard against replay
attacks.
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-ah-hmac-sha-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-sha-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-ietf-ipsec-ah-hmac-sha-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: <19961030150401.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-sha-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030150401.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27255; 31 Oct 96 10:14 EST
Received: from localhost by ietf.org id aa25706; 31 Oct 96 10:02 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.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-http-feature-reg-00.txt
Date: Thu, 31 Oct 1996 10:01:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610311002.aa25706 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 HyperText Transfer Protocol
Working Group of the IETF.
Title : Feature Tag Registration Procedures
Author(s) : K. Holtman, A. Mutz
Filename : draft-ietf-http-feature-reg-00.txt
Pages : 14
Date : 10/30/1996
The internet draft draft-holtman-http-negotiation-03.txt (Transparent
Content Negotiation in HTTP) specifies a `feature negotiation' mechanism
for negotiation on content characteristics other than MIME type, charset,
and language. Feature negotiation allows the quick introduction of new
dimensions of negotiation through the registration of `feature tags'. A
feature tag identifies a capability of a user agent or a preference of a
user.
This document discusses considerations related to feature tag registration,
and contains a proposed definition of a feature tag registration procedure.
Feature tag registration is foreseen as an ongoing, open process. It should
keep pace with the introduction of new rendering features by web software
vendors, and other parties such as standards bodies.
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-http-feature-reg-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-feature-reg-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-http-feature-reg-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: <19961030171131.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-feature-reg-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-feature-reg-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030171131.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27241; 31 Oct 96 10:14 EST
Received: from localhost by ietf.org id aa25637; 31 Oct 96 10:01 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-ietf-urn-naptr-00.txt
Date: Thu, 31 Oct 1996 10:01:38 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610311001.aa25637 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Resolution of Uniform Resource Identifiers using the
Domain Name System
Author(s) : R. Daniel, M. Mealling
Filename : draft-ietf-urn-naptr-00.txt
Pages : 12
Date : 10/30/1996
Uniform Resource Locators (URLs) are the foundation of the World Wide Web,
and are a vital Internet technology. However, they have proven to be
brittle in practice. The basic problem is that URLs typically identify a
particular path to a file on a particular host. There is no graceful way of
changing the path or host once the URL has been assigned. Neither is there
a graceful way of replicating the resource located by the URL to achieve
better network utilization and/or fault tolerance. Uniform Resource Names
(URNs) have been hypothesized as a adjunct to URLs that would overcome such
problems. URNs and URLs are both instances of a broader class of
identifiers known as Uniform Resource Identifiers (URIs).
This document describes a new DNS Resource Record, NAPTR (Naming Authority
PoinTeR), that provides rules for mapping parts of URIs to domain names.
By changing the mapping rules, we can change the host that is contacted to
resolve a URI. This will allow a more graceful handling of URLs over
long time periods, and forms the foundation for a new proposal
for Uniform Resource Names.
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-urn-naptr-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-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-urn-naptr-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: <19961030142240.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-naptr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-naptr-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030142240.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27238; 31 Oct 96 10:14 EST
Received: from localhost by ietf.org id aa25654; 31 Oct 96 10:01 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-ah-hmac-md5-03.txt
Date: Thu, 31 Oct 1996 10:01:43 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610311001.aa25654 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.
Note: This revision reflects comments received during the last call period.
Title : HMAC-MD5 IP Authentication with Replay Prevention
Author(s) : M. Oehler, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-md5-03.txt
Pages : 7
Date : 10/30/1996
This document describes a keyed-MD5 transform to be used in conjunction
with the IP Authentication Header [RFC-1826]. The particular transform is
based on [HMAC-MD5]. An option is also specified to guard against replay
attacks.
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-ah-hmac-md5-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-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-ietf-ipsec-ah-hmac-md5-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: <19961030145250.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-md5-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030145250.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27253; 31 Oct 96 10:14 EST
Received: from localhost by ietf.org id aa25619; 31 Oct 96 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.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-madman-alarmmib-01.txt
Date: Thu, 31 Oct 1996 10:01:33 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610311001.aa25619 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 Mail and Directory
Management Working Group of the IETF.
Title : Mail and Directory Alarms
Author(s) : G. Jones, N. Jain, G. Mansfield
Filename : draft-ietf-madman-alarmmib-01.txt
Pages : 13
Date : 10/30/1996
This document defines alarms for Mail and Directory usage. It is to be used
in conjunction with the Mail and Directory Management (MADMAN) RFCs.
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-madman-alarmmib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-madman-alarmmib-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-madman-alarmmib-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: <19961030114521.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-madman-alarmmib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-alarmmib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030114521.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa00203; 31 Oct 96 11:07 EST
Received: from mail1.texas.net by ietf.org id aa29826; 31 Oct 96 11:00 EST
Received: from dnet06-18.austin.texas.net (dnet06-18.austin.texas.net [206.127.25.146]) by mail1.texas.net (TxNet/Texas Net v1.2.2) with SMTP id JAA11618; Thu, 31 Oct 1996 09:59:00 -0600 (CST)
Message-ID: <3278E933.6A3B at texas.net>
Date: Thu, 31 Oct 1996 10:00:19 -0800
Sender:ietf-request at ietf.org
From: Tim Belding <tbelding at texas.net>
X-Mailer: Mozilla 2.01 (Win16; I)
MIME-Version: 1.0
To: "James E. [Jed] Donnelley" <jed at llnl.gov>
CC: ietf at ietf.org
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
References: <v03007856ae9d74d6cee9 at [128.115.96.72]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
James E. [Jed] Donnelley wrote:
>
> I have been following this discussion r.e. English and the
> IETF, but am at a loss to know what it might hope to
> achieve.
>
> There has been no debate in the discussion about whether
> English is the language of choice for IETF (and more
> generally scientific and international commerce) communication.
> It is.
>
> Are we trying to make it easier for people with weak English
> skills (perhaps because they are not native English speakers)
> to participate in the IETF? That seems a laudable goal.
> However, I haven't seen any discussion in this thread
> that directly addressed this goal.
>
> Hiring translators was mentioned, but I don't believe
> seriously. I certainly think it would not be worthwhile
> translating all the e-mail that flys by - it's value
> (this message included) is not sufficient to justify
> the costs. While I think translators at meetings can
> be handled on a case by case basis, I also don't think
> that more translators are generally justified. I
> certainly don't think it is worthwhile to go in the
> direction of the European Commission - any to any
> language translation.
>
> So then, other than deploring the sort of boorish behavior
> that Mr. Ohta mentioned (which English speaking people have
> perhaps a deserved reputation for, but by no means a
> monopoly position on), what do we have left? The issue
> of the location of the meetings? It seems to me that
> is dealt with on a case by case basis - though I am sure
> this language (or is it national?) neutrality
> aspect is a reasonable topic to come in the discussion
> of sites.
>
> --Jed http://www-atp.llnl.gov/atp/jed-signature.html
Maybe someone who has not been speaking English that long is starting to
like it better than their native language and it is making them hate
themselves. I don't see the value this discussion has to this mailing
list either.
Received: from ietf.org by ietf.org id aa04848; 31 Oct 96 12:14 EST
Received: from Kitten.mcs.com by ietf.org id aa04399; 31 Oct 96 12:09 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id LAA26146; Thu, 31 Oct 1996 11:08:00 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJ0az-000DPjC at mailbox.mcs.com>; Thu, 31 Oct 96 11:07 CST
Received: (from karl at localhost) by Mars.mcs.net (8.8.Beta.6/8.8.Beta.3) id LAA13911; Thu, 31 Oct 1996 11:07:56 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199610311707.LAA13911 at Mars.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Steve Bellovin <smb at research.att.com>
Date: Thu, 31 Oct 1996 11:07:56 -0600 (CST)
Cc: frezza at interramp.com, dcrocker at brandenburg.com, ietf at ietf.org,
namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
In-Reply-To: <199610302314.SAA03384 at smb.research.att.com> from "Steve Bellovin" at Oct 30, 96 06:06:40 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
>
> Dave Crocker writes:
>
> >You may have concerns over the current operation of IANA. You may
> >have specific changes in mind. But rest assured that the solution wi
>ll
> >require a central authority, if the solution is to be viable.
>
> HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
> Please describe how this central authority will compel people around
> the world to obey its edicts.
>
> This is indeed a problem. Unfortunately, it's one without an answer --
> *any* policy has to be accepted; none are enforceable. And please
> believe me that for technical reasons (which I'll be glad to spell
> out), the creation of alternate DNS roots *will* cause trouble, even
> for those who choose not to accept their authority.
>
>--Steve Bellovin
Why don't you spell out what you *believe* will cause trouble?
--
--
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
| 23 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 aa05673; 31 Oct 96 12:27 EST
Received: from ns.research.att.com by ietf.org id aa05527; 31 Oct 96 12:25 EST
Received: from research.att.com by ns; Thu Oct 31 12:23:05 EST 1996
Received: from raptor.research.att.com by research; Thu Oct 31 12:20:10 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 MAA24464; Thu, 31 Oct 1996 12:20:10 -0500 (EST)
Message-Id: <199610311720.MAA24464 at raptor.research.att.com>
To: Karl Denninger <karl at mcs.net>
cc: frezza at interramp.com, dcrocker at brandenburg.com, ietf at ietf.org,
namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Subject: Re: The cartel begins to crumble?
Date: Thu, 31 Oct 1996 12:20:09 -0500
Sender:ietf-request at ietf.org
From: Steven Bellovin <smb at research.att.com>
Source-Info: From (or Sender) name not authenticated.
> *any* policy has to be accepted; none are enforceable. And please
> believe me that for technical reasons (which I'll be glad to spell
> out), the creation of alternate DNS roots *will* cause trouble, even
> for those who choose not to accept their authority.
>
>--Steve Bellovin
Why don't you spell out what you *believe* will cause trouble?
Cache contamination, in particular of a host's knowledge of the
real (or, if you like, preferred) root servers. If a name server
sends you NS records for the root -- and this can happen -- a host
will believe them and cache them.
And yes, I'm speaking from experience.
Received: from cnri by ietf.org id aa08254; 31 Oct 96 13:10 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa16829;
31 Oct 96 13:10 EST
Received: by neptune.TIS.COM id aa21175; 31 Oct 96 12:33 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa17976;
31 Oct 96 11:11 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
MMDF-Warning: Parse error in original version of preceding line at
Message-ID: <9610311036.aa17969 at neptune.TIS.COM>
neptune.TIS.COM
cc: ipsec at TIS.COM
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt
Date: Thu, 31 Oct 1996 10:01:47 -0500
Message-ID: <9610311001.aa25671 at ietf.org>
Sender: ipsec-approval at neptune.tis.com
Precedence: bulk
--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.
Note: This revision reflects comments received during the last call period.
Title : HMAC-SHA IP Authentication with Replay Prevention
Author(s) : S. Chang, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-sha-03.txt
Pages : 7
Date : 10/30/1996
This document describes a keyed-SHA transform to be used in conjunction
with the IP Authentication Header [RFC-1826]. The particular transform is
based on [HMAC-MD5]. An option is also specified to guard against replay
attacks.
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-ah-hmac-sha-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-sha-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-ietf-ipsec-ah-hmac-sha-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: <19961030150401.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-sha-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030150401.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa10877; 31 Oct 96 13:25 EST
Received: from Kitten.mcs.com by ietf.org id aa10555; 31 Oct 96 13:22 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id MAA00971; Thu, 31 Oct 1996 12:21:24 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJ1k1-000DPFC at mailbox.mcs.com>; Thu, 31 Oct 96 12:21 CST
Received: (from karl at localhost) by Mars.mcs.net (8.8.Beta.6/8.8.Beta.3) id MAA15655; Thu, 31 Oct 1996 12:21:21 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199610311821.MAA15655 at Mars.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Steven Bellovin <smb at research.att.com>
Date: Thu, 31 Oct 1996 12:21:20 -0600 (CST)
Cc: karl at mcs.net, frezza at interramp.com, dcrocker at brandenburg.com,
ietf at ietf.org, namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
In-Reply-To: <199610311720.MAA24464 at raptor.research.att.com> from "Steven Bellovin" at Oct 31, 96 12:20:09 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> > *any* policy has to be accepted; none are enforceable. And please
> > believe me that for technical reasons (which I'll be glad to spell
> > out), the creation of alternate DNS roots *will* cause trouble, even
> > for those who choose not to accept their authority.
> >
> >--Steve Bellovin
>
> Why don't you spell out what you *believe* will cause trouble?
>
> Cache contamination, in particular of a host's knowledge of the
> real (or, if you like, preferred) root servers. If a name server
> sends you NS records for the root -- and this can happen -- a host
> will believe them and cache them.
>
> And yes, I'm speaking from experience.
"Contamination" can only occur if people do not synchronize the data in the
root.
The fact that a server is claiming to be authoritative for "." is only
harmful if the data in that server is different than that in the others.
If all but ten (the IANA roots) have the same data, and the reason the IANA
ones do not is because they REFUSE to admit the data that the others all
agree upon, who's "contaminated" and who's not?
Hmmm...
Cartel control only works if you can compel people to listen. The IANA is
rapidly losing that ability. This is a GOOD THING.
Nobody -- I repeat -- nobody -- is presuming to assign the same TLD to
multiple entities, EXCEPT the IANA -- which APPEARS, on the face, to be
reserving that "right".
If they actually DO this, I expect that the bottom line is that their root
servers will become irrelavent within days, as THEY will be the ones
"breaking the net".
--
--
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
| 23 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 aa11031; 31 Oct 96 13:27 EST
Received: from searn.sunet.se by ietf.org id aa10929; 31 Oct 96 13:26 EST
Received: from SEARN.SUNET.SE by SEARN.SUNET.SE (IBM VM SMTP V2R3)
with BSMTP id 5707; Thu, 31 Oct 96 19:22:37 +0200
Received: from SEARN.SUNET.SE (NJE origin ERIC at SEARN) by SEARN.SUNET.SE (LMail V1.2c/1.8c) with RFC822 id 0029; Thu, 31 Oct 1996 19:22:37 +0100
Date: Thu, 31 Oct 1996 19:03:36 +0100
Sender:ietf-request at ietf.org
From: Eric Thomas <ERIC at vm.se.lsoft.com>
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
To: ietf at ietf.org
In-Reply-To: Message of Thu, 31 Oct 1996 10:00:19 -0800 from
ietf-request at ietf.org
Message-ID: <9610311326.aa10929 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
This is not precisely a new problem, and I'm surprised that it has been
debated so long. FYI, over 10 years of experience with meetings where you
had a representative from just about every European country on the map
have taught me that:
1. There is no perfect solution to this problem.
2. There are a number of pretty good solutions to the problem.
3. Whatever you do, there will always be people who aren't happy and make
a fuss.
In a face to face meeting, the following rules and conventions will help
considerably:
1. The chairman may not be a native English speaker (if necessary, a
temporary chairman is appointed for the meeting). Native speakers tend
to talk faster than most non-native speakers can understand, and often
use idiomatic expressions that mean absolutely nothing to people with
a limited command of the English language. Worse, they have no idea
what the non-native listeners are going through - they don't know
which constructs of the English language are confusing to people for
whom it is a foreign language.
2. All native speakers will be required to speak slowly. Any native
speaker caught laughing at someone's accent will be required to repeat
an apology in a language that is foreign to him, while people are
allowed to laugh if the phonetic rendition is imperfect (this rarely
needs to be done, but is VERY effective :-) ).
3. A good chairman will make English mistakes on purpose (without telling
people that he is doing that). This makes the non-native speakers feel
more comfortable about speaking up ("Hey, even the chairman makes
mistakes, and nobody is laughing!") However, the chairman must speak
and understand English very well so that:
4. At the end of every long statement, the chairman makes a short summary
of what was said, for the benefit of the non-native speakers who may
not have the necessary vocabulary to understand the full discussion,
or who simply do not understand the speaker's accent. It works both
ways, when a non-native speaker says something that natives do not
understand, the chairman also summarizes. This also gives speakers a
chance to make sure that they were not totally misunderstood :-)
5. The chairman and attendees will show *reasonable* tolerance if one of
the attendees starts translating things for the benefit of people who
barely speak any English. One must strike a balance between allowing
the discussions to go on, and not ending up with a Babel syndrome. Any
reasonably large group will have people who can translate back and
forth, and it helps if the chairman speaks 3 or more languages.
6. There will however be NO group discussion in languages other than
English. Period.
This isn't really the end of the world. It's practical and about as
effective as you can get without having a dozen translators per attendees
like they do at the EC. Having a non-native chairman making English
mistakes is an inconvenience to the native speakers and gives them a
glimpse of what the rest of the audience is going through. This in turn
makes them more likely to make an effort and speak clearly. And FYI,
English was my third language; I'm afraid I didn't know a word of English
until I was 10.
Eric
Received: from cnri by ietf.org id aa11191; 31 Oct 96 13:31 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa17309;
31 Oct 96 13:31 EST
Received: by neptune.TIS.COM id aa21495; 31 Oct 96 12:37 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa17867;
31 Oct 96 11:09 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
MMDF-Warning: Parse error in original version of preceding line at
Message-ID: <9610311035.aa17853 at neptune.TIS.COM>
neptune.TIS.COM
cc: ipsec at TIS.COM
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-03.txt
Date: Thu, 31 Oct 1996 10:01:43 -0500
Message-ID: <9610311001.aa25654 at ietf.org>
Sender: ipsec-approval at neptune.tis.com
Precedence: bulk
--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.
Note: This revision reflects comments received during the last call period.
Title : HMAC-MD5 IP Authentication with Replay Prevention
Author(s) : M. Oehler, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-md5-03.txt
Pages : 7
Date : 10/30/1996
This document describes a keyed-MD5 transform to be used in conjunction
with the IP Authentication Header [RFC-1826]. The particular transform is
based on [HMAC-MD5]. An option is also specified to guard against replay
attacks.
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-ah-hmac-md5-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-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-ietf-ipsec-ah-hmac-md5-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: <19961030145250.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-md5-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030145250.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19718; 31 Oct 96 15:05 EST
Received: from coral.llnl.gov by ietf.org id aa15858; 31 Oct 96 14:58 EST
Received: from [128.115.96.72] (jedsmac.llnl.gov [128.115.96.72]) by coral.llnl.gov (8.7.5/8.7.3/LLNL-Jun96) with ESMTP id LAA14294 for <ietf at ietf.org>; Thu, 31 Oct 1996 11:57:05 -0800 (PST)
X-Sender: jed at coral.llnl.gov
Message-Id: <v03007877ae9eafcbdd5c at [128.115.96.72]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 31 Oct 1996 12:43:23 -0800
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "James E. [Jed] Donnelley" <jed at llnl.gov>
Subject: Folling the crumbling cartel - a note about thread following
Source-Info: From (or Sender) name not authenticated.
I have been following the various messages in the:
Re: The cartel begins to crumble?
with interest. The aspect I would like to comment on and
ask a question about here concerns the tools that we have
available to structure such communication. At a high level
I feel that the tools we have (todays e-mail) are very
poorly suited to carrying on such discussions. The tools
seem to me to contribute a great deal to the confusion
that often results and to the various forms of fragmentation
that occur.
In this note I am asking for pointers to any efforts to
develop better tools for this type of communication.
If you know of any such efforts, please point me at
them. In the rest of the note I use the "crumbling cartel"
discussion as an example to motivate how I would like to
see such tools improved. Please do not respond to this
note to the IETF mailing list (thanks).
The "cartel" discussion started, as I expect we all know, with
Bill Frezza's article:
http://techweb.cmp.com/cw/102896/635frez.htm
where he seems to suggest that central control of DNS
name registration is no longer needed (I certainly don't
want to get back into that issue - as it is continuing
on this list as I write).
Dave Crocker responded (quite effectively I thought)
on that specific topic to the list and we were off
to the races.
At one point the discussion split. One thread went off
on the topic of the use of English for IETF discussions.
While a topic moderately germane to the IETF, it was
certainly a distinct topic and was carried still under the
banner of "Re: The cartel begins to crumble?"
The usual tension began to build (I can feel it through
my keys) with some people not wanting to be bothered
with throwing away all the "cartel crumbling" e-mail and
others being interested to one degree or another in
one or the other of the particular subthreads.
So... Here is what I would like - the ability to:
1. Take a thread "offline" or perhaps more accurately off the
main thread. What I mean by this is that I would be able to send
or "post" something to a list noting the separating of a thread
from the list. At that point anyone could choose to follow the
thread or not. At any point they choose to follow it
they would get a dump of all the messages on that offline
thread since it was take out of the main list. They
would then be on the subthread and see any new postings
to the subthread (I use the prefix "sub" loosely here as
I presume someone could join the "sub" thread without
joining the originating thread). Once a thread was
split off, nobody on the spawning thread would see anything
more unless they choose to follow the subthread.
I think in some ways it might be nice to have such
"splitting" be automatic - namely, any responces to
a particular subject would not be sent to the list
unless somebody requested to see them. This is tied
up in the issue of having information delivered (e.g.
like mail) or requiring it to be sought (e.g. like
Web pages).
2. Designate a split thread topic. It seems to me
that it would be reasonable to combine this splitting
with taking a thread out of the main stream - though I
can see some motivations for keeping a distinct thread
still visible to the whole list.
I know that there are various arcane ways that
people have of trying to get some of the above
functionality by designating new "Subject:" fields
in e-mail ("Re:" being the simpliest and probably
having the most support). I certainly try that often
with little knowledge of what I am doing. I also
think this issue is tied inextricably with the
issue of managing who is on and off lists (i.e.
the "take me off the list" problem). I also have
seen netnews readers and e-mail readers that attempt
to help with this issue by following the subject
field. Do people feel that such reader support is
adequate to deal with this issue (and I am just unaware of
the best tools)? I don't and would like to find a
way to contribute to some better technology.
So... In the spirit of the above, I would NOT like
to discuss this on the IETF list. However, if you
have information to share on this topic -
particularly pointers to other places to discuss it,
please contact me.
Thanks.
--Jed http://www-atp.llnl.gov/atp/jed-signature.html
Received: from ietf.org by ietf.org id aa24682; 31 Oct 96 16:19 EST
Received: from gate.ups.com by ietf.org id aa24373; 31 Oct 96 16:12 EST
Received: by gate.ups.com id AA04245
(InterLock SMTP Gateway 3.0 for ietf at ietf.org);
Thu, 31 Oct 1996 16:11:36 -0500
Received: by gate.ups.com (Protected-side Proxy Mail Agent-1);
Thu, 31 Oct 1996 16:11:36 -0500
X-Orig-Sender: tel1stt at is.ups.com
Message-Id: <3279156D.17FA at is.ups.com>
Date: Thu, 31 Oct 1996 16:09:01 -0500
Sender:ietf-request at ietf.org
From: "Ted Takvorian (What? Come on guys ... What?)" <ted at is.ups.com>
Organization: United Parcel Service
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 i86pc)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: unsubscribe <ted at is.ups.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa29056; 31 Oct 96 17:58 EST
Received: from zephyr.isi.edu by ietf.org id aa28244; 31 Oct 96 17:47 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA08660>; Thu, 31 Oct 1996 14:46:00 -0800
Message-Id: <199610312246.AA08660 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2055 on WebNFS Server Specification
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 31 Oct 96 14:45:59 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 2055:
Title: WebNFS Server Specification
Author: B. Callaghan
Date: October 1996
Mailbox: brent.callaghan at eng.sun.com
Pages: 10
Characters: 20,498
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2055.txt
This document describes the specifications for a server of
WebNFS clients. WebNFS extends the semantics of versions 2
and 3 of the NFS protocols to allow clients to obtain
filehandles more easily, without recourse to the portmap or
MOUNT protocols. In removing the need for these protocols,
WebNFS clients see benefits in faster response to requests,
easy transit of firewalls and better server scalability This
description is provided to facilitate compatible
implementations of WebNFS servers.
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: <961031143852.RFC at ISI.EDU>
SEND /rfc/rfc2055.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2055.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961031143852.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29713; 31 Oct 96 18:04 EST
Received: from zephyr.isi.edu by ietf.org id aa29229; 31 Oct 96 18:00 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA09904>; Thu, 31 Oct 1996 14:59:04 -0800
Message-Id: <199610312259.AA09904 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2016 on Uniform Resource Agents
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 31 Oct 96 14:59:03 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 2016:
Title: Uniform Resource Agents (URAs)
Author: L. Daigle, P. Deutsch, B. Heelan,
C. Alpaugh, M. Maclachlan
Date: October 1996
Mailbox: ura-bunyip at bunyip.com
Pages: 21
Characters: 38,355
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2016.txt
This paper presents an experimental architecture for an agent system
that provides sophisticated Internet information access and
management. Not a generalized architecture for active objects that
roam the Internet, these agents are modeled as extensions of existing
pieces of the Internet information infrastructure. This experimental
agent technology focuses on the necessary information structures to
encapsulate Internet activities into objects that can be activated,
transformed, and combined into larger structured activities.
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: <961031145033.RFC at ISI.EDU>
SEND /rfc/rfc2016.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2016.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961031145033.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa00286; 31 Oct 96 18:09 EST
Received: from [206.86.127.224] by ietf.org id aa00083; 31 Oct 96 18:07 EST
Received: from [165.227.113.247] (phoffman.sc.scruznet.com [165.227.113.247]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id PAA26983; Thu, 31 Oct 1996 15:04:25 -0800 (PST)
X-Sender: paulh at mail.proper.com
Message-Id: <v03007812ae9ed80220b5 at [165.227.113.247]>
In-Reply-To: <199610311821.MAA15655 at Mars.mcs.net>
References: <199610311720.MAA24464 at raptor.research.att.com> from "Steven
Bellovin" at Oct 31, 96 12:20:09 pm
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 31 Oct 1996 15:06:40 -0800
To: Karl Denninger <karl at mcs.net>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Paul Hoffman <paulh at imc.org>
Subject: Re: The cartel begins to crumble?
Cc: frezza at interramp.com
Source-Info: From (or Sender) name not authenticated.
Karl Denninger said:
>Cartel control only works if you can compel people to listen. The IANA is
>rapidly losing that ability.
That's garbage, Karl. The writings of a few misguided pressoids looking for
a hot story do not indicate "rapidly losing".
>This is a GOOD THING.
For a small number of greedy people with short-term motives, yes, that
would be a good thing. For the rank and file Internet users, no.
Let's get real here. You (Karl) are claiming rights to sell subdomains of
".biz" on an experimental basis and are taking money from people right now;
other Alternic people are claiming similar rights to other well-named TLDs.
As a cooperating part of Alternic, you are being your own cartel. Gee,
thanks.
If I come along and say, "Ignore Karl, *I'm* selling subdomains of .biz and
you can use my DNS server", I can fool people into giving me money just as
easily as you can. And there might be two "mcdonalds.biz" domains, and mail
to "info at mcdonalds.biz" can go to either place based on which DNS server an
ISP happens to point to; same for Web accesses to "www.mcdonalds.biz".
You are advocating one of two things:
-- chaos, where two identical domain name resolution requests could resolve
very differently depending on which quasi-top an ISP points to (I claim
.biz, you claim .biz)
-- replacing IANA with a single other group that will administer ".". The
group you are advocating now, Alternic, has no significant track record of
fairness or technical skill.
Sorry, Karl, it's a big lie. This is a BAD THING with a few short-term wins
for a few greedy people and some cute sound bites in the press. It doesn't
scale: if you want .biz and I want .biz and ten other people will want
.biz; in fact, I can think of many people who want to be ".". As soon as
you have five competing "." services, you can kiss the usefulness of domain
names goodbye forever. That's incredibly harmful to everyone.
No one (well, almost no one) is thrilled about Network Solutions' monopoly,
but that doesn't mean we should try to ruin the whole system in response.
"Hand it all over to Alternic" is no more fair (and certainly less
technically sound) than "Let NSI run it forever"; both are bad. As you well
know from your long hard work with MCS, the Internet is a long-term
investment. Give IAHC a chance, or propose a better solution that is fair
to everyone and will scale in the long term. Otherwise, go back to what you
do best and stop trying to hurt the rest of us.
--Paul Hoffman
--Internet Mail Consortium
Received: from ietf.org by ietf.org id aa01969; 31 Oct 96 18:27 EST
Received: from Kitten.mcs.com by ietf.org id aa01898; 31 Oct 96 18:25 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id RAA17325; Thu, 31 Oct 1996 17:24:18 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJ6TB-000DOiC at mailbox.mcs.com>; Thu, 31 Oct 96 17:24 CST
Received: (from karl at localhost) by Mars.mcs.net (8.8.Beta.6/8.8.Beta.3) id RAA21892; Thu, 31 Oct 1996 17:24:16 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199610312324.RAA21892 at Mars.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Paul Hoffman <paulh at imc.org>
Date: Thu, 31 Oct 1996 17:24:16 -0600 (CST)
Cc: karl at mcs.net, ietf at ietf.org, frezza at interramp.com
In-Reply-To: <v03007812ae9ed80220b5 at [165.227.113.247]> from "Paul Hoffman" at Oct 31, 96 03:06:40 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
>
> Karl Denninger said:
> >Cartel control only works if you can compel people to listen. The IANA is
> >rapidly losing that ability.
>
> That's garbage, Karl. The writings of a few misguided pressoids looking for
> a hot story do not indicate "rapidly losing".
>
> >This is a GOOD THING.
>
> For a small number of greedy people with short-term motives, yes, that
> would be a good thing. For the rank and file Internet users, no.
>
> Let's get real here. You (Karl) are claiming rights to sell subdomains of
> ".biz" on an experimental basis and are taking money from people right now;
> other Alternic people are claiming similar rights to other well-named TLDs.
> As a cooperating part of Alternic, you are being your own cartel. Gee,
> thanks.
>
> If I come along and say, "Ignore Karl, *I'm* selling subdomains of .biz and
> you can use my DNS server", I can fool people into giving me money just as
> easily as you can. And there might be two "mcdonalds.biz" domains, and mail
> to "info at mcdonalds.biz" can go to either place based on which DNS server an
> ISP happens to point to; same for Web accesses to "www.mcdonalds.biz".
The second person who claims *ANY* TLD is the one to ignore.
Not the first.
NOBODY is advocating or condoning that.
Nobody.
Stop deliberately mischaracterizing what people are doing, and what they
say, and you'll have more credibility.
Until then, there's no point debating with you, as distortion is all I
see here.
--
--
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
| 23 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 aa02915; 31 Oct 96 18:44 EST
Received: from zephyr.isi.edu by ietf.org id aa02756; 31 Oct 96 18:40 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA14022>; Thu, 31 Oct 1996 15:39:46 -0800
Message-Id: <199610312339.AA14022 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2054 on WebNFS Client Specification
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 31 Oct 96 15:39:46 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 2054:
Title: WebNFS Client Specification
Author: B. Callaghan
Date: October 1996
Mailbox: brent.callaghan at eng.sun.com
Pages: 16
Characters: 36,354
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2054.txt
This document describes a lightweight binding mechanism that
allows NFS clients to obtain service from WebNFS-enabled
servers with a minimum of protocol overhead. In removing
this overhead, WebNFS clients see benefits in faster response
to requests, easy transit of packet filter firewalls and
TCP-based proxies, and better server scalability.
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: <961031153346.RFC at ISI.EDU>
SEND /rfc/rfc2054.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2054.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961031153346.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02931; 31 Oct 96 18:44 EST
Received: from SPECTRUM.RNS.COM by ietf.org id aa02845; 31 Oct 96 18:43 EST
Received: from anchor.rns.com by RNS.COM (SMI-8.6/SMI-4.1(Spectrum))
id PAA11636; Thu, 31 Oct 1996 15:34:18 -0800
Received: by anchor.rns.com (SMI-8.6/SMI-SVR4)
id PAA16676; Thu, 31 Oct 1996 15:42:11 -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: The cartel begins to crumble?
Date: 31 Oct 1996 15:42:09 -0800
Organization: RNS / Meret Communications
Lines: 34
Message-ID: <55bdgh$g8q at anchor.rns.com>
References: <199610302337.PAA10804 at server.livingston.com>
Source-Info: From (or Sender) name not authenticated.
In article <199610302337.PAA10804 at server.livingston.com> megazone at livingston.com (MegaZone) writes:
>I DO feel that we need new name space, it is damn crowded now. I think
>a .per domain (personal sites) would be useful, so many people have personal
>domains (Heck, I just applied for a .org for personal use). It would also
>be nices to have some differentiation between ISPs and corporations online.
>.com is already to fixed, maybe a new .isp and .cor TLDs.
The *.COM TLD is crowded, but only because everyone seems to want to
crowd into it ... probably exactly because it is so crowded. For people
and companies located in the USA, there is already an alternative tree
under the *.US TLD. This could be made even more useful by the addition
of a set of industry trees adjacent to the geographical (by state)
trees; how about:
*.<manufacturer>.AUTO.US
e.g. www.Chicago.Ford.Auto.US could hold a directory of
Ford dealers in that city.
<callsign>.RADIO.US
<callsign>.TV.US
e.g. www.WGBH.TV.US seems like the place to look for a
program schedule from the PBS affiliate in
Boston
*.NETWORK.US
e.g. ANS.NETWORK.US and NET-99.NETWORK.US are great
places to look for ISPs.
and BAY.NETWORK.US or ASCEND.NETWORK.US are well
known manufacturers.
Has IANA authorized anything other than state names under *.US yet ?
If not, why not ?
--
/ Lars PoulsenInternet E-mail: lars at RNS.COM
RNS / Meret CommunicationsPhone: +1-805-562-3158
7402 Hollister AvenueTelefax: +1-805-968-8256
Santa Barbara, CA 93117Internets: designed and built while you wait
Received: from ietf.org by ietf.org id aa03499; 31 Oct 96 18:51 EST
Received: from zephyr.isi.edu by ietf.org id aa03311; 31 Oct 96 18:48 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA14850>; Thu, 31 Oct 1996 15:47:41 -0800
Message-Id: <199610312347.AA14850 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2053 on The AM (Armenia) Domain
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 31 Oct 96 15:47:39 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 2053:
Title: The AM (Armenia) Domain
Author: E. Der-Danieliantz
Date: October 1996
Mailbox: edd at acm.org
Pages: 3
Characters: 4,128
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2053.txt
The AM Domain is an official Internet top-level domain of Armenia.
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: <961031154050.RFC at ISI.EDU>
SEND /rfc/rfc2053.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2053.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961031154050.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03720; 31 Oct 96 18:57 EST
Received: from zephyr.isi.edu by ietf.org id aa03568; 31 Oct 96 18:53 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA15111>; Thu, 31 Oct 1996 15:52:36 -0800
Message-Id: <199610312352.AA15111 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2052 on DNS SRV RR
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 31 Oct 96 15:52: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 2052:
Title: A DNS RR for specifying the location of services
(DNS SRV)
Author: A. Gulbrandsen, P. Vixie
Date: October 1996
Mailbox: agulbra at troll.no, paul at vix.com
Pages: 10
Characters: 19,257
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2052.txt
This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain (like a more general form
of MX).
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: <961031154913.RFC at ISI.EDU>
SEND /rfc/rfc2052.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2052.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961031154913.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05657; 31 Oct 96 19:18 EST
Received: from anvil.ry.com by ietf.org id aa05449; 31 Oct 96 19:17 EST
Received: from steve.ry.com (client26.ry.com [206.144.142.41]) by anvil.ry.com (8.7.5/8.7.3) with SMTP id SAA24286; Thu, 31 Oct 1996 18:16:02 -0600 (CST)
Message-Id: <3.0.32.19961031181820.00cd8be4 at mailhub.ry.com>
X-Sender: stevep at mailhub.ry.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 31 Oct 1996 18:18:21 -0600
To: Karl Denninger <karl at mcs.net>
Sender:ietf-request at ietf.org
From: Steve Peterson <stevep at ry.com>
Subject: Re: The cartel begins to crumble?
Cc: ietf at ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 05:24 PM 10/31/96 -0600, Karl Denninger wrote:
>The second person who claims *ANY* TLD is the one to ignore.
>
>Not the first.
>
>NOBODY is advocating or condoning that.
>
>Nobody.
>
OK, I'll bite. I hereby claim all TLDs that no one has yet registered with
either Alternic or IANA.
I can't do that? Why not?
--
Steve Peterson Reality Interactive,
Inc.
stevep at ry.com
--
Check out http://www.realtools.com for info on CD-ROM training for ISO 9000,
QS-9000 and ISO 14000.
--
Received: from ietf.org by ietf.org id aa07021; 31 Oct 96 19:38 EST
Received: from coral.llnl.gov by ietf.org id aa06852; 31 Oct 96 19:36 EST
Received: from [128.115.96.72] (jedsmac.llnl.gov [128.115.96.72]) by coral.llnl.gov (8.7.5/8.7.3/LLNL-Jun96) with ESMTP id QAA22749 for <ietf at ietf.org>; Thu, 31 Oct 1996 16:35:27 -0800 (PST)
X-Sender: jed at coral.llnl.gov
Message-Id: <v0300780aae9f015a0afd at [128.115.96.72]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 31 Oct 1996 17:37:30 -0800
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "James E. [Jed] Donnelley" <jed at llnl.gov>
Subject: Re: The cartel begins to crumble? - .com crowding
Source-Info: From (or Sender) name not authenticated.
Lars Poulsen <lars at anchor.rns.com> wrote:
>The *.COM TLD is crowded, but only because everyone seems to want to
>crowd into it ... probably exactly because it is so crowded.
I think this is about right. A specific angle on this is that
I (and I suspect I am not alone) often will try
www.<name>.com when looking for company <name> on the Web.
There was one point where this convention was even
encoded into the Netscape browser (type <name> into
the "Location" window and it would fill in http://www.<name>,com/).
Heck, I just tried it and it still works on my 3.0 version.
This convention works a surprisingly large fraction of the time...
I even find it useful sometimes to go to pages like:
http://www.zurich.ibm.com/wwwcomdirectory.html
(Watch out! - it is large). It is a listing of the
www.<name>.com space (filtered somehow) with links
to the WWW sites.
Currently .com is "the" place to be. This seems to me
to be a social phenomenon. If we want it to change
(why?) then it seems to me that we need to change some
of the surrounding social structure.
--Jed http://www-atp.llnl.gov/atp/jed-signature.html
Received: from ietf.org by ietf.org id aa07293; 31 Oct 96 19:41 EST
Received: from [206.86.127.224] by ietf.org id aa07218; 31 Oct 96 19:40 EST
Received: from [165.227.113.247] (phoffman.sc.scruznet.com [165.227.113.247]) by mail.proper.com (8.8.2/8.7.3) with ESMTP id QAA27755; Thu, 31 Oct 1996 16:36:48 -0800 (PST)
X-Sender: paulh at mail.proper.com
Message-Id: <v03007816ae9ef4b7df1b at [165.227.113.247]>
In-Reply-To: <199610312324.RAA21892 at Mars.mcs.net>
References: <v03007812ae9ed80220b5 at [165.227.113.247]> from "Paul Hoffman"
at Oct 31, 96 03:06:40 pm
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 31 Oct 1996 16:39:02 -0800
To: Karl Denninger <karl at mcs.net>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Paul Hoffman <paulh at imc.org>
Subject: Re: The cartel begins to crumble?
Cc: frezza at interramp.com
Source-Info: From (or Sender) name not authenticated.
Karl Denninger wrote:
>The second person who claims *ANY* TLD is the one to ignore.
So because you "claimed" .biz "first", you get it? And where did you
"claim" this? At Alternic? Well, I can say that I claimed it first at
Foonic, who also wants to be ".". And Vint can claim it first and MCInic
and so on and so on.
See the problem, Karl? What is to stop someone else from competing with
Alternic? What is to stop them from saying "We claim .biz"?
And, by the way, what is to stop an Alternic competitor from every once and
a while answering requests for resolution of "www.mcs.net" with an address
different from 205.164.8.12?
>Stop deliberately mischaracterizing what people are doing, and what they
>say, and you'll have more credibility.
Thank you for that advice. I tend to follow those who do as they say.
>Until then, there's no point debating with you, as distortion is all I
>see here.
Doesn't sound like debating was on your mind, anyways. Fair enough.
--Paul Hoffman
--Internet Mail Consortium
Received: from ietf.org by ietf.org id aa08754; 31 Oct 96 19:54 EST
Received: from slopok.roses.rockwell.com by ietf.org id aa08551;
31 Oct 96 19:52 EST
Received: by slopok.roses.rockwell.com (5.65/DEC-Ultrix/4.3)
id AA28455; Thu, 31 Oct 1996 16:51:25 -0800
Sender:ietf-request at ietf.org
From: "Mark A. Crother" <crotherm at roses.rockwell.com>
Message-Id: <9611010051.AA28455 at slopok.roses.rockwell.com>
Subject: Re: The cartel begins to crumble?
To: Karl Denninger <karl at mcs.net>
Date: Thu, 31 Oct 1996 16:51:25 +1600 (PST)
Cc: ietf at ietf.org, frezza at interramp.com
In-Reply-To: <199610312324.RAA21892 at Mars.mcs.net> from "Karl Denninger" at Oct 31, 96 05:24:16 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2264
Source-Info: From (or Sender) name not authenticated.
>
> >
> > Karl Denninger said:
> > >Cartel control only works if you can compel people to listen. The IANA is
> > >rapidly losing that ability.
> >
> > That's garbage, Karl. The writings of a few misguided pressoids looking for
> > a hot story do not indicate "rapidly losing".
> >
> > >This is a GOOD THING.
> >
> > For a small number of greedy people with short-term motives, yes, that
> > would be a good thing. For the rank and file Internet users, no.
> >
> > Let's get real here. You (Karl) are claiming rights to sell subdomains of
> > ".biz" on an experimental basis and are taking money from people right now;
> > other Alternic people are claiming similar rights to other well-named TLDs.
> > As a cooperating part of Alternic, you are being your own cartel. Gee,
> > thanks.
> >
> > If I come along and say, "Ignore Karl, *I'm* selling subdomains of .biz and
> > you can use my DNS server", I can fool people into giving me money just as
> > easily as you can. And there might be two "mcdonalds.biz" domains, and mail
> > to "info at mcdonalds.biz" can go to either place based on which DNS server an
> > ISP happens to point to; same for Web accesses to "www.mcdonalds.biz".
>
> The second person who claims *ANY* TLD is the one to ignore.
The point Paul was trying to make is that a method must exist to
absolutely determine who had it first. Just because I said so does not
work. That is why there MUST be ONE entity which controls "."
>
> Not the first.
>
> NOBODY is advocating or condoning that.
>
> Nobody.
>
> Stop deliberately mischaracterizing what people are doing, and what they
> say, and you'll have more credibility.
>
> Until then, there's no point debating with you, as distortion is all I
> see here.
That is really nice way to avoid discussion. IMHO I did not think Paul
was so far off base to consider his points invalid. They are genuine
concerns.
So the question remains, if, in your opinion, NSI is "crumbling", then
who should take over root?
>
> --
> --
> Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
--
Mark Crother crotherm at roses.rockwell.com
Rockwell's Operational Software Engineering System (ROSES)
Space Systems Division (SSD) All opinions are mine.
Received: from ietf.org by ietf.org id aa11915; 31 Oct 96 21:03 EST
Received: from Kitten.mcs.com by ietf.org id aa11775; 31 Oct 96 21:01 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id UAA24703; Thu, 31 Oct 1996 20:00:40 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJ8uT-000DPZC at mailbox.mcs.com>; Thu, 31 Oct 96 20:00 CST
Received: (from karl at localhost) by Mars.mcs.net (8.8.Beta.6/8.8.Beta.3) id UAA25842; Thu, 31 Oct 1996 20:00:36 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611010200.UAA25842 at Mars.mcs.net>
Subject: Re: The cartel begins to crumble?
To: "Mark A. Crother" <crotherm at roses.rockwell.com>
Date: Thu, 31 Oct 1996 20:00:36 +1800 (CST)
Cc: karl at mcs.net, ietf at ietf.org, frezza at interramp.com
In-Reply-To: <9611010051.AA28455 at slopok.roses.rockwell.com> from "Mark A. Crother" at Oct 31, 96 04:51:25 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> > The second person who claims *ANY* TLD is the one to ignore.
>
> The point Paul was trying to make is that a method must exist to
> absolutely determine who had it first. Just because I said so does not
> work. That is why there MUST be ONE entity which controls "."
There is. Its called public notice and *constructive* use.
The current projects to set up clusters of root servers all recognize this
to the best of my knowledge. I also believe it is obvious on the face
that this HAS to be the case with the only other possibility being a
monopoly (which we have seen is IMHO bad in the SLD namespaces). I believe
that it would be trivial to implement a simple "reservation" system for
TLDs with some basic operational rules to guarantee "FCFS".
I also believe that the cost to implement this is TRIVIAL (few thousand
dollars a year) and I'm even willing to host it (free) if that's what it
takes to get the job done.
Let's say we define it like this:
1)No more than 3 pending TLDs for an organization, no more than (say)
five TLD registrations from an organization in a 30 day period.
Affiliated (ie: significantly and operationally owned - 5% or more,
use SEC rules on what "operational influence" is) companies count.
2)Activation must be within 30 days of declaration of intent or the
name gets released back. Activation is defined as customers being
able to register under the domain with a published set of policies.
3)Beyond this, fight in court. (On the premise that courts generally
are expensive, its only worth it with a 2+ billion entry namespace
if someone has REALLY wronged you, and I believe in the rule of law
not dictators, self-important ones included.)
4)Prove fraud in the above and the offender gets removed entirely.
(ie: penalties for cheating people are so obscene nobody will
attempt it, and further, probably also passes legal scrutiny.
The process HAS TO BE fair, recognize first-use somehow since that's
what existing law is based on, and be reasonably-immune to abuse).
That prevents the "grab 8,000 entries" game, you have to be able to
actually register people within 30 days, there are no conflicts between
TLD root servers, and the rest people go to war over in the conventional
ways.
A minimalist philosophy towards the problem. And one which probably avoids
liability for the decisions (see above; I'm willing to host the server for
mutual exclusion, which means I don't think I can be successfully sued if
I implement this algorythm -- and since I'm known for being an asshole, the
odds of a frivolous suit are minimal -- I *DO* bite back when snapped at. :-)
> > Not the first.
> >
> > NOBODY is advocating or condoning that.
> >
> > Nobody.
> >
> > Stop deliberately mischaracterizing what people are doing, and what they
> > say, and you'll have more credibility.
> >
> > Until then, there's no point debating with you, as distortion is all I
> > see here.
>
> That is really nice way to avoid discussion. IMHO I did not think Paul
> was so far off base to consider his points invalid. They are genuine
> concerns.
The first rule of discussion and negotiation is that both parties must agree
not to deliberately misrepresentat their goals and the words of the other
parties involved. If you can't past that, you're dealing with people who
are irrational and unable to be negotiated with -- other than the way
you negotiate with someone who is holding a gun to your head -- that is,
try to find a way to kill them first if you're convinced the gun is real
and they're not going to give it up without being dead first (if you're
not convinced of this you're not being held up -- simple enough).
> So the question remains, if, in your opinion, NSI is "crumbling", then
> who should take over root?
I believe that the solution is for everyone to develop their own policies
for TLDs (just like we have for SLDs now) if you wish to be one of the
"authorities" for it, along with a dispute resolution procedure ("sue each
other" is good enough) *AND* an explicit agreement to honor FCFS on the
above (or something similar) guidelines.
I think we can get consensus on THOSE guidelines easily. The goals are
defined and nobody really has an interest in seeing them broken (you can't
exploit the process; there's nothing to be gained)
I have no interest in being a "root" registry, so I have no interest in this
at all. In fact, I believe this is a cost center all the way around (DNS
services).
But its a cost center I'm willing to bear, because I believe it HAS TO be
done and there are real problems with both how it works now and what people
have proposed as a "fix".
> > Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
>
> Mark Crother crotherm at roses.rockwell.com
--
--
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
| 23 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 aa12528; 31 Oct 96 21:17 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa12355;
31 Oct 96 21:15 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199611010213.LAA14678 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id LAA14678; Fri, 1 Nov 1996 11:13:00 +0900
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
To: Eric Thomas <ERIC at vm.se.lsoft.com>
Date: Fri, 1 Nov 96 11:12:58 JST
Cc: ietf at ietf.org
In-Reply-To: <9610311326.aa10929 at ietf.org>; from "Eric Thomas" at Oct 31, 96 7:03 pm
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
> This is not precisely a new problem, and I'm surprised that it has been
> debated so long. FYI, over 10 years of experience with meetings where you
> had a representative from just about every European country on the map
> have taught me that:
>
> 1. There is no perfect solution to this problem.
> 3. Whatever you do, there will always be people who aren't happy and make
> a fuss.
The problem is that IETF is behind other international activities
on the problem.
Moreover, rough consensus based way of decision making means to
ignore silent majority (or minority), which makes the problem
worse (this is *NOT* a proposal to have voting).
Finally, current US intensive membership of IETF and tendency of
some (hopefully not so many but...) people in US to think all
the world is like US make it difficult to solve the problem.
> 2. There are a number of pretty good solutions to the problem.
Sure. But, at least, certain number of us must recognize that
there is the problem.
> In a face to face meeting, the following rules and conventions will help
> considerably:
>
> 1. The chairman may not be a native English speaker (if necessary, a
> temporary chairman is appointed for the meeting).
That's a tradition seemingly used by IAB.
> Native speakers tend
> to talk faster than most non-native speakers can understand, and often
> use idiomatic expressions that mean absolutely nothing to people with
> a limited command of the English language.
That's what happening today.
> 2. All native speakers will be required to speak slowly.
Of course.
> 3. A good chairman will make English mistakes on purpose (without telling
> people that he is doing that). This makes the non-native speakers feel
> more comfortable about speaking up
Hmmmm. But, not-so-fluent non-native speakers can't notice the
mistakes, or, worse, can't resume the statement as well as native ones,
or, the worst, think the mistakes the correct way of using English and
use it later.
> 4. At the end of every long statement, the chairman makes a short summary
> of what was said, for the benefit of the non-native speakers who may
> not have the necessary vocabulary to understand the full discussion,
> or who simply do not understand the speaker's accent.
> 5. The chairman and attendees will show *reasonable* tolerance if one of
> the attendees starts translating things for the benefit of people who
> barely speak any English.
Sounds reasonable.
> 6. There will however be NO group discussion in languages other than
> English. Period.
Fine.
And, I'd like to propose one more.
7. Native users of English who complain trade language quality English
must hire translators at their own expense.
> This isn't really the end of the world. It's practical and about as
> effective as you can get without having a dozen translators per attendees
> like they do at the EC.
EC and ISO meetings should be working fine. Asian pacific meetings
are, too.
But, IETF meetings today, are not.
Masataka Ohta
Received: from ietf.org by ietf.org id aa22960; 31 Oct 96 23:32 EST
Received: from Kitten.mcs.com by ietf.org id aa22804; 31 Oct 96 23:28 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id WAA29950; Thu, 31 Oct 1996 22:27:11 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJBCH-000DPWC at mailbox.mcs.com>; Thu, 31 Oct 96 22:27 CST
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.Beta.3) id WAA16952; Thu, 31 Oct 1996 22:27:08 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611010427.WAA16952 at Jupiter.Mcs.Net>
Subject: Re: The cartel begins to crumble?
To: Steve Peterson <stevep at ry.com>
Date: Thu, 31 Oct 1996 22:27:08 +1800 (CST)
Cc: karl at mcs.net, ietf at ietf.org
In-Reply-To: <3.0.32.19961031181820.00cd8be4 at mailhub.ry.com> from "Steve Peterson" at Oct 31, 96 06:18:21 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> At 05:24 PM 10/31/96 -0600, Karl Denninger wrote:
> >The second person who claims *ANY* TLD is the one to ignore.
> >
> >Not the first.
> >
> >NOBODY is advocating or condoning that.
> >
> >Nobody.
> >
>
> OK, I'll bite. I hereby claim all TLDs that no one has yet registered with
> either Alternic or IANA.
>
> I can't do that? Why not?
> --
> Steve Peterson Reality Interactive,
> Inc.
More reduction to the absurd.
Sigh....
--
--
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
| 23 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 aa29124; 1 Nov 96 2:41 EST
Received: from dxmint.cern.ch by ietf.org id aa28845; 1 Nov 96 2:30 EST
Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch
with SMTP id IAA08657; Fri, 1 Nov 1996 08:29:33 +0100 (MET)
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM)
id AA16033; Fri, 1 Nov 1996 08:29:28 +0100
Message-Id: <9611010729.AA16033 at dxcoms.cern.ch>
Subject: Re: The cartel begins to crumble?
To: Steve Peterson <stevep at ry.com>
Date: Fri, 1 Nov 1996 08:29:28 +0100 (MET)
Sender:ietf-request at ietf.org
From: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
Cc: karl at mcs.net, ietf at ietf.org
In-Reply-To: <3.0.32.19961031181820.00cd8be4 at mailhub.ry.com> from "Steve Peterson" at Oct 31, 96 06:18:21 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 Steve Peterson follows:
...
> OK, I'll bite. I hereby claim all TLDs that no one has yet registered with
> either Alternic or IANA.
>
> I can't do that? Why not?
You can claim anything you want. I hereby claim that I'm the
Emperor Napoleon. Does that make it true?
Brian Carpenter
Received: from ietf.org by ietf.org id aa00006; 1 Nov 96 3:10 EST
Received: from songbird.com by ietf.org id aa29928; 1 Nov 96 3:08 EST
Received: (from kent at localhost) by songbird.com (8.7.4/8.7.3) id BAA20090; Fri, 1 Nov 1996 01:09:18 -0800
Sender:ietf-request at ietf.org
From: Kent Crispin <kent at songbird.com>
Message-Id: <199611010909.BAA20090 at songbird.com>
Subject: Re: The cartel begins to crumble?
To: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
Date: Fri, 1 Nov 1996 01:09:18 -0800 (PST)
Cc: ietf at ietf.org
In-Reply-To: <9611010729.AA16033 at dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Nov 1, 96 08:29:28 am
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Brian Carpenter CERN-CN allegedly said:
>
> >--------- Text sent by Steve Peterson follows:
> ...
> > OK, I'll bite. I hereby claim all TLDs that no one has yet registered with
> > either Alternic or IANA.
> >
> > I can't do that? Why not?
>
> You can claim anything you want. I hereby claim that I'm the
> Emperor Napoleon. Does that make it true?
>
> Brian Carpenter
That is, of course, exactly the point Steve was making...perhaps it
was a bit subtle...
--
Kent Crispin"No reason to get excited",
kent at songbird.com,kc at llnl.govthe thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
Received: from ietf.org by ietf.org id aa01028; 1 Nov 96 3:30 EST
Received: from eunet.EU.net by ietf.org id aa00953; 1 Nov 96 3:28 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 JAA03777; Fri, 1 Nov 1996 09:27:36 +0100 (MET)
Received: by jotun.EU.net id AA03580
(5.67a/IDA-1.5); Fri, 1 Nov 1996 09:27:35 +0100
Message-Id: <199611010827.AA03580 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <bilse at eu.net>
Date: Fri, 1 Nov 1996 09:27:34 +0100
In-Reply-To: <199610312324.RAA21892 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: The cartel begins to crumble?
Cc: ietf at ietf.org, frezza at interramp.com
Source-Info: From (or Sender) name not authenticated.
On Oct 31, 17:24, Karl Denninger <karl at mcs.net> wrote:
> The second person who claims *ANY* TLD is the one to ignore.
>
> Not the first.
Well, what are you doing messing with my domain, then? I
claimed .biz and several other potential TLDs over three
years ago:
On Sep 23, 10:10, Per Gregers Bilse <bilse at EU.net> wrote:
> From bilse Thu Sep 23 10:10:11 1993
> Received: by mcsun.EU.net with SMTP
> id AA03195 (5.65b/CWI-2.232); Thu, 23 Sep 1993 10:10:06 +0200
> Message-Id: <9309230810.AA03195 at mcsun.EU.net>
> From: Per Gregers Bilse <bilse at EU.net>
> Date: Thu, 23 Sep 1993 10:10:05 +0200
> Organization: EUnet NOC
> Sender: bilse at mcsun.EU.net
> X-Mailer: Mail User's Shell (7.2.2 4/12/91)
> To: hostmaster at mcsun.EU.net
> Subject: Claim for new TLDs
> Status: OR
>
> Dear hostmaster,
>
> In anticipation of liberalisation of TLD management in the
> future, I'd hereby like to claim all new TLDs that may be
> created. Of special interest is of course snappy and neat
> domains, like .inc, .ftp, .gopher, .biz, and ... uhh .. .sex,-)
> but I'd really like to claim all of them. Is this possible?
>
> Best regards,
>
> --
> bilse <bilse at EU.net> +31 20 592 5109 (dir: 5110); fax +31 20 592 5163
>
>-- End of excerpt from Per Gregers Bilse
On Sep 23, 10:34, hostmaster at mcsun.EU.net <hostmaster at mcsun.EU.net> wrote:
> From bilse Thu Sep 23 10:34:14 1993
> Received: by mcsun.EU.net with SMTP
> id AA03978 (5.65b/CWI-2.232); Thu, 23 Sep 1993 10:34:09 +0200
> Message-Id: <9309230834.AA03978 at mcsun.EU.net>
> From: hostmaster at mcsun.EU.net
> Date: Thu, 23 Sep 1993 10:34:08 +0200
> In-Reply-To: <9309230810.AA03195 at mcsun.EU.net>
> Organization: EUnet NOC
> Sender: bilse at mcsun.EU.net
> X-Mailer: Mail User's Shell (7.2.2 4/12/91)
> To: Per Gregers Bilse <bilse at EU.net>
> Subject: Re: Claim for new TLDs
> Status: OR
>
> On Sep 23, 10:10, Per Gregers Bilse <bilse at EU.net> wrote:
> > In anticipation of liberalisation of TLD management in the
> > future, I'd hereby like to claim all new TLDs that may be
> > created. Of special interest is of course snappy and neat
> > domains, like .inc, .ftp, .gopher, .biz, and ... uhh .. .sex,-)
> > but I'd really like to claim all of them. Is this possible?
>
> You can't claim any and all future domains just like that, but
> you can have the ones you mention no problem; noted in
> /documents/domain-claim on ns.EU.net, also visible via gopher
> and ftp. If you'd like to claim more TLDs, please get back to
> me with a list.
>
> Best regards,
>
> Hostmaster for the day,
>
> --
> bilse <bilse at EU.net> +31 20 592 5109 (dir: 5110); fax +31 20 592 5163
>
>-- End of excerpt from hostmaster at mcsun.EU.net
The domain-claim file is no longer on line.
I guess you'll blatantly state that the above email is fake,
and that no such claim was ever registered. What if I produce
a backup tape, proving I'm right?
--
------ ___ --- 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 aa01579; 1 Nov 96 3:37 EST
Received: from cnri by ietf.org id aa01495; 1 Nov 96 3:35 EST
Received: from mailhost01.primenet.com by CNRI.Reston.VA.US id aa04433;
1 Nov 96 3:35 EST
Received: from primenet.primenet.com (ip-20-126.phx.primenet.com [206.165.20.126]) by primenet.com (8.8.2/8.8.2) with SMTP id BAA29964 for <ietf at cnri.reston.va.us>; Fri, 1 Nov 1996 01:34:43 -0700 (MST)
Message-ID: <3279B51D.75CD at primenet.com>
Date: Fri, 01 Nov 1996 01:30:21 -0700
Sender:ietf-request at ietf.org
From: Stephen32 <vali32 at primenet.com>
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: ietf at CNRI.Reston.VA.US
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa03057; 1 Nov 96 4:15 EST
Received: from sigma.itu.ch by ietf.org id aa02975; 1 Nov 96 4:11 EST
Received: from MR.ITU.CH by ITU.CH (PMDF V5.0-6 #16074)
id <01IBBT77GY4G99G8TI at ITU.CH>; Fri, 01 Nov 1996 10:06:53 +0200
Received: with PMDF-MR; Fri, 01 Nov 1996 09:02:25 +0200
MR-Received: by mta TIES.MUAS; Relayed; Fri, 01 Nov 1996 09:02:25 +0200
MR-Received: by mta TAU; Relayed; Fri, 01 Nov 1996 09:02:30 +0200
Disclose-recipients: prohibited
Date: Fri, 01 Nov 1996 09:02:25 +0200
Sender:ietf-request at ietf.org
From: shaw <ROBERT.SHAW at itu.ch>
Subject: Re: The cartel begins to crumble?
In-reply-to: <199611010827.AA03580 at jotun.EU.net>
To: ietf <ietf at ietf.org>, Karl Denninger <karl at mcs.net>
Cc: Karl Denninger <karl at mcs.net>, frezza <frezza at interramp.com>,
bilse at eu.net
Message-id: <7825021001111996/A05718/TAU/11AB0A821700* at MHS>
Autoforwarded: false
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Importance: normal
Priority: normal
UA-content-id: 11AB0A821700
X400-MTS-identifier: [;7825021001111996/A05718/TAU]
Hop-count: 1
Source-Info: From (or Sender) name not authenticated.
>On Oct 31, 17:24, Karl Denninger <karl at mcs.net> wrote:
>> The second person who claims *ANY* TLD is the one to ignore.
>>
>> Not the first.
>
>Well, what are you doing messing with my domain, then? I
>claimed .biz and several other potential TLDs over three
>years ago:
>
OK, since we're all having so much fun, here's another claim.
The Bank fur Internationalen Zahlungsausgleich (BIZ) (in English
that's the Bank for International Settlements) has trademarked
'biz' in 10 countries for 20 years including in the classes for
telecommunications and computer programming services. Trademark
registration number 418611 through the World Intellectual Property
Organization (WIPO).
;-)
Robert
ITU
Received: from ietf.org by ietf.org id aa03682; 1 Nov 96 4:29 EST
Received: from Hugin.mainz.dk by ietf.org id aa03573; 1 Nov 96 4:28 EST
Date: Fri, 01 Nov 1996 10:34:46 +0100
Sender:ietf-request at ietf.org
From: Kim Wohlert <Kim.Wohlert at mainz.dk>
Subject: RE: The cartel begins to crumble?
To: 'Karl Denninger' <karl at mcs.net>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>,
"'frezza at interramp.com'" <frezza at interramp.com>
Message-id: <c=DK%a=_%p=MAINZ%l=MOONRAKER-961101093446Z-992 at Moonraker.mainz.dk>
MIME-version: 1.0
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
On Thursday, 31 October, 1996 21:00, Karl Denninger[SMTP:karl at mcs.net]
wrote:
<snip>
>
> >I also believe that the cost to implement this is TRIVIAL (few thousand
> >dollars a year) and I'm even willing to host it (free) if that's what it
> >takes to get the job done.
> >
Doesn't that make YOU the cartel?
> >Let's say we define it like this:
> >
> >1)No more than 3 pending TLDs for an organization, no more than (say)
> >five TLD registrations from an organization in a 30 day period.
> >Affiliated (ie: significantly and operationally owned - 5% or more,
> >use SEC rules on what "operational influence" is) companies count.
As far as I am concerned, SEC is a US 'thing' that has absolutely no
merit internationally, so you can't use those rules.
Every nation will have its own definitions of "company", "operations
influence" etc.
> >2)Activation must be within 30 days of declaration of intent or the
> >name gets released back. Activation is defined as customers being
> >able to register under the domain with a published set of policies.
Who will police that? You?
> >3)Beyond this, fight in court. (On the premise that courts generally
> >are expensive, its only worth it with a 2+ billion entry namespace
> >if someone has REALLY wronged you, and I believe in the rule of law
> >not dictators, self-important ones included.)
What court/law? US?, California?, Armenia?, Bahamas? (continue the list
youself)
> >4)Prove fraud in the above and the offender gets removed entirely.
> >(ie: penalties for cheating people are so obscene nobody will
> >attempt it, and further, probably also passes legal scrutiny.
> >The process HAS TO BE fair, recognize first-use somehow since that's
> >what existing law is based on, and be reasonably-immune to abuse).
Prove to whom? By what definition of fraud? And who gets to remove the
offender? You?
> >
> >A minimalist philosophy towards the problem.
No, a nationalist.
> >
> >I believe that the solution is for everyone to develop their own policies
> >for TLDs (just like we have for SLDs now) if you wish to be one of the
> >"authorities" for it, along with a dispute resolution procedure ("sue each
> >other" is good enough) *AND* an explicit agreement to honor FCFS on the
> >above (or something similar) guidelines.
But if you want FCFS, someone has to decide what 'First' is? So in
effect you are replacing one cartel with another - where is the benefit?
>
>- Kim
--
Kim Wohlert |Internet:Kim.Wohlert at mainz.dk
erik mainz a/s |
Dortheavej 7 |
DK-2400 Copenhagen |Phone: +45 38 34 77 88
Denmark |Fax: +45 31 19 16 25
---
"Enough about me, lets talk about you. What do you think of me?"
Received: from ietf.org by ietf.org id aa01968; 1 Nov 96 8:46 EST
Received: from thunder.ncr.disa.mil by ietf.org id aa01325; 1 Nov 96 8:27 EST
Received: from ncr.disa.mil ([164.117.176.106]) by thunder.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id IAA02539; Fri, 1 Nov 1996 08:11:56 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA846865527; Fri, 01 Nov 96 08:22:44 EST
Date: Fri, 01 Nov 96 08:22:44 EST
Sender:ietf-request at ietf.org
From: David Gaon <gaond at ncr.disa.mil>
Message-Id: <9610018468.AA846865527 at ncr.disa.mil>
To: ietf at ietf.org, Lars Poulsen <lars at anchor.rns.com>
Subject: Re[2]: The cartel begins to crumble?
Source-Info: From (or Sender) name not authenticated.
Although the .US is available, US entities and IANA have not enforced
it. Instead, they have created international or global TLDs (.com,
.edu, ...) and, as expected, allowed registration willy-nilly without
regards to nationality.
Although creating TLDs under the .US (and hopefully eliminating the
global TLDs) will solve some of the problems with crowding of TLDs, it
will not solve the copyright/trademark issue. This means that
companies like IBM will register in multiple domains simply to
safeguard their copyright, and there will be contention by others for
the use of .IBM.US
Thus, the creation of TLDs perpetuates the problems rather than solve
them.
It appears to me that the simple solution is the creation of
dsitributed directories.
With the use of Directories, individuals can get a listing of all
entities they wish to address that have IBM as 3 letters in their call
sign or as the mnemonic of their name. The user will then selects the
entry of the entity he wishes to contact and uses the corresponding
network address for their mail, web, voice, fax, .... other services
as they come along. He clearly does not have to retype anything, just
click and go. He also has the option to store that infomration on his
own machine for future use, which obviates the need for another
Directory ping (saves $$$).
It really is very simple and an enterprising company can make a
handsome profit on it as well.
What if IANA, ATT, or Joe Schmoe Directory Service do the following:
- create distributed directories located strategically
- for a fee (I estimate $5.00) publish on CD all the addressable port
numbers they know of (voice, data, video, ...). The information is
public knowledge, already in electronic form, and needs to be
formatted in the directory database
- the user would buy a directory utility(user agent) to run on his PC
(I estimate $30.00) from the likes of Microsoft. The user agent may
even be embedded and given free in the operating system.
The technology is there (X.500), so it is not rocket science.
I am surprised Microsoft has not done that already.
Cheers
David Gaon
DoD/DISA/Center for Standards
______________________________ Reply Separator _________________________________
Subject: Re: The cartel begins to crumble?
Author: Lars Poulsen <lars at anchor.rns.com> at smtp
Date: 10/31/96 7:05 PM
In article <199610302337.PAA10804 at server.livingston.com> megazone at livingston.com
(MegaZone) writes:
>I DO feel that we need new name space, it is damn crowded now. I think
>a .per domain (personal sites) would be useful, so many people have personal
>domains (Heck, I just applied for a .org for personal use). It would also
>be nices to have some differentiation between ISPs and corporations online.
>.com is already to fixed, maybe a new .isp and .cor TLDs.
The *.COM TLD is crowded, but only because everyone seems to want to
crowd into it ... probably exactly because it is so crowded. For people
and companies located in the USA, there is already an alternative tree
under the *.US TLD. This could be made even more useful by the addition
of a set of industry trees adjacent to the geographical (by state)
trees; how about:
*.<manufacturer>.AUTO.US
e.g. www.Chicago.Ford.Auto.US could hold a directory of
Ford dealers in that city.
<callsign>.RADIO.US
<callsign>.TV.US
e.g. www.WGBH.TV.US seems like the place to look for a
program schedule from the PBS affiliate in
Boston
*.NETWORK.US
e.g. ANS.NETWORK.US and NET-99.NETWORK.US are great
places to look for ISPs.
and BAY.NETWORK.US or ASCEND.NETWORK.US are well
known manufacturers.
Has IANA authorized anything other than state names under *.US yet ?
If not, why not ?
--
/ Lars Poulsen Internet E-mail: lars at RNS.COM
RNS / Meret Communications Phone: +1-805-562-3158
7402 Hollister Avenue Telefax: +1-805-968-8256
Santa Barbara, CA 93117 Internets: designed and built while you wait
Received: from ietf.org by ietf.org id aa05071; 1 Nov 96 9:45 EST
Received: from localhost by ietf.org id aa03454; 1 Nov 96 9:27 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-hernacki-nntpsrch-01.txt
Date: Fri, 01 Nov 1996 09:27:39 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611010927.aa03454 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : NNTP Full-text Search Enhancements
Author(s) : B. Hernacki, B. Polk
Filename : draft-hernacki-nntpsrch-01.txt
Pages : 15
Date : 10/31/1996
This document describes a set of enhancements to the Network News Transport
Protocol [NNTP-977] that allows full-text searching of news articles across
multiple newsgroups.
This new search mechanism also allows search criteria to be saved into
search profiles. Articles arriving on the server are checked against the
profiles, and the articles that match are collected together for the client.
The availability of the extensions described here will be advertised by the
server using the extension negotiation-mechanism described in the new NNTP
protocol specification currently being developed [NNTP-NEW].
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-hernacki-nntpsrch-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hernacki-nntpsrch-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-hernacki-nntpsrch-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: <19961031151159.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hernacki-nntpsrch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hernacki-nntpsrch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961031151159.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05086; 1 Nov 96 9:45 EST
Received: from localhost by ietf.org id aa03470; 1 Nov 96 9:27 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-eastlake-muse-01.txt
Date: Fri, 01 Nov 1996 09:27:43 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611010927.aa03470 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Mail Ubiquitous Security Extensions (MUSE)
Author(s) : D. Eastlake
Filename : draft-eastlake-muse-01.txt
Pages : 20
Date : 10/31/1996
Secure electronic mail can provide authentication of the source of mail and
confidentiality for its contents. These features are becoming increasingly
important as the Internet grows exponentially and email is increasingly
used for critical, sensitive, and confidential communications.
However, use of secure mail is not widespread due to the problems of key
distribution and lack of migration to secure mail enabled user agents.
This draft proposes partial solutions to these two problems by using
coarser grained identity to permit authentication and confidentiality
without user agent change, and DNS security for key distribution.
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-eastlake-muse-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-eastlake-muse-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-eastlake-muse-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: <19961031162257.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-eastlake-muse-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-eastlake-muse-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961031162257.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06790; 1 Nov 96 10:06 EST
Received: from doorstep.unety.net by ietf.org id aa06577; 1 Nov 96 10:03 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 IAA26992; Fri, 1 Nov 1996 08:58:08 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC7D3.03A82A40 at webster.unety.net>; Fri, 1 Nov 1996 08:59:39 -0600
Message-ID: <01BBC7D3.03A82A40 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>,
"James E. [Jed] Donnelley" <jed at llnl.gov>,
'Phil Karn' <karn at qualcomm.com>
Subject: RE: Folling the crumbling cartel - a note about thread following
Date: Fri, 1 Nov 1996 08:59:38 -0600
Encoding: 231 TEXT
Source-Info: From (or Sender) name not authenticated.
On Tuesday, October 29, 1996 10:26 PM, Phil Karn[SMTP:karn at qualcomm.com] wrote:
@ >The "cartel" discussion started, as I expect we all know, with
@ >Bill
@ Frezza's article:
@
@ Bill Frezza appears to be a journalistic gadfly who specializes in attacking
@ large, successful technology organizations. He has written a series of
@ articles
@ attacking Qualcomm CDMA that, in my opinion, are best characterized as
@ "vicious",
@ as opposed to merely "uninformed" or "muckraking".
@
@ He is best not taken too seriously.
@
@ Phil
@@@@@@@@@@@@@@@
Dear Phil...we have all come a long way...in a short time...
I hope that you take this work seriously....
JF
@@@@@@@@@@@@@@@
Saturday, October 26, 1996
Root-64 Weekly Status Report
Several people have expressed interest in some sort of weekly summary.
This will help busy people get an overview of the progress being made
without getting involved in the daily discussions.
This past week was very busy, the NSF and the FNC (Federal Networking
Council) met and based on the early reports from that meeting, the FNC
is recommending that the NSF work hard to divest itself from the top level
domain issues and the management of the popular root name servers.
Hopefully, the NSF will see that projects like the Root-64 Project will help
accelerate this process.
Attached is the growing list of root name servers which are being deployed
around the world. This list helps to illustrate that the commercial world as
well as non profit organizations are willing to step in as the NSF and the
U.S. Government withdraw support. Additional root name servers will provide
the stability needed to grow the Internet beyond the current R&D architecture
supported by the NSF.
As shown below, the major recent changes are:
England:
Keith Mitchell - keith at linx.org has expressed interest in the project
and appears to have a very strategic location and facilties in the U.K.
to provide support for not only the U.K. but surrounding regions.
France:
Laurent BERNARD - lbernard at artinternet.fr is very enthusiastic
about getting involved from his Paris based ISP. He has volunteered
to help develop a root DNS FAQ, which hopefully may also be
available in French.
Australia:
Andrew Khoo - andrew at aussie.net has indicated that his
management is supportive of the project and would like more
information to help them bring a root name server to Australia.
ISOC/IAHC:
The Internet Society, under Don Heath's (heath at linus.isoc.org)
direction, is starting to make progress. They have appointed
a committee to discuss all of the issues of the top level domains.
Only one of the members of the committee, Perry Metzger, was
active in the "newdom" discussions this past year. It is still not
clear if they intend to host a root name server. That may be one
of the topics that their committee discusses. It is still too early to
tell.
@@@@@
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 -
3 - Jeff Houston
4 - Hank Nusbacher
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 - ???
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 -
@@@@
A variety of people are starting to write software, scripts, documentation,
etc. that will be needed to coordinate the updates for all of the root name
servers. For people that want a Java view of the servers, the temporary
web site, http://www.unety.net/Java/root.html has a demo.
Chris Sevcik - chris at sparknet.net has been exploring some interesting
ideas about a web sites, etc. Chris has pointed out the need for a web
site that helps document who the contacts are for the above root name
servers.
Alexis Yushin - alexis at dawn.ww.net of Ukraine has expressed interest
in moving the discussion forward on the technology needed to keep the
world wide collection of root name servers in synch. I would encourage
everyone to work with Alexis on these important projects.
John Palmer - newdom at Taka.AGN.NET reported that their "whois"
database is up and working for the .EARTH and .USA top level domains.
John provided both URLs as just another example of how the new TLDs
can coexist with the "popular" TLDs.
http://www.earth/whois.html
http://www.agn.net/whois.html
Peter deBlanc -pdeblanc at usvi.net reports that he is making good
progress in Venezula and hopes to have some news in early November.
South America is clearly an area where more progress is needed. If
anyone wants to explore those regions, cruise on down there.
The NANOG group met in Ann Arbor this week. I did receive a response
from them, but I do not anticipate any news until the results of their
meetings are digested.
The operator of the OLD newdom mailing list has suggested closing
the list. Several of the members of that list have now subscribed to
the NEW newdom list. Richard J. Sexton, the operator of the new
list wants to remind everyone that there is a web site for people to
subscribe. Please circultate this URL <http://www.newdom.com/lists/>.
On the International front, there are meetings next week in Geneva,
Switzerland. Stay tuned to the following web site for more info
http://www.wia.org
It should be clear from that web site that many stakeholders are now
involved in the Internet, and some of them will want to take part in
helping to provide stability via the deployment of root name servers.
Stay tuned for next week's report...inputs are welcome...;-)
P.S. As far as I know, none of the above work was funded by the NSF,
or the U.S. government. All of the work is being done by private citizens
and companies who volunteer their time and resources to these efforts.
--
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 aa07147; 1 Nov 96 10:13 EST
Received: from doorstep.unety.net by ietf.org id aa07019; 1 Nov 96 10: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 JAA27040; Fri, 1 Nov 1996 09:07:18 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC7D4.4C698AC0 at webster.unety.net>; Fri, 1 Nov 1996 09:08:51 -0600
Message-ID: <01BBC7D4.4C698AC0 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>,
"James E. [Jed] Donnelley" <jed at llnl.gov>,
'Phil Karn' <karn at qualcomm.com>
Cc: 'New Newdom' <newdom at vrx.net>
Subject: Serious Business
Date: Fri, 1 Nov 1996 09:08:49 -0600
Encoding: 76 TEXT
Source-Info: From (or Sender) name not authenticated.
On Tuesday, October 29, 1996 10:26 PM, Phil Karn[SMTP:karn at qualcomm.com] wrote:
@ >The "cartel" discussion started, as I expect we all know, with
@ >Bill
@ Frezza's article:
@
@ Bill Frezza appears to be a journalistic gadfly who specializes in attacking
@ large, successful technology organizations. He has written a series of
@ articles
@ attacking Qualcomm CDMA that, in my opinion, are best characterized as
@ "vicious",
@ as opposed to merely "uninformed" or "muckraking".
@
@ He is best not taken too seriously.
@
@ Phil
@
@@@@@@@
Dear Phil,
I also hope that you take this statement from Paul Vixie...
...."seriously"...
...this is all very serious business...and just think, much of
it started out right there in the E Aisle in Building 6...
...not long ago...(in Earth years)....;-)
JF
@@@@@@@
----------
From:Paul A Vixie[SMTP:paul at vix.com]
Sent:Thursday, October 31, 1996 12:56 PM
To:newdom at vrx.net
Subject:requirements for participation
I have told the IANA and I have told InterNIC -- now I'll tell you kind folks.
If IANA's proposal stagnates past January 15, 1997, without obvious progress
and actual registries being licensed or in the process of being licensed, I
will declare the cause lost. At that point it will be up to a consortium of
Internet providers, probably through CIX if I can convince them to take up
this cause, to tell me what I ought to put into the "root.cache" file that I
ship with BIND.
I am willing to wait for the lawyers to do what they think is necessary but
I am only willing to wait *so*long*. At some point it will become necessary
for the people who own the majority of the fabric to decide what names should
be available to their customers.
I do not expect "root-64" or Alternic et al to be any more relevant then, than
it is now. A thing badly begun is *very* hard to repair later. You guys are
just rabble in my opinion, and I do not think that your efforts will sway the
people I intend to listen to.
But there are limits to my support for the now-ISOC process. Now you know.
Oh, and one more thing: I'm not in the registry business and won't ever be.
I might charge folks to write software to help run registries but I won't
ever collect any money in exchange for registering a name. If the Internet
Software Consortium decided to get funding in exchange for names, I would
cease all projects funded by ISC grants. I am **NOT** in this for the money.
@@@@@
--
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 aa07195; 1 Nov 96 10:14 EST
Received: from Kitten.mcs.com by ietf.org id aa07094; 1 Nov 96 10:13 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id JAA18373; Fri, 1 Nov 1996 09:12:38 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJLGu-000DPWC at mailbox.mcs.com>; Fri, 1 Nov 96 09:12 CST
Received: (from karl at localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id JAA06591; Fri, 1 Nov 1996 09:12:36 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611011512.JAA06591 at Mercury.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Per Gregers Bilse <bilse at eu.net>
Date: Fri, 1 Nov 1996 09:12:36 -0600 (CST)
Cc: karl at mcs.net, ietf at ietf.org, frezza at interramp.com
In-Reply-To: <199611010827.AA03580 at jotun.EU.net> from "Per Gregers Bilse" at Nov 1, 96 09:27:34 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Operational registries Per Gregers, nothing more or less.
We have it (and had it first), you did not.
I can declare myself emporer of the known universe, but unless I do
something to demonstrate that I'm serious (ie: find a way to actually govern
and enforce it across every person on the planet) all I get is laughed at.
--
--
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
| 23 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
> On Oct 31, 17:24, Karl Denninger <karl at mcs.net> wrote:
> > The second person who claims *ANY* TLD is the one to ignore.
> >
> > Not the first.
>
> Well, what are you doing messing with my domain, then? I
> claimed .biz and several other potential TLDs over three
> years ago:
>
> On Sep 23, 10:10, Per Gregers Bilse <bilse at EU.net> wrote:
> > From bilse Thu Sep 23 10:10:11 1993
> > Received: by mcsun.EU.net with SMTP
> > id AA03195 (5.65b/CWI-2.232); Thu, 23 Sep 1993 10:10:06 +0200
> > Message-Id: <9309230810.AA03195 at mcsun.EU.net>
> > From: Per Gregers Bilse <bilse at EU.net>
> > Date: Thu, 23 Sep 1993 10:10:05 +0200
> > Organization: EUnet NOC
> > Sender: bilse at mcsun.EU.net
> > X-Mailer: Mail User's Shell (7.2.2 4/12/91)
> > To: hostmaster at mcsun.EU.net
> > Subject: Claim for new TLDs
> > Status: OR
> >
> > Dear hostmaster,
> >
> > In anticipation of liberalisation of TLD management in the
> > future, I'd hereby like to claim all new TLDs that may be
> > created. Of special interest is of course snappy and neat
> > domains, like .inc, .ftp, .gopher, .biz, and ... uhh .. .sex,-)
> > but I'd really like to claim all of them. Is this possible?
> >
> > Best regards,
> >
> > --
> > bilse <bilse at EU.net> +31 20 592 5109 (dir: 5110); fax +31 20 592 5163
> >
> >-- End of excerpt from Per Gregers Bilse
>
>
> On Sep 23, 10:34, hostmaster at mcsun.EU.net <hostmaster at mcsun.EU.net> wrote:
> > From bilse Thu Sep 23 10:34:14 1993
> > Received: by mcsun.EU.net with SMTP
> > id AA03978 (5.65b/CWI-2.232); Thu, 23 Sep 1993 10:34:09 +0200
> > Message-Id: <9309230834.AA03978 at mcsun.EU.net>
> > From: hostmaster at mcsun.EU.net
> > Date: Thu, 23 Sep 1993 10:34:08 +0200
> > In-Reply-To: <9309230810.AA03195 at mcsun.EU.net>
> > Organization: EUnet NOC
> > Sender: bilse at mcsun.EU.net
> > X-Mailer: Mail User's Shell (7.2.2 4/12/91)
> > To: Per Gregers Bilse <bilse at EU.net>
> > Subject: Re: Claim for new TLDs
> > Status: OR
> >
> > On Sep 23, 10:10, Per Gregers Bilse <bilse at EU.net> wrote:
> > > In anticipation of liberalisation of TLD management in the
> > > future, I'd hereby like to claim all new TLDs that may be
> > > created. Of special interest is of course snappy and neat
> > > domains, like .inc, .ftp, .gopher, .biz, and ... uhh .. .sex,-)
> > > but I'd really like to claim all of them. Is this possible?
> >
> > You can't claim any and all future domains just like that, but
> > you can have the ones you mention no problem; noted in
> > /documents/domain-claim on ns.EU.net, also visible via gopher
> > and ftp. If you'd like to claim more TLDs, please get back to
> > me with a list.
> >
> > Best regards,
> >
> > Hostmaster for the day,
> >
> > --
> > bilse <bilse at EU.net> +31 20 592 5109 (dir: 5110); fax +31 20 592 5163
> >
> >-- End of excerpt from hostmaster at mcsun.EU.net
>
>
> The domain-claim file is no longer on line.
>
> I guess you'll blatantly state that the above email is fake,
> and that no such claim was ever registered. What if I produce
> a backup tape, proving I'm right?
>
> --
> ------ ___ --- 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 aa07591; 1 Nov 96 10:20 EST
Received: from Kitten.mcs.com by ietf.org id aa07481; 1 Nov 96 10:19 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id JAA18670; Fri, 1 Nov 1996 09:17:51 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJLLx-000DNbC at mailbox.mcs.com>; Fri, 1 Nov 96 09:17 CST
Received: (from karl at localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id JAA08564; Fri, 1 Nov 1996 09:17:49 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611011517.JAA08564 at Mercury.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Kim Wohlert <Kim.Wohlert at mainz.dk>
Date: Fri, 1 Nov 1996 09:17:48 -0600 (CST)
Cc: karl at mcs.net, ietf at ietf.org, frezza at interramp.com
In-Reply-To: <c=DK%a=_%p=MAINZ%l=MOONRAKER-961101093446Z-992 at Moonraker.mainz.dk> from "Kim Wohlert" at Nov 1, 96 10:34:46 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> On Thursday, 31 October, 1996 21:00, Karl Denninger[SMTP:karl at mcs.net]
> wrote:
>
> <snip>
> >
> > >I also believe that the cost to implement this is TRIVIAL (few thousand
> > >dollars a year) and I'm even willing to host it (free) if that's what it
> > >takes to get the job done.
> > >
>
> Doesn't that make YOU the cartel?
Again, the difference here is that I'm looking for consensus, not ramming
things down people's throats. And I'm not DOING anything; the machine makes
and enforces the rules (which we agree on) :-)
> > >Let's say we define it like this:
> > >
> > >1)No more than 3 pending TLDs for an organization, no more than (say)
> > >five TLD registrations from an organization in a 30 day period.
> > >Affiliated (ie: significantly and operationally owned - 5% or more,
> > >use SEC rules on what "operational influence" is) companies count.
>
> As far as I am concerned, SEC is a US 'thing' that has absolutely no
> merit internationally, so you can't use those rules.
>
> Every nation will have its own definitions of "company", "operations
> influence" etc.
Ok, what if we say "any influence" and define it. Ie: overlapping boards of
directors, etc.
> > >2)Activation must be within 30 days of declaration of intent or the
> > >name gets released back. Activation is defined as customers being
> > >able to register under the domain with a published set of policies.
>
> Who will police that? You?
The computer polices it. You file with the computer for the domains, the
computer checks for working NS records in the zone and actual registrations.
None there in 30 days, poof.
> > >3)Beyond this, fight in court. (On the premise that courts generally
> > >are expensive, its only worth it with a 2+ billion entry namespace
> > >if someone has REALLY wronged you, and I believe in the rule of law
> > >not dictators, self-important ones included.)
>
> What court/law? US?, California?, Armenia?, Bahamas? (continue the list
> youself)
The combatents have to select the venue, as they do now in any other arena.
Its none of my (or your) business what venue two combatants want to sue each
other in. Nor should we ATTEMPT to define it, as that inserts bias in the
form of cost into the process.
> > >4)Prove fraud in the above and the offender gets removed entirely.
> > >(ie: penalties for cheating people are so obscene nobody will
> > >attempt it, and further, probably also passes legal scrutiny.
> > >The process HAS TO BE fair, recognize first-use somehow since that's
> > >what existing law is based on, and be reasonably-immune to abuse).
>
> Prove to whom? By what definition of fraud? And who gets to remove the
> offender? You?
I believe the policy is difficult to mis-interpret. If you believe it is
easy to misinterpret, then let's refine it until we're satisfied that it is
IMPOSSIBLE to misinterpret.
> No, a nationalist.
Where do you get the idea that this has anything to do with the US?
> > >I believe that the solution is for everyone to develop their own policies
> > >for TLDs (just like we have for SLDs now) if you wish to be one of the
> > >"authorities" for it, along with a dispute resolution procedure ("sue each
> > >other" is good enough) *AND* an explicit agreement to honor FCFS on the
> > >above (or something similar) guidelines.
>
> But if you want FCFS, someone has to decide what 'First' is? So in
> effect you are replacing one cartel with another - where is the benefit?
Again, define a process.
Quit sniping at people and start looking at the PROBLEM.
--
--
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
| 23 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 ab08246; 1 Nov 96 10:35 EST
Received: from ng.netgate.net by ietf.org id aa08082; 1 Nov 96 10:32 EST
Received: from [205.214.160.111] (d75.netgate.net [205.214.160.111]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id HAA14857; Fri, 1 Nov 1996 07:39:06 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100603ae9fc53d0de5 at [205.214.160.121]>
In-Reply-To: <9610018468.AA846865527 at ncr.disa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Fri, 1 Nov 1996 07:26:54 -0800
To: David Gaon <gaond at ncr.disa.mil>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re[2]: The cartel begins to crumble?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 5:22 AM -0800 11/1/96, David Gaon wrote:
> It appears to me that the simple solution is the creation of
> dsitributed directories.
> With the use of Directories, individuals can get a listing of all
> entities they wish to address that have IBM as 3 letters in their call
> sign or as the mnemonic of their name. The user will then selects the
David,
There is great appeal to trying to solve registration and mapping
problems by moving the task to a 'directory'. Such a suggestion crops up
pretty regularly in discussions about difficult lookup tasks. It almost
never really solves the problem.
The difference I make between a mapping service, like the DNS, and
a 'directory' service is that of determinism. You put in a precise query
to a mapping service and you get zero or one information node back. You
put in a query to a directory service and you might get any number of nodes
back. Then you figure out which one you really want...maybe.
A mapping service MUST be reasonably quick and completely
deterministic. A directory service does not need to be either. Hence, a
directory service MUST NOT be in the critical path of an infrastructure
service. It's fine as an adjunct, but it simply isn't the direction to go
for a service that returns addresses, especially when the lookup activity
is in the middle of mainline system processing such as a mail forwarder.
d/
ps.Even if one COULD use a directory, your suggestion doesn't solve
the current problem. Say you and I each list acme.biz in our different
directories and someone queries the distributed service, finding both
entries. How do they choose?
--------------------
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 aa08898; 1 Nov 96 10:39 EST
Received: from atlas.xylogics.com by ietf.org id aa08684; 1 Nov 96 10:38 EST
Received: from huey.xylogics.com (huey.xylogics.com [132.245.32.139]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id KAA02773; Fri, 1 Nov 1996 10:36:26 -0500 (EST)
Received: by huey.xylogics.com id AA18153 (4.1/UK-doug-951219);
Fri, 1 Nov 96 10:36:25 EST
Sender:ietf-request at ietf.org
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Fri, 1 Nov 96 10:36:25 EST
Message-Id: <18153.9611011536 at huey.xylogics.com>
To: jed at llnl.gov
Cc: ietf at ietf.org
In-Reply-To: "James E. [Jed] Donnelley"'s message of Thu, 31 Oct 1996 17:37:30 -0800 <v0300780aae9f015a0afd at [128.115.96.72]>
Subject: The cartel begins to crumble? - .com crowding
Source-Info: From (or Sender) name not authenticated.
> >The *.COM TLD is crowded, but only because everyone seems to want to
> >crowd into it ... probably exactly because it is so crowded.
>
> I think this is about right. A specific angle on this is that
> I (and I suspect I am not alone) often will try
Actually, I think that most people register under .com because they
don't know that anything else exists. I don't think I've ever seen
any URL advertised on TV that wasn't a .com. I think we could solve
some of the crowding simply by insisting that a .com name truely be
a company/corporation (i.e., not the name of a movie, or someones
pet project).
----------------------------------------------------------------------
Gary Malkin Cheap, Fast, Good
(617) 238-6237 Pick two!
Received: from ietf.org by ietf.org id aa09971; 1 Nov 96 11:02 EST
Received: from thunder.ncr.disa.mil by ietf.org id aa09775; 1 Nov 96 11:00 EST
Received: from ncr.disa.mil ([164.117.176.106]) by thunder.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id KAA05585; Fri, 1 Nov 1996 10:45:08 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA846874750; Fri, 01 Nov 96 10:52:15 EST
Date: Fri, 01 Nov 96 10:52:15 EST
Sender:ietf-request at ietf.org
From: David Gaon <gaond at ncr.disa.mil>
Message-Id: <9610018468.AA846874750 at ncr.disa.mil>
To: Dave Crocker <dcrocker at brandenburg.com>
Cc: ietf at ietf.org
Subject: Re[3]: The cartel begins to crumble?
Source-Info: From (or Sender) name not authenticated.
David Croker
All you say is true if the implementation of directory lookup is in the
router.
I am suggesting that the determination of the ""exact network address of
the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is left
to the user and is done offline (with respect to the communications
infrastructure). The user, on deciding whom he wants to reach, either
types in the corresponding port number in his e-mail or web access, or he
passes it to his application (e-mail) which inserts it in the appropriate
field.
As for forwarder application, instead of sending mail to ietf at isetf.org,
the user sends it to the exact address corresponding to that port. In
inception of the forwarder, the translation of exact member addresses is
done once (clearly updated later), but again done outside the main stream
process of the application.
Thus the task of the router is minimised and is as fast or even faster than
present implementation depending on what is doing the name translation.
Yes indeed, the user has to query the directory, search, and decide, but
so what, eventually he will accumulate (in his application's cache) the
port addresses of those he communicates with.
Cheers
David Gaon
DoD/DISA/Center for Standards
______________________________ Reply Separator _________________________________
Subject: Re[2]: The cartel begins to crumble?
Author: Dave Crocker <dcrocker at brandenburg.com> at smtp
Date: 11/1/96 10:31 AM
At 5:22 AM -0800 11/1/96, David Gaon wrote:
> It appears to me that the simple solution is the creation of
> dsitributed directories.
> With the use of Directories, individuals can get a listing of all
> entities they wish to address that have IBM as 3 letters in their call
> sign or as the mnemonic of their name. The user will then selects the
David,
There is great appeal to trying to solve registration and mapping
problems by moving the task to a 'directory'. Such a suggestion crops up
pretty regularly in discussions about difficult lookup tasks. It almost
never really solves the problem.
The difference I make between a mapping service, like the DNS, and
a 'directory' service is that of determinism. You put in a precise query
to a mapping service and you get zero or one information node back. You
put in a query to a directory service and you might get any number of nodes
back. Then you figure out which one you really want...maybe.
A mapping service MUST be reasonably quick and completely
deterministic. A directory service does not need to be either. Hence, a
directory service MUST NOT be in the critical path of an infrastructure
service. It's fine as an adjunct, but it simply isn't the direction to go
for a service that returns addresses, especially when the lookup activity
is in the middle of mainline system processing such as a mail forwarder.
d/
ps. Even if one COULD use a directory, your suggestion doesn't solve
the current problem. Say you and I each list acme.biz in our different
directories and someone queries the distributed service, finding both
entries. How do they choose?
--------------------
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 aa13326; 1 Nov 96 11:59 EST
Received: from pinky.junction.net by ietf.org id aa13222; 1 Nov 96 11:58 EST
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id JAA18182; Fri, 1 Nov 1996 09:11:54 -0800
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id IAA11634; Fri, 1 Nov 1996 08:53:00 -0800
Date: Fri, 1 Nov 1996 08:53:00 -0800 (PST)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: Jim Fleming <JimFleming at unety.net>
cc: "ietf at ietf.org" <ietf at ietf.org>,
"James E. [Jed] Donnelley" <jed at llnl.gov>,
'Phil Karn' <karn at qualcomm.com>, 'New Newdom' <newdom at vrx.net>
Subject: Re: Serious Business
In-Reply-To: <01BBC7D4.4C698AC0 at webster.unety.net>
Message-ID: <Pine.BSI.3.93.961101085135.4145W-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 1 Nov 1996, Jim Fleming wrote:
> @ Bill Frezza appears to be a journalistic gadfly who specializes in attacking
> @ large, successful technology organizations. He has written a series of
> @ articles
> @ attacking Qualcomm CDMA that, in my opinion, are best characterized as
> @ "vicious",
> @ as opposed to merely "uninformed" or "muckraking".
> ...this is all very serious business...and just think, much of
> it started out right there in the E Aisle in Building 6...
Is that the building at AT&T where you worked together with Bill Frezza
back in the early 80's on videotex/NAPLPS systems?
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from ietf.org by ietf.org id aa15163; 1 Nov 96 12:12 EST
Received: from doorstep.unety.net by ietf.org id aa14935; 1 Nov 96 12:10 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 LAA27445; Fri, 1 Nov 1996 11:04:47 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC7E4.B54E5060 at webster.unety.net>; Fri, 1 Nov 1996 11:06:19 -0600
Message-ID: <01BBC7E4.B54E5060 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Dave Crocker' <dcrocker at brandenburg.com>,
David Gaon <gaond at ncr.disa.mil>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: Re[2]: The cartel begins to crumble?
Date: Fri, 1 Nov 1996 11:06:17 -0600
Encoding: 233 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 01, 1996 9:26 AM, Dave Crocker[SMTP:dcrocker at brandenburg.com] wrote:
@ At 5:22 AM -0800 11/1/96, David Gaon wrote:
@ > It appears to me that the simple solution is the creation of
@ > dsitributed directories.
@ > With the use of Directories, individuals can get a listing of all
@ > entities they wish to address that have IBM as 3 letters in their call
@ > sign or as the mnemonic of their name. The user will then selects the
@
@David,
@
@There is great appeal to trying to solve registration and mapping
@ problems by moving the task to a 'directory'. Such a suggestion crops up
@ pretty regularly in discussions about difficult lookup tasks. It almost
@ never really solves the problem.
@
@The difference I make between a mapping service, like the DNS, and
@ a 'directory' service is that of determinism. You put in a precise query
@ to a mapping service and you get zero or one information node back. You
@ put in a query to a directory service and you might get any number of nodes
@ back. Then you figure out which one you really want...maybe.
@
@A mapping service MUST be reasonably quick and completely
@ deterministic. A directory service does not need to be either. Hence, a
@ directory service MUST NOT be in the critical path of an infrastructure
@ service. It's fine as an adjunct, but it simply isn't the direction to go
@ for a service that returns addresses, especially when the lookup activity
@ is in the middle of mainline system processing such as a mail forwarder.
@
@ d/
@
@ ps.Even if one COULD use a directory, your suggestion doesn't solve
@ the current problem. Say you and I each list acme.biz in our different
@ directories and someone queries the distributed service, finding both
@ entries. How do they choose?
@
@ --------------------
@ 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
@
@@@@@@@@@
Dave,
The DNS "mapping" system is evolving. As noted in my notes
below, there are new features being developed like the SRV
records which may not be "completely deterministic", thus
things like PRIORITY and WEIGHT are being proposed.
As noted below, I feel that people should try to step back
and look at the IPv4/DNS Core Transport system as a unit
and try to start using the DNS system for functions that
can help bring stability to the core network.
I agree with you that people should differentiate between those
services which are assumed to be part of the critcal mass
and those which are built around the edges. In my mind,
DNS is certainly part of the core, even though it may not be
deterministic.
...actually, nothing in the core is totally deterministic, of
course, that is the way it was designed and part of its beauty...
JF
----------
From:Jim Fleming[SMTP:JimFleming at unety.net.]
Sent:Thursday, October 31, 1996 11:44 PM
To:'New Newdom'
Subject:DNS Evolution
As some people know, I am an advocate of Internet evolution not
revolution. If one steps back and looks at the current Internet, they
will find a growing IPv4 core with a distributed Domain Name System
(DNS) that could be used for many more functions that require
symbolic names to be mapped to binary numbers.
If one draws a circle and labels it the IPv4/DNS Transport Core,
then everything inside that circle can be solidified via standards
and evolved to a point where no additional services or features
are needed, just new ways to use the old capabilities. This is
similar to what happens with processor instruction sets and
operating system interfaces, they reach a point where enough
is enough and then creativity takes over.
Einstein is often reported to have said, "Everything should be
as simple as possible, but no simpler". (or something like that)
In my opinion, that sort of test should be applied to the IPv4/DNS
Transport Core and evolution should then begin in a layer around
the outside of those core capabilities.
One area where evolution can occur is alternate uses for DNS
or alternate applications. Most people assume that DNS can
only be used to convert domain names to IP addresses, but
if you look at it from a purely bits and bytes point of view, it
can be used for many "mapping" or "lookup" applications.
In my opinion, the success of the Root 64 project and extensions
to the top level domains will depend on a highly synchronized
set of commercial root name servers operated by people with
a complete understanding of the overall system and the registries
needed to feed the system.
Some of the synchronizartion will be achieved simply via people
working together in "round table" forums where changes are
made only after consensus is reached via open discussions.
The rest of the synchronization will be achieved via software
automation. In my opinion, a view of the evolving IPv4/DNS
Transport Core should be developed and solidified and the
DNS should be used to the maximum amount possible to
assist in the root name server synchronization task.
Before the "core" is solidified, one has to ask, "When is enough,
enough?" or "When is the core as simple as possible but no
simpler?". While I am sure that everyone would love to rush
in the last list of features before the requirements are set and
the code is written, there is a point at which, enough is enough.
Because I tend to be a minimalist when it comes to computer
systems (that comes from hacking UNIX kernels since 1976),
I generally do not like to see a lot of time wasted while people
wait for the next release, or that killer feature which will make
life easier. There are always more future features, but sometimes
pressing people to use what they have, causes cleaner solutions.
Having said that, I will also admit that there could be some
new feature which could help to make life simpler and actually
help to *accelerate* some evolutionary transitions, if everyone
is willing to wait for the feature to be tested and widely deployed.
This happened several times in the early days of UNIX at Bell
Labs, but the day did come when enough was enough.
Because I would like to see DNS used to its max in helping
to solve the distributed global syncronization problem of the
root name servers, I think that all of the current features of
DNS should be assesed as well as those that are clearly on
the horizon.
Arnt Gulbrandsen and Paul Vixie have published some notes that
might be of interest to people working with top level domain issues
and root name server deployments.
@@@@@ ftp://ds.internic.net/rfc/rfc2052.txt
In a nutshell, the notes describe an experimental extension that
will allow SRV records to be added to encode DNS information
that goes beyond the current mundane world of domain name
to IP address mappings.
The following example SRV records help to illustrate most of
the proposed features...
@@@
; HTTP - server is the main server, new-fast-box is the backup
; (On new-fast-box, the HTTP daemon runs on port 8000)
;Service.Proto.Name TTL Class SRV Priority Weight Port Target
http.tcpSRV0080server.any-name.com.
SRV1008000new-fast-box.any-name.com.
@@@
When a SRV-cognizant client wants to retrieve
http://www.any-name.com/
it does a lookup of
http.tcp.www.any-name.com
the psuedo host.domain, "http.tcp" is found in the
"www.any-name.com" domain and instead of just obtaining an
IP address, port information is also obtained along with priority
and weight information. The client digests all of this and
continues the resolution to the final IP address.
@@@@@
Before the requirements and design of the root name server
synchronization system are solidified, the SRV capabilities
should probably be assessed to make sure that the "system
is as simple as possible, but no simpler".
It seems to me that two views could be taken of the SRV
capabilities:
1. The intended functionality described above.
2. The ability to store and retrieve a new type of
record, with binary fields that could be used
for many purposes, along with a target host
name.
I am not certain if either view will be helpful to provide the
last "killer" DNS feature needed to pull together the entire
root name server system into a coherent solution. It just
seemed to me, that when I read the notes, there was a
gut level feeling that the SRV records could be helpful in
the final root name server synchronization system.
Because time is short and more code must be written and
tested, I think that these capabilities require a quick look,
if for no other reason, than the ability to say, "we wanted to
use these capabilities, but ran out of time and had to stick
to the solidified set of features provided by the IPv4 Transport
Core as of October 1996.".
It seems to me that system evolution decisions require
an ability to know what features are worth waiting for,
balanced against some willingness to wait only so long
before "enough is enough"....
...it is good to have as many people as possible take
one last look...before things rapidly move forward in
high gear...
@@@@
--
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 aa15489; 1 Nov 96 12:15 EST
Received: from doorstep.unety.net by ietf.org id aa15247; 1 Nov 96 12: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 LAA27453; Fri, 1 Nov 1996 11:07:43 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC7E5.1F1DB760 at webster.unety.net>; Fri, 1 Nov 1996 11:09:16 -0600
Message-ID: <01BBC7E5.1F1DB760 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Michael Dillon' <michael at memra.com>
Cc: "ietf at ietf.org" <ietf at ietf.org>,
"James E. [Jed] Donnelley" <jed at llnl.gov>,
'Phil Karn' <karn at qualcomm.com>, 'New Newdom' <newdom at vrx.net>
Subject: RE: Serious Business
Date: Fri, 1 Nov 1996 11:09:15 -0600
Encoding: 38 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 01, 1996 2:53 AM, Michael Dillon[SMTP:michael at memra.com] wrote:
@ On Fri, 1 Nov 1996, Jim Fleming wrote:
@
@ > @ Bill Frezza appears to be a journalistic gadfly who specializes in attacking
@ > @ large, successful technology organizations. He has written a series of
@ > @ articles
@ > @ attacking Qualcomm CDMA that, in my opinion, are best characterized as
@ > @ "vicious",
@ > @ as opposed to merely "uninformed" or "muckraking".
@
@ > ...this is all very serious business...and just think, much of
@ > it started out right there in the E Aisle in Building 6...
@
@ Is that the building at AT&T where you worked together with Bill Frezza
@ back in the early 80's on videotex/NAPLPS systems?
@
@
@ Michael Dillon - ISP & Internet Consulting
@ Memra Software Inc. - Fax: +1-604-546-3049
@ http://www.memra.com - E-mail: michael at memra.com
@
@
@
No, Bill Frezza worked primarily in Holmdel, NJ.
Phil Karn and I worked together at Bell Labs Indian Hill, in Naperville, IL.
"ihnss" was located there...if you go back that far...
--
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 aa16934; 1 Nov 96 12:26 EST
Received: from jekyll.piermont.com by ietf.org id aa16809; 1 Nov 96 12:25 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id MAA02841; Fri, 1 Nov 1996 12:24:12 -0500 (EST)
Message-Id: <199611011724.MAA02841 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol
To: pinchas at sprynet.com
cc: ietf at ietf.org
Subject: Re: The Cartel Begins to Crumble
In-reply-to: Your message of "Wed, 30 Oct 1996 12:53:45 PST."
<3277C059.7617 at sprynet.com>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 01 Nov 1996 12:24:08 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Phillip Charles Oliff writes:
> One final observation, as the Internet grows, the efforts of the
> IETF will seem insignificant as compared to the industry giants.
> It seems that the computer industry has a short memory and will
> soon forget about our efforts if not properly reminded.
I believe that most of the firms that have seriously flouted standards
in the past (Wang comes to mind) have been punished in the
marketplace.
Perry
Received: from ietf.org by ietf.org id aa16933; 1 Nov 96 12:26 EST
Received: from coral.llnl.gov by ietf.org id aa16775; 1 Nov 96 12:25 EST
Received: from [128.115.96.72] (jedsmac.llnl.gov [128.115.96.72]) by coral.llnl.gov (8.7.5/8.7.3/LLNL-Jun96) with ESMTP id JAA01109; Fri, 1 Nov 1996 09:23:55 -0800 (PST)
X-Sender: jed at coral.llnl.gov
Message-Id: <v03007803ae9fe8dfa9f3 at [128.115.96.72]>
In-Reply-To: <18153.9611011536 at huey.xylogics.com>
References: "James E. [Jed] Donnelley"'s message of Thu, 31 Oct 1996
17:37:30 -0800 <v0300780aae9f015a0afd at [128.115.96.72]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 1 Nov 1996 10:01:59 -0800
To: Gary Scott Malkin <gmalkin at xylogics.com>
Sender:ietf-request at ietf.org
From: "James E. [Jed] Donnelley" <jed at llnl.gov>
Subject: Re: The cartel begins to crumble? - .com crowding
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
In responce to:
>> >The *.COM TLD is crowded, but only because everyone seems to want to
>> >crowd into it ... probably exactly because it is so crowded.
Gary Malkin wrote:
>Actually, I think that most people register under .com because they
>don't know that anything else exists. I don't think I've ever seen
>any URL advertised on TV that wasn't a .com. I think we could solve
>some of the crowding simply by insisting that a .com name truely be
>a company/corporation (i.e., not the name of a movie, or someones
>pet project).
I certainly think that publicizing alternative TLDs is a
good idea. I wouldn't go so far as to "insist." However,
I can see some justification for it. At least what a
corporation is can be quite well defined. There would certainly
be lot of grandfathering to deal with. Actually I was
only addressing the issue of why companies all want to be
in the .com domain. I see no justification for individuals
or projects or services or ... to be there.
I think the .per (or whatever it was) for personal domains is
a great (!) idea. Where do I sign up? I am not as sure about
projects, services, etc. If it would be adequate to take some
pressure off of the .com domain by introducing a few (centrally
managed ;-) new TLDs, then I am all for it. Perhaps it would be
useful to hear a summary of progress on this front in the
current administrative structure. I can't give that summary.
--Jed http://www-atp.llnl.gov/atp/jed-signature.html
Received: from ietf.org by ietf.org id aa17377; 1 Nov 96 12:34 EST
Received: from doorstep.unety.net by ietf.org id aa17305; 1 Nov 96 12:33 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 LAA27513; Fri, 1 Nov 1996 11:27:05 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC7E7.D3329160 at webster.unety.net>; Fri, 1 Nov 1996 11:28:37 -0600
Message-ID: <01BBC7E7.D3329160 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Gary Scott Malkin' <gmalkin at xylogics.com>,
"jed at llnl.gov" <jed at llnl.gov>
Cc: "ietf at ietf.org" <ietf at ietf.org>, 'New Newdom' <newdom at vrx.net>
Subject: RE: The cartel begins to crumble? - .com crowding
Date: Fri, 1 Nov 1996 11:28:36 -0600
Encoding: 64 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 01, 1996 9:36 AM, Gary Scott Malkin[SMTP:gmalkin at xylogics.com] wrote:
@ > >The *.COM TLD is crowded, but only because everyone seems to want to
@ > >crowd into it ... probably exactly because it is so crowded.
@ >
@ > I think this is about right. A specific angle on this is that
@ > I (and I suspect I am not alone) often will try
@
@ Actually, I think that most people register under .com because they
@ don't know that anything else exists. I don't think I've ever seen
@ any URL advertised on TV that wasn't a .com. I think we could solve
@ some of the crowding simply by insisting that a .com name truely be
@ a company/corporation (i.e., not the name of a movie, or someones
@ pet project).
@
@ ----------------------------------------------------------------------
@ Gary Malkin Cheap, Fast, Good
@ (617) 238-6237 Pick two!
@
@
That will happen as a result of the free market processes
working as well as other laws, such as supply and demand.
With the introduction of new top level domains, the supply
is being opened up. The demand may not be impacted, it
appears to continue to grow. Just look at the 2,000+
registrations that have been made in the new .USA top
level domain and that is only during the past few months.
Marketing people anticipate that the .COM extension may
become both a classic as well as a top level domain to
avoid, when leading edge companies realize that they can
now make a statement via the top level domain they choose.
Of course, many names will run in parallel with .COM for
quite some time.
The convention of registring a name in both .COM and
one of the new top level domains can further help to ease
this transition. For example, the following two names both
direct people to the proper place...
http://www.internet-mall.com
http://www.internet.mall
...if you do not believe me, give it a try, assuming of course
that you are on the leading edge of the Internet...;-)
P.S. With the NEW web server techniques, the server can
of course determine which of the above a person typed, and
"leading edge" people can be presented with leading edge
information and opportunities. If marketing people use that
as a selector, then people might be compelled to move to
the new format, so they do not miss something...of course,
classic DNS users could also be given a classic message...
...Hmmm...maybe an ASCII only web site...just like RFCs...
--
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 aa23878; 1 Nov 96 13:32 EST
Received: from cnri by ietf.org id aa23761; 1 Nov 96 13:30 EST
Received: from verdi.nethelp.no by CNRI.Reston.VA.US id aa16426;
1 Nov 96 13:30 EST
Received: (qmail 8905 invoked by uid 1001); 1 Nov 1996 18:29:18 +0000 (GMT)
To: ietf at CNRI.Reston.VA.US
Subject: RE: Folling the crumbling cartel - a note about thread following
Sender:ietf-request at ietf.org
From: sthaug at nethelp.no
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Fri, 01 Nov 1996 19:29:18 +0100
Message-ID: <8903.846872958 at verdi.nethelp.no>
Source-Info: From (or Sender) name not authenticated.
JimFleming at unety.net (Jim Fleming) wrote:
> Dear Phil...we have all come a long way...in a short time...
>
> I hope that you take this work seriously....
It's not at all clear what your message is supposed to prove. You have
listed a number of name servers. If your claim is that all these servers
know about your "alternative" TLDs, you're flat out wrong.
On top of the list, it says: "Attached is the growing list of root name
servers which are being deployed around the world."
Most of the refrences given are URLs, which really says nothing about
name servers at all. From the host name/IP addresses which are *not*
URLs, I made the following list:
Name IP address Other name Alternative Auth
rootsanswer
-----------------------------------------------------------------------------
NS.INTERNIC.NET 198.41.0.4 a.root-servers.net NoYes
NS1.ISI.EDU 128.9.0.107 b.root-servers.net NoYes
C.PSI.NET 192.33.4.12 c.root-servers.net NoYes
TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes
NS.NASA.GOV 192.203.230.10 e.root-servers.net NoConn refused
NS.ISC.ORG 192.5.5.241 f.root-servers.net NoYes
NS.NIC.DDN.MIL 192.112.36.4 g.root-servers.net NoYes
AOS.ARL.ARMY.MIL 128.63.2.53 h.root-servers.net NoYes
NIC.NORDU.NET 192.36.148.17 i.root-servers.net NoYes
ROOT-NS.THENIC.NET 207.67.22.81 NoNo
MX.ALTERNIC.NET 204.94.42.1 YesNo answer
ROOT-NS.MCS.NET 192.160.127.8 YesNo route
SIMBA.AGN.NET 160.79.1.3 YesNo
TORONTO.ALTERNIC.NET 207.107.232.106 YesYes
USVI.NET 204.199.0.4 YesYes *
NS.WW.NET 193.124.73.100 YesYes
NS.ALPHAQUE.COM 202.185.254.12 YesYes
NS.UNETY.NET 207.32.128.1 YesYes
Comments:
* Gives authoritative answer for ".", but returns localhost!
"No route": Doesn't answer ping
"No answer": Doesn't answer "dig ns ."
"Conn refused": Connection refused, so apparently no name server running
----------------------------------------------------------------------------
Not surprisingly, a.root-servers.net - i.root-servers.net do not support
your alternative roots. (I assume NS.NASA.GOV doesn't, even if I was
unable to verify this.)
Of the 9 name servers you have listed which are *not* the traditional
root name servers:
- 8 support your alternative roots (I *assume* MX.ALTERNIC.NET and
ROOT-NS.MCS.NET do, even if I was unable to verify this).
- One of these does not give authoritative answers.
- One of these returns "localhost" as the authoritative name server
for ".".
- One of these answers to ping, but doesn't answer DNS requests.
- Three of the servers are out side North America (Ukraine, Malaysia
and U.S. Virgin Island).
Quite frankly, I can't see that you have shown anything whatsoever about
growing support for your alternative roots around the world. Furthermore,
I can't see any reason why I should "take this work seriously".
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
Former 'no' TLD responsible
Received: from cnri by ietf.org id aa27201; 1 Nov 96 14:40 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18077;
1 Nov 96 14:40 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <SAA07712 at pad-thai.cam.ov.com>; Fri, 1 Nov 1996 18:09:14 GMT
Received: from PO10.ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA09375; Fri, 1 Nov 96 13:09:12 EST
Received: (from postman at localhost) by po10.andrew.cmu.edu (8.8.2/8.8.0) id NAA00774; Fri, 1 Nov 1996 13:09:08 -0500
Received: via switchmail; Fri, 1 Nov 1996 13:09:07 -0500 (EST)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.EmSXleK00WBw018u80>;
Fri, 1 Nov 1996 13:07:39 -0500 (EST)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/jgm/.Outgoing/QF.YmSXldK00WBw0L3HQ0>;
Fri, 1 Nov 1996 13:07:37 -0500 (EST)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54
via MS.5.6.hogtown.andrew.cmu.edu.sun4_51;
Fri, 1 Nov 1996 13:07:35 -0500 (EST)
Message-Id: <EmSXlbm00WBw0L3HE0 at andrew.cmu.edu>
Date: Fri, 1 Nov 1996 13:07:35 -0500 (EST)
From: John Gardiner Myers <jgm at cmu.edu>
To: imap at cac.washington.edu, cat-ietf at mit.edu
Subject: ietf-sasl mailing list
A new mailing list, ietf-sasl at imc.org, has been created to discuss and
resolve pending issues with the SASL (previously IMAP authentication)
draft. Subscriptions to ietf-sasl-request at imc.org
Thanks to the Internet Mail Consortium for hosting the list.
--
_.John Gardiner MyersInternet: jgm+ at CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.org by ietf.org id aa28787; 1 Nov 96 15:11 EST
Received: from nirvana.genesyslab.com by ietf.org id aa28679; 1 Nov 96 15:09 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 MAA20969; Fri, 1 Nov 1996 12:08:34 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id MAA09393; Fri, 1 Nov 1996 12:08:10 -0800 (PST)
Date: Fri, 1 Nov 1996 12:08:10 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199611012008.MAA09393 at giant.genesyslab.com>
To: Valdis.Kletnieks at vt.edu, gaond at ncr.disa.mil
Subject: Re: Re[3]: The cartel begins to crumble?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: Valdis.Kletnieks at vt.edu
>
>On Fri, 01 Nov 1996 10:52:15 EST, David Gaon said:
>> I am suggesting that the determination of the ""exact network address of
>> the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is left
>> to the user and is done offline (with respect to the communications
>> infrastructure). The user, on deciding whom he wants to reach, either
>> types in the corresponding port number in his e-mail or web access, or he
>> passes it to his application (e-mail) which inserts it in the appropriate
>> field.
>> As for forwarder application, instead of sending mail to ietf at isetf.org,
>> the user sends it to the exact address corresponding to that port. In
>> inception of the forwarder, the translation of exact member addresses is
>> done once (clearly updated later), but again done outside the main stream
>> process of the application.
>> Thus the task of the router is minimised and is as fast or even faster than
>> present implementation depending on what is doing the name translation.
>>
>Sounds good at first glance, but let's look at this a little bit closer...
>
>What about mail to ietf at ietf.org, as you use for your example? OK,
>*you* can do the resolution of *that* address "offline" - but once
>your mail gets to the mailing list, *EACH RECIPIENT* has to be looked
>up someplace.
>
>This is the *true* bottleneck. We have machines that process an
>amazing amount of mail per day. Hell, I'm the administrator of an
>RS6000-250, which is only a 66mz PowerPC chip, that handles over 500K
>messages/day some days. Eric Thomas has been pumping well over 2M/day
>through a P90 running NT. I haven't talked to my friends at AOL (you
>DTW's know who you are ;) lately about what THEY do...
Offline is offline - you can do resolving on another host.
And at second, I think the large part of CPU time is the name-server/resolver
side, not mail transfer side.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa28950; 1 Nov 96 15:14 EST
Received: from cnri by ietf.org id aa28840; 1 Nov 96 15:12 EST
Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa19038;
1 Nov 96 15:12 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id OAA07004; Fri, 1 Nov 1996 14:11:41 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJPwJ-000DTIC at mailbox.mcs.com>; Fri, 1 Nov 96 14:11 CST
Received: (from karl at localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id OAA27288; Fri, 1 Nov 1996 14:11:38 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611012011.OAA27288 at Mercury.mcs.net>
Subject: Re: Folling the crumbling cartel - a note about thread following
To: sthaug at nethelp.no
Date: Fri, 1 Nov 1996 14:11:38 -0600 (CST)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <8903.846872958 at verdi.nethelp.no> from "sthaug at nethelp.no" at Nov 1, 96 07:29:18 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> JimFleming at unety.net (Jim Fleming) wrote:
>
> > Dear Phil...we have all come a long way...in a short time...
> >
> > I hope that you take this work seriously....
>
> It's not at all clear what your message is supposed to prove. You have
> listed a number of name servers. If your claim is that all these servers
> know about your "alternative" TLDs, you're flat out wrong.
>
> On top of the list, it says: "Attached is the growing list of root name
> servers which are being deployed around the world."
>
> Most of the refrences given are URLs, which really says nothing about
> name servers at all. From the host name/IP addresses which are *not*
> URLs, I made the following list:
>
> Name IP address Other name Alternative Auth
> rootsanswer
> -----------------------------------------------------------------------------
> NS.INTERNIC.NET 198.41.0.4 a.root-servers.net NoYes
> NS1.ISI.EDU 128.9.0.107 b.root-servers.net NoYes
> C.PSI.NET 192.33.4.12 c.root-servers.net NoYes
> TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes
> NS.NASA.GOV 192.203.230.10 e.root-servers.net NoConn refused
> NS.ISC.ORG 192.5.5.241 f.root-servers.net NoYes
> NS.NIC.DDN.MIL 192.112.36.4 g.root-servers.net NoYes
> AOS.ARL.ARMY.MIL 128.63.2.53 h.root-servers.net NoYes
> NIC.NORDU.NET 192.36.148.17 i.root-servers.net NoYes
Does someone care to tell me under what authority NSI is running COM, ORG
and NET on servers owned by the US Government (three of the above) and two
publically funded universities (2 more of the above)? :-)
1/2 of your operating infrastructure effectively paid for (at least in part)
with public funds... not bad for a for-profit company!
> ROOT-NS.THENIC.NET 207.67.22.81 NoNo
>
> MX.ALTERNIC.NET 204.94.42.1 YesNo answer
> ROOT-NS.MCS.NET 192.160.127.8 YesNo route
That IP address is wrong. The right one is 192.160.127.86. If you ping
the right address (or dig to it) you'll find that it does work.
> SIMBA.AGN.NET 160.79.1.3 YesNo
> TORONTO.ALTERNIC.NET 207.107.232.106 YesYes
> USVI.NET 204.199.0.4 YesYes *
> NS.WW.NET 193.124.73.100 YesYes
> NS.ALPHAQUE.COM 202.185.254.12 YesYes
> NS.UNETY.NET 207.32.128.1 YesYes
>
> Comments:
>
> * Gives authoritative answer for ".", but returns localhost!
> "No route": Doesn't answer ping
> "No answer": Doesn't answer "dig ns ."
> "Conn refused": Connection refused, so apparently no name server running
> ----------------------------------------------------------------------------
>
> Not surprisingly, a.root-servers.net - i.root-servers.net do not support
> your alternative roots. (I assume NS.NASA.GOV doesn't, even if I was
> unable to verify this.)
>
> Of the 9 name servers you have listed which are *not* the traditional
> root name servers:
>
> - 8 support your alternative roots (I *assume* MX.ALTERNIC.NET and
> ROOT-NS.MCS.NET do, even if I was unable to verify this).
> - One of these does not give authoritative answers.
> - One of these returns "localhost" as the authoritative name server
> for ".".
> - One of these answers to ping, but doesn't answer DNS requests.
> - Three of the servers are out side North America (Ukraine, Malaysia
> and U.S. Virgin Island).
>
> Quite frankly, I can't see that you have shown anything whatsoever about
> growing support for your alternative roots around the world. Furthermore,
> I can't see any reason why I should "take this work seriously".
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
> Former 'no' TLD responsible
Well, you could start by making sure you're looking in the right place! :-)
--
--
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
| 23 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 aa29578; 1 Nov 96 15:23 EST
Received: from thunder.ncr.disa.mil by ietf.org id aa29370; 1 Nov 96 15:21 EST
Received: from ncr.disa.mil ([164.117.176.106]) by thunder.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id PAA10034; Fri, 1 Nov 1996 15:06:01 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA846890402; Fri, 01 Nov 96 15:17:47 EST
Date: Fri, 01 Nov 96 15:17:47 EST
Sender:ietf-request at ietf.org
From: David Gaon <gaond at ncr.disa.mil>
Message-Id: <9610018468.AA846890402 at ncr.disa.mil>
To: Valdis.Kletnieks at vt.edu, Leonid Egoshin <egoshin at genesyslab.com>
Cc: ietf at ietf.org
Subject: Re[5]: The cartel begins to crumble?
Source-Info: From (or Sender) name not authenticated.
Leonid
Thanks, I believe you have captured my intent.
But I suggest to Vladis Kletnieks that whoever creates the mailing
list will in fact resolve the names to port addresses and enter only
the last, or parties interested in joining the list will actually
offer their network port address through their mail (header or body)
since this will be available.
Cheers
David Gaon
DoD/DISA/Center for Standards
______________________________ Reply Separator _________________________________
Subject: Re: Re[3]: The cartel begins to crumble?
Author: Leonid Egoshin <egoshin at genesyslab.com> at smtp
Date: 11/1/96 3:08 PM
>From: Valdis.Kletnieks at vt.edu
>
>On Fri, 01 Nov 1996 10:52:15 EST, David Gaon said:
>> I am suggesting that the determination of the ""exact network address of
>> the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is
left
>> to the user and is done offline (with respect to the communications
>> infrastructure). The user, on deciding whom he wants to reach, either
>> types in the corresponding port number in his e-mail or web access, or
he
>> passes it to his application (e-mail) which inserts it in the
appropriate
>> field.
>> As for forwarder application, instead of sending mail to ietf at isetf.org,
>> the user sends it to the exact address corresponding to that port. In
>> inception of the forwarder, the translation of exact member addresses is
>> done once (clearly updated later), but again done outside the main
stream
>> process of the application.
>> Thus the task of the router is minimised and is as fast or even faster
than
>> present implementation depending on what is doing the name translation.
>>
>Sounds good at first glance, but let's look at this a little bit closer...
>
>What about mail to ietf at ietf.org, as you use for your example? OK,
>*you* can do the resolution of *that* address "offline" - but once
>your mail gets to the mailing list, *EACH RECIPIENT* has to be looked
>up someplace.
>
>This is the *true* bottleneck. We have machines that process an
>amazing amount of mail per day. Hell, I'm the administrator of an
>RS6000-250, which is only a 66mz PowerPC chip, that handles over 500K
>messages/day some days. Eric Thomas has been pumping well over 2M/day
>through a P90 running NT. I haven't talked to my friends at AOL (you
>DTW's know who you are ;) lately about what THEY do...
Offline is offline - you can do resolving on another host.
And at second, I think the large part of CPU time is the name-server/resolver
side, not mail transfer side.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa00420; 1 Nov 96 15:35 EST
Received: from cnri by ietf.org id aa00299; 1 Nov 96 15:33 EST
Received: from verdi.nethelp.no by CNRI.Reston.VA.US id aa19588;
1 Nov 96 15:33 EST
Received: (qmail 9291 invoked by uid 1001); 1 Nov 1996 20:32:54 +0000 (GMT)
To: karl at mcs.net
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Folling the crumbling cartel - a note about thread following
Sender:ietf-request at ietf.org
From: sthaug at nethelp.no
In-Reply-To: Your message of "Fri, 1 Nov 1996 14:11:38 -0600 (CST)"
References: <199611012011.OAA27288 at Mercury.mcs.net>
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Fri, 01 Nov 1996 21:32:54 +0100
Message-ID: <9289.846880374 at verdi.nethelp.no>
Source-Info: From (or Sender) name not authenticated.
> Does someone care to tell me under what authority NSI is running COM, ORG
> and NET on servers owned by the US Government (three of the above) and two
> publically funded universities (2 more of the above)? :-)
>
> 1/2 of your operating infrastructure effectively paid for (at least in part)
> with public funds... not bad for a for-profit company!
I'm not the right person to comment on this - but I see that you prefer
to discuss other things than the claimed 'growing support'.
> > ROOT-NS.MCS.NET 192.160.127.8 YesNo route
>
> That IP address is wrong. The right one is 192.160.127.86. If you ping
> the right address (or dig to it) you'll find that it does work.
My fault. Note that in my table I assumed it supported the alternative
roots, so my count of 8 servers for the alternative roots is unchanged.
> > Quite frankly, I can't see that you have shown anything whatsoever about
> > growing support for your alternative roots around the world. Furthermore,
> > I can't see any reason why I should "take this work seriously".
>
> Well, you could start by making sure you're looking in the right place! :-)
I still can't see that anything you've said here supports the notion
that there is growing support for your alternative roots around the world.
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
Received: from ietf.org by ietf.org id aa00712; 1 Nov 96 15:37 EST
Received: from localhost by ietf.org id aa00235; 1 Nov 96 15:32 EST
To: IETF-Announce: ;
Subject: Internet-Draft CUTOFF Date
Date: Fri, 01 Nov 1996 15:32:19 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9611011532.aa00235 at ietf.org>
The cut-off for Internet-Draft submissions prior to the San Jose IETF
meeting is Tuesday, November 26, 1996 at 5pm ET. Internet-Drafts
received after this time will not be announced nor made available in
the Internet-drafts Directories.
We will begin processing Internet-Draft submissions the week
following the IETF meeting.
Thank you for your understanding and cooperation. Please do not
hesitate to contact me if you have any questions or concerns.
Kind Regards,
Cynthia Clark
Internet-Drafts Administrator
Received: from ietf.org by ietf.org id aa01207; 1 Nov 96 15:47 EST
Received: from cnri by ietf.org id aa01065; 1 Nov 96 15:45 EST
Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa19932;
1 Nov 96 15:45 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 OAA28128; Fri, 1 Nov 1996 14:39:30 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC802.B4CACCE0 at webster.unety.net>; Fri, 1 Nov 1996 14:41:03 -0600
Message-ID: <01BBC802.B4CACCE0 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>,
"'sthaug at nethelp.no'" <sthaug at nethelp.no>
Cc: 'New Newdom' <newdom at vrx.net>
Subject: RE: Folling the crumbling cartel - a note about thread following
Date: Fri, 1 Nov 1996 14:41:01 -0600
Encoding: 140 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 01, 1996 12:29 PM, sthaug at nethelp.no wrote:
@ JimFleming at unety.net (Jim Fleming) wrote:
@
@ > Dear Phil...we have all come a long way...in a short time...
@ >
@ > I hope that you take this work seriously....
@
@ It's not at all clear what your message is supposed to prove. You have
@ listed a number of name servers. If your claim is that all these servers
@ know about your "alternative" TLDs, you're flat out wrong.
@
No, I do not claim this. Root name servers are a separate issue
from the alternative top level domains. Many people know that
the "popular" root name servers, commonly defaulted into "root.cache"
files, do not support all of the top level domains. The operators
of those name servers, still choose to recognize only a subset of the
TLDs.
@ On top of the list, it says: "Attached is the growing list of root name
@ servers which are being deployed around the world."
@
@ Most of the refrences given are URLs, which really says nothing about
@ name servers at all. From the host name/IP addresses which are *not*
@ URLs, I made the following list:
@
Unfortunately, you did not have all of the context of the list. I apologize
for mixing entries. Some of the entries are pointers to "notes" about
people and organizations that may or may not be likely candidates to
help host a root name server. Since the list is a "living notebook" using
a static medium like an ASCII file, it is difficult to show the hyper-dynamics
of the information.
One thing that should not go unmentioned from your great analysis
below is that one to the "popular" root name servers, NS.NASA.GOV,
is not the most stellar server to specify in one's "root.cache" file. This
helps to point out that ISPs should not just blindly load some file from
their O/S vendor or some "NIC", without looking at the file and fully
understanding the contents and the ramifications.
In my opinion, I do not think that the NASA server should even be in
the set of "popular" root name servers because of the following reasons.
1. As you have shown, it is not accessible.
2. It is in North America, and more International coverage should
be encouraged.
3. It is funded by U.S. taxpayers and as people have seen recently
as well as during the past few years, the U.S. Government
(mostly via the NSF) wants the Internet infrastructure to be
shifted to the commercial sector. Root name servers should
be no exception.
@ Name IP address Other name Alternative Auth
@ rootsanswer
@ -----------------------------------------------------------------------------
@ NS.INTERNIC.NET 198.41.0.4 a.root-servers.net NoYes
@ NS1.ISI.EDU 128.9.0.107 b.root-servers.net NoYes
@ C.PSI.NET 192.33.4.12 c.root-servers.net NoYes
@ TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes
@ NS.NASA.GOV 192.203.230.10 e.root-servers.net NoConn refused
@ NS.ISC.ORG 192.5.5.241 f.root-servers.net NoYes
@ NS.NIC.DDN.MIL 192.112.36.4 g.root-servers.net NoYes
@ AOS.ARL.ARMY.MIL 128.63.2.53 h.root-servers.net NoYes
@ NIC.NORDU.NET 192.36.148.17 i.root-servers.net NoYes
@
@ ROOT-NS.THENIC.NET 207.67.22.81 NoNo
@
@ MX.ALTERNIC.NET 204.94.42.1 YesNo answer
@ ROOT-NS.MCS.NET 192.160.127.8 YesNo route
@ SIMBA.AGN.NET 160.79.1.3 YesNo
@ TORONTO.ALTERNIC.NET 207.107.232.106 YesYes
@ USVI.NET 204.199.0.4 YesYes *
@ NS.WW.NET 193.124.73.100 YesYes
@ NS.ALPHAQUE.COM 202.185.254.12 YesYes
@ NS.UNETY.NET 207.32.128.1 YesYes
@
@ Comments:
@
@ * Gives authoritative answer for ".", but returns localhost!
@ "No route": Doesn't answer ping
@ "No answer": Doesn't answer "dig ns ."
@ "Conn refused": Connection refused, so apparently no name server running
@ ----------------------------------------------------------------------------
@
@ Not surprisingly, a.root-servers.net - i.root-servers.net do not support
@ your alternative roots. (I assume NS.NASA.GOV doesn't, even if I was
@ unable to verify this.)
@
(see my notes above on the NASA server)
@ Of the 9 name servers you have listed which are *not* the traditional
@ root name servers:
@
@ - 8 support your alternative roots (I *assume* MX.ALTERNIC.NET and
@ ROOT-NS.MCS.NET do, even if I was unable to verify this).
@ - One of these does not give authoritative answers.
@ - One of these returns "localhost" as the authoritative name server
@ for ".".
@ - One of these answers to ping, but doesn't answer DNS requests.
@ - Three of the servers are out side North America (Ukraine, Malaysia
@ and U.S. Virgin Island).
@
Yes, the idea behind the Root 64 Project is to develop broader coverage
around the world. The Root 128 Project focuses on just the U.S.
Many people feel that the U.S.-centric attitudes of Internet Infrastructure
administration need to be down played and more emphasis needs to be
placed on the International nature of the Internet. One of the major complaints
that some people reported from a recent Harvard conference was a lack
of participation from the International community.
@ Quite frankly, I can't see that you have shown anything whatsoever about
@ growing support for your alternative roots around the world. Furthermore,
@ I can't see any reason why I should "take this work seriously".
@
@ Steinar Haug, Nethelp consulting, sthaug at nethelp.no
@ Former 'no' TLD responsible
@
@
Thanks for your comments and analysis. You may want to consider
helping the evolution of this effort via the NEW newdom mailing list.
If Norway every decides to support a true root name server, you sound
like a good person to contact to get an expert opinion and help in that
region. Thanks again for the great feedback. I am sure that everyone
on the newdom list will appreciate your comments.
--
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 aa01231; 1 Nov 96 15:47 EST
Received: from ritig1.rit.reuters.com by ietf.org id aa01063; 1 Nov 96 15:45 EST
Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM)
id AA22599; Fri, 1 Nov 1996 15:47:40 -0500
Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V5.0-7 #7805)
id <01IBC4WOQI0W001VZE at RITIG4.RIT.REUTERS.COM> for ietf at ietf.org; Fri,
01 Nov 1996 15:41:59 -0500 (EST)
Received: with PMDF-MR; Fri, 01 Nov 1996 20:41:12 -0500 (EST)
Mr-Received: by mta REC.MUAS; Relayed; Fri, 01 Nov 1996 20:41:12 -0500
Mr-Received: by mta RE6; Relayed; Fri, 01 Nov 1996 20:41:13 -0500
Mr-Received: by mta RITIG4; Relayed; Fri, 01 Nov 1996 20:41:53 -0500
Disclose-Recipients: prohibited
Date: Fri, 01 Nov 1996 20:41:12 -0500 (EST)
Sender:ietf-request at ietf.org
From: Misha Wolf <MISHA.WOLF at reuters.com>
Subject: Tenth Int'l Unicode Conference - Call for Papers - Final Reminder
To: ietf <ietf at ietf.org>
Message-Id: <0912412001111996/A51806/RE6/11AB0D290B00* at MHS>
Autoforwarded: false
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Importance: normal
Priority: urgent
Ua-Content-Id: 11AB0D290B00
X400-Mts-Identifier: [;0912412001111996/A51806/RE6]
Hop-Count: 2
Source-Info: From (or Sender) name not authenticated.
Please forward this information to your colleagues, friends and contacts
C A L L F O R P A P E R S - F I N A L R E M I N D E R
!!! The deadline for submissions is 8 November 1996 !!!
* * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Tenth International Unicode Conference
and
Global Computing Showcase
Europe, Software + the Internet: Going Global with Unicode**
March 10-11, 1997
Mainz, Germany
****************************************************************************
With the Internet comes change: businesses world-wide expect accurate access
to text, independent of location or language. Users demand software that
runs everywhere. To meet these needs requires global computing. The Tenth
International Unicode** Conference will address all issues and topics
relating to global computing with Unicode.
Conference attendees will include managers, software engineers, systems
analysts, and product marketing personnel responsible for the development
of software supporting Unicode/ISO 10646 as well as those involved in all
aspects of the globalization of software and the Internet.
All proposals for papers will be reviewed for inclusion in the Conference
Program and book of Conference Proceedings.
THEME/TOPICS
Global computing with Unicode is the overall theme of the Conference.
Presentations should be geared towards a technical audience. Suggested
topics of interest include, but are not limited to:
- The Internet and Unicode
- The World Wide Web (WWW) and Unicode
- Java and Unicode
- Character set issues on the Internet and WWW
- Compression of Unicode data
- Testing Unicode applications
- Library and archival concerns
- Unicode in UNIX
- Unicode in databases
- Unicode in large scale networks
- The results of using Unicode applications (case studies, solutions)
- Business topics and market forecasts
- Language processing issues with Unicode data
- Migrating legacy applications to Unicode
- Cross platform issues
- Usability evaluations of Unicode applications
SESSIONS
The Conference Program will provide a wide range of sessions including:
- Keynote presentations
- Technical presentations
- Panel sessions
- Open discussion sessions
- Workshops/Tutorials
All sessions except the Workshops/Tutorials will be of 40 minute duration.
In some cases, two consecutive 40 minute program slots may be devoted to a
single session.
The Workshops/Tutorials will each last three hours. They should be designed
to stimulate discussion and participation, using slides and demonstrations.
DEADLINES:
Submissions due: 8 November 1996
Notification date: 22 November 1996
Camera ready papers due: 17 January 1997
PUBLICITY
If your submission is accepted, your abstract, biography, name, title and
affiliation, as well as any URLs you provide, will be included on the
Conference Web pages and will be seen by many people.
SUBMISSIONS
Submissions must contain:
1 An abstract of 150-250 words, consisting of statement of purpose, paper
description, and your conclusions or final summary
2 A brief biography
3 The details listed below:
TITLE OF SESSION: _______________________________________________
TYPE OF SESSION: [ ] Keynote presentation
[ ] Technical presentation
[ ] Panel session
[ ] Open discussion session
[ ] Workshop/Tutorial
TARGET AUDIENCE (you may select more than one category):
[ ] Manager [ ] Software Engineer
[ ] Systems Analyst [ ] Marketer
[ ] Other: ____________________________________
NAME: Dr/Mr/Mrs/Ms: _______________________________________________
TITLE/POSITION: _______________________________________________
ORGANIZATION/AFFILIATION: _______________________________________________
ORGANIZATION'S WWW URL: _______________________________________________
OWN WWW URL: _______________________________________________
E-MAIL ADDRESS: _______________________________________________
ADDRESS FOR PAPER MAIL: _______________________________________________
_______________________________________________
TELEPHONE: _______________________________________________
FAX: _______________________________________________
For e-mail submissions, please submit in ASCII, uncoded, non-compressed text
and use the following subject line:
Proposal for IUC 10
Submissions should be sent to the following address by e-mail, post, or fax:
Tenth International Unicode Conference
c/o Global Meeting Services
3627 Princess Avenue
N.Vancouver, B.C.
Canada V7N 2E4
voice: +1 604 983-9157
fax: +1 604 983-9158
e-mail: papers at unicode.org
or: barbara_jarzyna at mindlink.bc.ca
EXHIBIT OPPORTUNITIES:
The Conference will have an Exhibition area for corporations or individuals
who wish to display and promote their products, technology and/or services.
The Exhibition will take place from 5-8pm on March 10, coinciding with the
Conference Reception.
Every effort will be made to provide maximum exposure and advertising.
Exhibit space is limited. For further information or to reserve a place,
please contact Global Meeting Services at the above location.
CONFERENCE VENUE
The Conference will take place at the:
Mainz Hilton
Rheinstrasse 68
55116 Mainz
Germany
CONFERENCE UPDATES
For further information on the Tenth International Unicode Conference, visit
<http://www.reuters.com/unicode/iuc10/> or <http://www.unicode.org>.
THE UNICODE STANDARD
The Unicode Standard is a 16-bit character encoding encompassing the world's
principal scripts which provides the foundation for the internationalization
and localization of software. With its simple and efficient approach to
special and modified characters, the Unicode Standard defines a new degree
of data portability between platforms and across borders. Software
(especially modern, distributed systems) can be adapted for particular
countries far more easily than when existing character sets are used. The
Unicode Standard is code-for-code identical to the International Standard
ISO/IEC 10646.
For further information on the Unicode Standard, visit the Unicode Web site
at <http://www.unicode.org> or e-mail <unicode-inc at unicode.org>.
** 'Unicode' is a trademark of Unicode, Inc.
Received: from ietf.org by ietf.org id aa01332; 1 Nov 96 15:48 EST
Received: from cnri by ietf.org id aa01212; 1 Nov 96 15:47 EST
Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa19971;
1 Nov 96 15:47 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id OAA09359; Fri, 1 Nov 1996 14:46:15 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJQTm-000DPrC at mailbox.mcs.com>; Fri, 1 Nov 96 14:46 CST
Received: (from karl at localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id OAA29233; Fri, 1 Nov 1996 14:46:13 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611012046.OAA29233 at Mercury.mcs.net>
Subject: Re: Folling the crumbling cartel - a note about thread following
To: sthaug at nethelp.no
Date: Fri, 1 Nov 1996 14:46:13 -0600 (CST)
Cc: karl at mcs.net, ietf at CNRI.Reston.VA.US
In-Reply-To: <9289.846880374 at verdi.nethelp.no> from "sthaug at nethelp.no" at Nov 1, 96 09:32:54 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> > Does someone care to tell me under what authority NSI is running COM, ORG
> > and NET on servers owned by the US Government (three of the above) and two
> > publically funded universities (2 more of the above)? :-)
> >
> > 1/2 of your operating infrastructure effectively paid for (at least in part)
> > with public funds... not bad for a for-profit company!
>
> I'm not the right person to comment on this - but I see that you prefer
> to discuss other things than the claimed 'growing support'.
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
