[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12208;
21 Jul 93 17:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12201;
21 Jul 93 17:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24621;
21 Jul 93 17:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12189;
21 Jul 93 17:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12165;
21 Jul 93 17:07 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa24593;
21 Jul 93 17:07 EDT
Received: from stein.u.washington.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA08177>; Wed, 21 Jul 1993 14:07:45 -0700
Received: by stein.u.washington.edu
(5.65/UW-NDC Revision: 2.28 ) id AA05540; Wed, 21 Jul 93 14:07:33 -0700
X-Sender: hhll at stein.u.washington.edu
Date: Wed, 21 Jul 1993 14:07:04 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steven Hodas <hhll at u.washington.edu>
Subject: Re: Internet BYPASS makes its debut - for transmission of FAX's
To: Frank Chen <frank at manua.gsfc.nasa.gov>
Cc: the terminal of Geoff Goodfellow <geoff at radiomail.net>, ietf at isi.edu,
com-priv at psi.com
In-Reply-To: <9307212053.AA29637 at manua.gsfc.nasa.gov>
Message-Id: <Pine.3.05.9307211402.C3665-9100000 at stein.u.washington.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=us-ascii
Does anyone know the address of these FAX gateways?
Steven
__________________________________________________________________
|| ||
|| HORSE HORSE LION LION, A Consulting Cooperative ||
|| "Information into Culture" ||
|| ||
|| Steven Hodas:Catherine Holland, Principals ||
|| HHLL at u.washington.edu ||
|| VOICE/FAX 206.285.5975 or 206.285.5734 ||
||______________________________________________________________||
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13428;
21 Jul 93 19:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13421;
21 Jul 93 19:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28791;
21 Jul 93 19:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13408;
21 Jul 93 19:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13371;
21 Jul 93 19:21 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa28744;
21 Jul 93 19:21 EDT
Received: by trystero.malamud.com
(5.65/IDA-1.2.8e) id AA26586; Wed, 21 Jul 93 19:24:20 -0400
Date: Wed, 21 Jul 93 19:24:20 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at trystero.malamud.com>
Message-Id: <9307212324.AA26586 at trystero.malamud.com>
To: ietf at CNRI.Reston.VA.US
Subject: Posting by Goodfellow
Org: Internet Multicasting Service
>From: the terminal of Geoff Goodfellow <geoff at radiomail.net>
>Subject: Internet BYPASS makes its debut - for transmission of FAX's
Sigh. Geoff violated the New York Time's copyright on that story
by posting on this list without their permission. It really isn't
appropriate to steal, be it candy, software, or newspaper articles.
I think Geoff's emphasis on bypass really misses the point. While
that kind of simplistic, senior management, mono-word synopsis may
be typical for lists like com-priv, I'd really hope that people on
the ietf list would take the time to read the FAQ and subsequent
documents that Marshall and I will be publishing to try and understand
what is really happening with this experiment.
Unfortunately, I'm afraid that people like Geoff will take the
easy way out and stop at the "gee, I can send a free fax" and not
see the broader implications of such a project. That would be
quite unfortunate and we would all miss a chance to really show
the world how a general-purpose infrastructure like the Internet is
capable of handling a variety of different types of services with high
functionality and high efficiency.
Carl
P.S. The faq for "An Experiment in Remote Printing" is available from
tpc-faq at town.hall.org.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13445;
21 Jul 93 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13441;
21 Jul 93 19:26 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa28849;
21 Jul 93 19:26 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA08176; Wed, 21 Jul 93 18:27:00 CDT
Received: by hemlock.cray.com
id AA15075; 4.1/CRI-5.6; Wed, 21 Jul 93 18:26:53 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
id AA15066; 4.1/CRI-5.6; Wed, 21 Jul 93 18:26:50 CDT
Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA08161; Wed, 21 Jul 93 18:26:47 CDT
Received: by frenzy.cray.com
id AA02865; 4.1/CRI-5.6; Wed, 21 Jul 93 18:27:38 CDT
Date: Wed, 21 Jul 93 18:27:38 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "David A. Borman" <dab at berserkly.cray.com>
Message-Id: <9307212327.AA02865 at frenzy.cray.com>
To: telnet-ietf at cray.com
Subject: Re: Environment Option
This message is in two parts. The first part is a report in much
more detail of what happened at the Telnet WG meeting in Amsterdam,
with regards to the Environment option. It also spells out clearly
what decisions were made at that meeting, and what future actions
were agreed on. The last part contains my own comments.
In short:
In Amsterdam, the Telnet WG voted 7 to 3 to reissue
the Environment option with a new option number. These
results are to be posted to the mailing list, and if
there are no serious new objections to that decision,
that will be the decision of the WG
And now for the details...
Background
----------
The issue at hand is that the BSD based implementation of the
Environment option has the value for VAR and VALUE swapped from
what RFC-1408 says. We all know this. When this was discovered,
it was proposed that RFC-1408 be re-issued with definitions for
VAR and VALUE that match the BSD implementation. HP objected to
making the change, since they are already shipping products based
on the RFC-1408 definitions. The WG decided to re-issue the
RFC, changing VAR and VALUE to match the BSD implementation.
At the same time, I wrote up some heuristics that can be used
to detect whether or not the other side of a telnet connection
has the same or reversed definitions for VAR and VALUE. It was
proposed that implementations use these to aid in interoperability.
HP continued to object, and raised the issue with the IESG. The
upshot of the IESG response was that they refused to either uphold
or overturn the WG decision to reissue RFC-1408. Instead, they
said that the WG would have to revisit the decision to reissue
RFC-1408 and decide whether or not the heuristics were a good long
term solution, and then whatever the WG decided, the IESG would
back the Working Group decision.
The IESG did iterate that the Environment option is just at the
Proposed level, and when vendors implement Proposed specifications
into products, they are assuming the risk that they may very well
have to change their implementation, since Proposed standards can
change. Installed base may be a good argument for not changing a
Draft or full Standard, but it is not a good argument for not
changing a Proposed Standard. In part this is why the IESG pushed
the decision back to the WG.
So, in Amsterdam those in attendance at the Telnet WG meeting
went over the whole issue again.
The Discussion as Amsterdam
---------------------------
It was agreed that there is no technical reason for picking one
definition over the other, both will work just fine. If there was
a technical reason, the answer would be easy. Everyone agreed that
the only reason for considering changing the definitions and doing
the heuristics was to allow new implementations to be interoperable
with existing implementations, and all the future discussion was
held with this in mind.
The working group thus had two issues to discuss. First, should the
values for VAR and VALUE be changed, and second, should the heuristics
be published as an interoperability solution, which would be in use
forever. The group decided to attack the second question first,
hoping that it would lead to the answer to the first question.
Problems with the Heuristics
----------------------------
The problem with the heuristics is that there are situations
where they are not deterministic, and you cannot guarantee that
you know what definitions are in use on the other side. Most
of the group agreed that it would be good to be able to get to
a point in the future when using the Environment option could be
done in a deterministic manner.
Leaving the definitions for VAR/VALUE alone, or reversing them
would not achieve this. The only way to do this is to get new
definitions that are not ambiguous.
Proposal for new VAR/VALUE definitions
--------------------------------------
The first proposed solution was to define entirely new values
for VAR and VALUE. If you got either 0/1 or 1/0, it would mean
that you had an old host, and you would do the best you could
using the heuristics. If you got the new VAR/VALUE values,
then you would know exactly what to do.
The problem with this is trying to decide whether or not to
send the new VAR/VALUE values, since old hosts would really
be confused if they got these new values, even more than if
they had just gotten reversed definitions for VAR and VALUE.
(There is more detail that was discussed, and I'll type it
up if there is a request for it...)
Counter proposal to have a new Telnet Option Number
---------------------------------------------------
A counter proposal was that rather than define new values for
VAR and VALUE within the existing Environment option, that instead
a new Telnet Option number would be assigned to the Environment
option, and the old option number would be deprecated.
The advantage of this is that for the cost of sending both "IAC DO
NEW-ENVIRON" and "IAC DO OLD-ENVIRON" at connection establishment,
implementations that implement the new option number would be positively
identified, and no heuristics would be needed when talking to those
implementations.
If the NEW-ENVIRON was not recognized, but OLD-ENVIRON was, then
things would be exactly as they are today. Either you just use
what ever definitions you have used in the past for VAR and VALUE,
or you use the heuristics to try and interoperate with a reversed
implementation.
In the long run, we get a deterministic solution, and the need
for the heuristics slowly dies out.
Leave things as they are
------------------------
The HP representatives re-iterated their proposal to just leave
things as they were. Marjo has sent a message to the mailing list
with HPs wording of why they want things left as they are.
A Vote was taken
----------------
A vote was taken among those present. The choices were
the two proposals:
1) Assign a new option number
2) Leave things as they are
The vote was 7 for changing the option number, and 3 for leaving
things as they were. Since those in attendance did not represent
the entire WG, it was decided that a final decision could not be
made at the WG meeting. Instead, these results would be posted
to the mailing list, and unless there was serious objection on the
mailing list to going with the proposal to assign a new option number
to the Environment option, that would be the final outcome.
##############################################
## Here ends my summary of what happened at ##
## the WG meeting. The rest of this message ##
## is my personal views on a few points. ##
##############################################
o The new RFC should have the same definitions for VAR and
VALUE as RFC-1408. This will place more of the burden of
change on implementations that don't match RFC-1408.
o To update an RFC-1408 implementation will require:
1) Send IAC DO/WILL NEW-ENVIRON in addition
to the existing IAC DO/WILL OLD-ENVIRON.
2) Have a global variable, say "env_opt",
initialized to OLD-ENVIRON.
3) If a DO/WILL NEW-ENVIRON is received,
set "env_opt" to NEW-ENVIRON.
4) Add a case statement for NEW-ENVIRON next
to OLD-ENVIRON when parsing suboptions.
5) Use the global variable "env_opt" for the option
number when generating a Environ suboption, rather
than using a static definition.
o Implementations with reversed VAR/VALUE definitions will need
a little bit more code.
o Heuristic checking need only be done if only the OLD-ENVIRON
is recognized, and if the implementor wants to interoperate
with implementations that have reversed VAR/VALUE definitions.
o Marjo's list of Cons for leaving RFC1408 alone is not complete.
It misses one of the main disadvantages of just leaving things
as they are: Interoperability both now and in the future with
both existing and new implementations.
He ignores the fact the the existing, uninteroperable implementations
will be around for a long time, and that by doing nothing
means that this interoperability issue will be around as a
support issue for vendors for a very long time, with no hope
of ever getting out from underneath of it.
As a telnet implementor, my goals for interoperability are,
in decreasing importance:
1) New implementations
2) Old implementations with the same VAR/VALUE definitions
3) Old implementations with reversed VAR/VALUE definitions
This means that if things are left as they are, implementations
that have had reversed definitions from RFC-1408 will continue
to use those definitions as their default values, for the cases
when the heuristics fail to determine what type of implementation
is on the other side. There will be no obvious convergence in
implementations for the default definitions of VAR and VALUE, and
there will be this gray area of interoperability forever.
This means that leaving things as is is not a technically clean
solution except for those who wish to have implementations that
only interoperate with implementations that have RFC-1408
implementations. And even then those implementations will have
trouble if an implementation with reversed definitions talks
to them...
o The argument that voting to leave RFC-1408 alone is an endorsement
for the IETF process completely ignores that fact that the whole
point of the standards process is to allow people to have interoperable
implementations of a common protocol. The only reason we are even
having this discussion is to 1) allow future implementation to have
as widespread interoperability with existing implementations as possible,
and 2) the desire that in the long run implementations should be
able to have deterministic and reliable behavior.
o Bottom line, in my mind:
Assigning a new Environment option number means recognizing that
we are in an very messy situation with regards the interoperability
of the Environment option. It also means that future implementations
need not be forever tainted due to problems with existing implementations.
-David Borman, dab at cray.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14526;
21 Jul 93 21:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14519;
21 Jul 93 21:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03494;
21 Jul 93 21:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14505;
21 Jul 93 21:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14480;
21 Jul 93 21:41 EDT
Received: from gatekeeper.oracle.com by CNRI.Reston.VA.US id aa03447;
21 Jul 93 21:41 EDT
Received: from rivendell.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
id AA26606; Wed, 21 Jul 93 18:41:38 PDT
Received: by rivendell.us.oracle.com (5.59.11/37.7)
id AA07543; Wed, 21 Jul 93 18:40:38 PDT
Message-Id: <9307220140.AA07543 at rivendell.us.oracle.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jack Haverty <jhaverty at us.oracle.com>
To: Carl Malamud <carl at trystero.malamud.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Posting by Goodfellow
In-Reply-To: Your message of Wed, 21 Jul 93 19:24:20 -0400.
<9307212324.AA26586 at trystero.malamud.com>
Date: Wed, 21 Jul 93 18:40:37 PDT
"...
Unfortunately, I'm afraid that people like Geoff will take the
easy way out and stop at the "gee, I can send a free fax" and not
see the broader implications of such a project. That would be
quite unfortunate and we would all miss a chance to really show
the world how a general-purpose infrastructure like the Internet is
capable of handling a variety of different types of services with high
functionality and high efficiency.
..."
Carl - how do you know the Internet can provide a service "efficiently"? If
the Internet were a business and had to charge for a fax, how much would it
charge compared to a phone call fax?
Jack
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14807;
21 Jul 93 22:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14800;
21 Jul 93 22:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04816;
21 Jul 93 22:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14787;
21 Jul 93 22:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14762;
21 Jul 93 22:18 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa04760;
21 Jul 93 22:18 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA07936; Wed, 21 Jul 93 19:18:45 -0700
Message-Id: <9307220218.AA07936 at Mordor.Stanford.EDU>
To: Carl Malamud <carl at trystero.malamud.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Posting by Goodfellow
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 21 Jul 93 19:24:20 -0400. <9307212324.AA26586 at trystero.malamud.com>
Date: Wed, 21 Jul 93 19:18:45 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
Carl, et al,
I completely concur with your concerns and assessment.
On a different tack, I was struck by the speed of publication by major,
general-audience rags for this announcement. The Washington Post
printed it yesterday -- i.e., one working day after the announcement --
and the NY Times today. This is bigtime!
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15171;
21 Jul 93 22:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15160;
21 Jul 93 22:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04953;
21 Jul 93 22:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15104;
21 Jul 93 22:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14845;
21 Jul 93 22:24 EDT
Received: from wizard-gw.qualcomm.com by CNRI.Reston.VA.US id aa04893;
21 Jul 93 22:24 EDT
Received: from servo.qualcomm.com by qualcomm.com; id AA23546
sendmail 5.65/QC-main-2.1 via SMTP
Wed, 21 Jul 93 19:24:14 -0700 for ietf at CNRI.Reston.VA.US
Received: by servo; id AA13345
sendmail 5.67/QC-subsidiary-2.1
Wed, 21 Jul 93 19:24:12 -0700 for jhaverty at us.oracle.com
Date: Wed, 21 Jul 93 19:24:12 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Phil Karn <karn at qualcomm.com>
Message-Id: <9307220224.AA13345 at servo>
To: carl at trystero.malamud.com, jhaverty at us.oracle.com
Subject: Re: Posting by Goodfellow
Cc: ietf at CNRI.Reston.VA.US
>Carl - how do you know the Internet can provide a service "efficiently"? If
>the Internet were a business and had to charge for a fax, how much would it
>charge compared to a phone call fax?
Well, at least the Internet doesn't send fax by first converting the
scanned image into a 9600 bps data stream, modulating that stream onto
a V.29 modem, and then sampling the modem's audio output at 64kb/s for
transmission. It's got to be more efficient.
If it takes something as rudimentary as fax to make the Internet truly
ubiquitous and a household word, I'm all in favor.
Phil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17747;
21 Jul 93 22:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17729;
21 Jul 93 22:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05625;
21 Jul 93 22:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17497;
21 Jul 93 22:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16375;
21 Jul 93 22:52 EDT
Received: from aerospace.aero.org by CNRI.Reston.VA.US id aa05610;
21 Jul 93 22:51 EDT
Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT)
id AA00626 for ietf at cnri.reston.va.us; Wed, 21 Jul 1993 19:50:28 -0700
Posted-Date: Wed, 21 Jul 1993 18:22:21 -0700
Message-Id: <199307220250.AA00626 at aerospace.aero.org>
Received: from merlin.aero.org by antares.aero.org (4.1/AMS-1.0)
id AA22262 for cnom at maestro.bellcore.com; Wed, 21 Jul 93 18:22:41 PDT
To: cnom at maestro.bellcore.com, ietf at CNRI.Reston.VA.US, snmp at uu.psi.com,
rmonmib at jarthur.claremont.edu
To: Joe Betser <betser at aero.org>, Mike Erlinger <mike at lexcel.com>,
Keith McCloghrie <kzm at hls.com>,
Steve Waldbusser <waldbusser at andrew.cmu.edu>,
Stuart Noyce <noyce at ajax.sun.com>, "Steven M. Dauber" <dauber at novell.com>,
Garry Baer <baer at osf.org>, Rich Waterman <rmw at desktalk.com>,
Kirk Hsin <khsin at ossi.com>, Jim Warner <warnerj at attmail.com>,
Paul Brusil <pjb at mbunix.mitre.org>,
Branislav Meandzija <metaccss!eve!bran at hub.ucsb.edu>,
Michele Nessier <4367585 at mcimail.com>,
Frank Kaplan <frank at tdd.sj.nec.com>, joseph Ghetie <jgg at ctt.bellcore.com>,
Shri Goyal <skg0 at gte.com>, Jim Fox <fox at osi.ncsl.nist.gov>,
Gary Haney <hny at ornl.gov>, Thomas Cikoski <splinter at allink.com>,
Bob Donnelly <bdonnelly at attmail.com>,
Wallace Matthews <matthews at took.enet.dec.com>, ositc at aero.org,
NOMS <NOMS at tdd.sj.nec.com>, OIW Security SIG <secsig at udel.edu>
To: Electronic Mail Management Group <ifip-emailmgt at ics.uci.edu>
To: OIW NMSIG <nmsig at ics.uci.edu>
To: Mike Erlinger <erlinger at aero.org>, mike at jarthur.claremont.edu,
Joe Betser <betser at aero.org>, Kraig Meyer <kmeyer at aero.org>,
Peter DeVries <peter at ftp.com>, Dave Mahler <dave at remedy.com>,
Philip Almquist <almquist at vangogh.cs.berkeley.edu>,
Nan Dorio <dorio at blizzard.eng.sun.com>, Suzanne Carey <scc at world.std.com>,
Branislav Meandzija <metaccss!dude!bran at hub.ucsb.edu>
To: Regional Workshop <rwnmcc at nmpd.oz.au>
To: ANSI <x3t54 at mbunix.mitre.org>
To: MITRE-NADIS <nadism at mbunix.mitre.org>
To: MITRE-OSI <mitre-osi at bistromath.mitre.org>
To: MITRE <nsm-info at gateway.mitre.org>
To: OSI Mgt Implementation <OSIMIS at cs.ucl.ac.uk>,
OSI API <api at mel.dit.csiro.au>, IETF MADMAN <ietf-madman at innosoft.com>
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
To: "Dr. Melvyn P. Galin" <mgalin at mbvm.mitre.org>,
Kim Kappel <kappel at prism.gatech.edu>, Donna Cowan <dcowan at world.std.com>,
Douglas N Zuckerman +1 908 957 7874 <w2xd at mrspock.att.com>
Subject: NOMS 94 - Invitation to Submit
Date: Wed, 21 Jul 1993 18:22:21 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joe Betser <betser at aero.org>
Dear Colleague,
We would like to invite you to submit a contributiontion for NOMS'94, the
IEEE/IFIP 1994 Network Operations and Management Symposium
"It's a Small World - Networking in the 90's"
NOMS'94 will be held in Orlando, Florida, February 14-17, 1994.
NOMS 94 will address the operations and management of public and
private telecommunication and data networks, and of distributed systems.
We (Joe and Mac) are organizing a NOMS'94 session entitled :
"Management Platforms - Integration Issues"
The management of increasingly complex data communications networks
is becoming a challenge which is addressed by several commercial products,
which have been introduced to the marketplace over the past several years.
There is a strong movement in the direction of standards conformance, and
commercial-off-the-shelf (COTS) technology availability. The integration of
such technologies among themselves and into experimental and production
networks provides a myriad of exciting technical issues that merit presentation
to our growing community. You are encouraged to submit your experience,
present and future challenges, as well as open issues you might have as an end-user,
developer, researcher, standards contributor, product manager, or technology
vendor.
TOPICS OF INTEREST:
- Integration of Network Management Stations (NMS) and Passive Network
Monitors (PNM)
- Scalability issues
- Interoperability and standards
- OSI
- SNMP
- RMON (Remote Monitoring MIB)
- Applications
- OMNIPoint
- Performance issues
- Heterogeneous systems
- Multi-vendor support
- Technologies and specifications for design, development, and construction
Please inform us as soon as possible of your plans (See attached
information). We look forward to receiving your contribution. Feel
free to communicate with us with any issues.
Sincerely,
Dr. Makoto Yoshida
NTT Network Information Laboratories
myoshida at attmail.com (MYOSHIDA )
Phone: +81422593030
Fax-Phone: +81422592460
Dr. Joe Betser
The Aerospace Corporation
+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+
| Joseph BETSER |
| Computer Science and Technology tel: +1 310 336-0577 |
| The Aerospace Corporation fax: +1 310 336-4402 |
| Mail Station: M1-102 beep: +1 310 576-8575 |
| 2350 East El Segundo Boulevard |
| El Segundo, CA 90245-4691 e-mail: betser at aero.org |
==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==
INSTRUCTIONS AND SCHEDULE
Submissions should consist of about ten visuals with explanatory text
accompanying each one. The format should have a visual in the upper half of a
page and the explanatory text in the lower half. A formal paper for
publication is not required. For detailed instructions and a
schedule, please contact
the NMOS '94 Technical Program Chair (or Joe Betser / Makoto Yoshida regarding
this session.)
Shri K. Goyal
GTE Laboratories, MS 45 Email: goyal at gte.com
40 Sylvan Road Phone: +1 617 466 2940
Waltham, MA 02254 USA Fax: +1 617 466 2960
All submissions will be refereed.
Preliminary Schedule:
DRAFT VISUAL AND TEXT DUE AUGUST 10, 1993 - SOON !
Notification of Acceptance mailed October 29, 1993
Camera-ready visuals and text due December 15, 1993
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18370;
21 Jul 93 23:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18366;
21 Jul 93 23:38 EDT
Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa06759;
21 Jul 93 23:38 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id
<01H0TFC1TI9C984K5Z at INNOSOFT.COM>; Wed, 21 Jul 1993 20:23:54 PST
Received: from aerospace.aero.org by INNOSOFT.COM (PMDF V4.2-13 #1336) id
<01H0TFBQNDZK984IJI at INNOSOFT.COM>; Wed, 21 Jul 1993 20:23:46 PST
Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT)
id AA00578 for ietf-madman at innosoft.com; Wed, 21 Jul 1993 19:48:25 -0700
Received: from merlin.aero.org by antares.aero.org (4.1/AMS-1.0) id AA22262 for
cnom at maestro.bellcore.com; Wed, 21 Jul 93 18:22:41 PDT
Date: Wed, 21 Jul 1993 18:22:21 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joe Betser <betser at aero.org>
Subject: NOMS 94 - Invitation to Submit
To: cnom at maestro.bellcore.com, ietf at CNRI.Reston.VA.US, snmp at uu.psi.com,
rmonmib at jarthur.claremont.edu
To: Joe Betser <betser at aero.org>, Mike Erlinger <mike at lexcel.com>,
Keith McCloghrie <kzm at hls.com>,
Steve Waldbusser <waldbusser at andrew.cmu.edu>,
Stuart Noyce <noyce at ajax.sun.com>, "Steven M. Dauber" <dauber at novell.com>,
Garry Baer <baer at osf.org>, Rich Waterman <rmw at desktalk.com>,
Kirk Hsin <khsin at ossi.com>, Jim Warner <warnerj at attmail.com>,
Paul Brusil <pjb at mbunix.mitre.org>,
Branislav Meandzija <metaccss!eve!bran at hub.ucsb.edu>,
Michele Nessier <4367585 at mcimail.com>,
Frank Kaplan <frank at tdd.sj.nec.com>, joseph Ghetie <jgg at ctt.bellcore.com>,
Shri Goyal <skg0 at gte.com>, Jim Fox <fox at osi.ncsl.nist.gov>,
Gary Haney <hny at ornl.gov>, Thomas Cikoski <splinter at allink.com>,
Bob Donnelly <bdonnelly at attmail.com>,
Wallace Matthews <matthews at took.enet.dec.com>, ositc at aero.org,
NOMS <NOMS at tdd.sj.nec.com>, OIW Security SIG <secsig at udel.edu>
To: Electronic Mail Management Group <ifip-emailmgt at ics.uci.edu>
To: OIW NMSIG <nmsig at ics.uci.edu>
To: Mike Erlinger <erlinger at aero.org>, mike at jarthur.claremont.edu,
Joe Betser <betser at aero.org>, Kraig Meyer <kmeyer at aero.org>,
Peter DeVries <peter at ftp.com>, Dave Mahler <dave at remedy.com>,
Philip Almquist <almquist at vangogh.cs.berkeley.edu>,
Nan Dorio <dorio at blizzard.eng.sun.com>, Suzanne Carey <scc at world.std.com>,
Branislav Meandzija <metaccss!dude!bran at hub.ucsb.edu>
To: Regional Workshop <rwnmcc at nmpd.oz.au>
To: ANSI <x3t54 at mbunix.mitre.org>
To: MITRE-NADIS <nadism at mbunix.mitre.org>
To: MITRE-OSI <mitre-osi at bistromath.mitre.org>
To: MITRE <nsm-info at gateway.mitre.org>
To: OSI Mgt Implementation <OSIMIS at cs.ucl.ac.uk>,
"To:OSI API" <api at mel.dit.csiro.au>,
"To:IETF MADMAN" <ietf-madman at innosoft.com>
To: "Dr. Melvyn P. Galin" <mgalin at mbvm.mitre.org>,
Kim Kappel <kappel at prism.gatech.edu>, Donna Cowan <dcowan at world.std.com>,
Douglas N Zuckerman +1 908 957 7874 <w2xd at mrspock.att.com>
Errors-to: ned+madman-errors at INNOSOFT.COM
Resent-message-id: <01H0TFC1WGCI984K5Z at INNOSOFT.COM>
Message-id: <199307220248.AA00578 at aerospace.aero.org>
X-VMS-To: IN%"cnom at maestro.bellcore.com", IN%"ietf at cnri.reston.va.us",
IN%"snmp at uu.psi.com", IN%"rmonmib at jarthur.claremont.edu"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Posted-Date: Wed, 21 Jul 1993 18:22:21 -0700
Dear Colleague,
We would like to invite you to submit a contributiontion for NOMS'94, the
IEEE/IFIP 1994 Network Operations and Management Symposium
"It's a Small World - Networking in the 90's"
NOMS'94 will be held in Orlando, Florida, February 14-17, 1994.
NOMS 94 will address the operations and management of public and
private telecommunication and data networks, and of distributed systems.
We (Joe and Mac) are organizing a NOMS'94 session entitled :
"Management Platforms - Integration Issues"
The management of increasingly complex data communications networks
is becoming a challenge which is addressed by several commercial products,
which have been introduced to the marketplace over the past several years.
There is a strong movement in the direction of standards conformance, and
commercial-off-the-shelf (COTS) technology availability. The integration of
such technologies among themselves and into experimental and production
networks provides a myriad of exciting technical issues that merit presentation
to our growing community. You are encouraged to submit your experience,
present and future challenges, as well as open issues you might have as an end-user,
developer, researcher, standards contributor, product manager, or technology
vendor.
TOPICS OF INTEREST:
- Integration of Network Management Stations (NMS) and Passive Network
Monitors (PNM)
- Scalability issues
- Interoperability and standards
- OSI
- SNMP
- RMON (Remote Monitoring MIB)
- Applications
- OMNIPoint
- Performance issues
- Heterogeneous systems
- Multi-vendor support
- Technologies and specifications for design, development, and construction
Please inform us as soon as possible of your plans (See attached
information). We look forward to receiving your contribution. Feel
free to communicate with us with any issues.
Sincerely,
Dr. Makoto Yoshida
NTT Network Information Laboratories
myoshida at attmail.com (MYOSHIDA )
Phone: +81422593030
Fax-Phone: +81422592460
Dr. Joe Betser
The Aerospace Corporation
+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+
| Joseph BETSER |
| Computer Science and Technology tel: +1 310 336-0577 |
| The Aerospace Corporation fax: +1 310 336-4402 |
| Mail Station: M1-102 beep: +1 310 576-8575 |
| 2350 East El Segundo Boulevard |
| El Segundo, CA 90245-4691 e-mail: betser at aero.org |
==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==
INSTRUCTIONS AND SCHEDULE
Submissions should consist of about ten visuals with explanatory text
accompanying each one. The format should have a visual in the upper half of a
page and the explanatory text in the lower half. A formal paper for
publication is not required. For detailed instructions and a
schedule, please contact
the NMOS '94 Technical Program Chair (or Joe Betser / Makoto Yoshida regarding
this session.)
Shri K. Goyal
GTE Laboratories, MS 45 Email: goyal at gte.com
40 Sylvan Road Phone: +1 617 466 2940
Waltham, MA 02254 USA Fax: +1 617 466 2960
All submissions will be refereed.
Preliminary Schedule:
DRAFT VISUAL AND TEXT DUE AUGUST 10, 1993 - SOON !
Notification of Acceptance mailed October 29, 1993
Camera-ready visuals and text due December 15, 1993
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01485;
22 Jul 93 7:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01481;
22 Jul 93 7:59 EDT
Received: from lists.psi.com by CNRI.Reston.VA.US id aa07669; 22 Jul 93 7:59 EDT
Received: by lists.psi.com (4.1/SMI-4.1.2-PSI)
id AA03080; Thu, 22 Jul 93 07:55:32 EDT
Return-Path: <srcdc at access.digex.net>
Received: from psi.com by lists.psi.com (4.1/SMI-4.1.2-PSI)
id AA02996; Thu, 22 Jul 93 07:55:10 EDT
Received: from access.digex.net by psi.com (4.1/2.1-PSI/PSINet)
id AA00506; Thu, 22 Jul 93 07:56:04 EDT
Received: by access.digex.net id AA27287
(5.65c/IDA-1.4.4 for com-priv at psi.com); Thu, 22 Jul 1993 07:55:53 -0400
Date: Thu, 22 Jul 1993 07:54:17 -0400 (EDT)
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Users <srcdc at access.digex.net>
Subject: Re: Internet BYPASS makes its debut - for transmission of FAX's
To: the terminal of Geoff Goodfellow <geoff at radiomail.net>
Cc: com-priv at psi.com, ietf at isi.edu
In-Reply-To: <9307212014.AA20569 at radiomail>
Message-Id: <Pine.3.07.9307220715.A26483-9100000 at access.digex.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
What about sending a fax that contains a quick draft drawing???
Also, who will pay for all the hardware and their use?
Nicolas Keller
System Resources Corporation
600 Maryland Avenue SW #740
Washington, DC 20024
Tel.: (202) 488-9740
Fax.: (202) 488-4729
Email: srcdc at access.digex.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02996;
22 Jul 93 9:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02989;
22 Jul 93 9:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11011;
22 Jul 93 9:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02976;
22 Jul 93 9:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02892;
22 Jul 93 9:21 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa10916;
22 Jul 93 9:21 EDT
Received: by xap.xyplex.com id <AA01615 at xap.xyplex.com>; Thu, 22 Jul 93 09:20:32 -0500
Date: Thu, 22 Jul 93 09:20:32 -0500
Message-Id: <9307221420.AA01615 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: Phil Karn's message of Wed, 21 Jul 93 19:24:12 -0700 <9307220224.AA13345 at servo>
Subject: Re: Posting by Goodfellow
>If it takes something as rudimentary as fax to make the Internet truly
>ubiquitous and a household word, I'm all in favor.
Ubiquity and householdness are fine things. Like most of us, I enjoy my
"free" Internet access (that my company pays NEARnet big bucks for).
I don't mean to get political, but as a person of somewhat libertarian bent,
the socialistic aspects of the Internet bother me a bit. Lots and lots of
people cooperating and donating to something they all use is wonderful.
Taxing everyone so a relatively small percentage get a benefit is not so
wonderful. So I can send free faxes. That's good for me and my company, and
Xyplex may actually be donating enough cash, via NEARnet, to pay for the free
lunch.
It would be interesting to know how the Internet is actually financed. "The
Public" deserves to know what it's paying and what it's getting. This has got
to come up eventually. If everyone had the Internet, would we still need
old-fashioned telephones and paper mail? If not, someone's sure to object.
Like most of us, I'd much rather use free email, free faxes, free talk, and
such, but I do occasionally feel a little guilty. I do have to pay for U.S.
mail and my home phone service with some consideration for how much I use it.
Bob
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03473;
22 Jul 93 9:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11719;
22 Jul 93 9:42 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03430;
22 Jul 93 9:42 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03249;
22 Jul 93 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-caradec-telnet-mpx-option-00.txt
Date: Thu, 22 Jul 93 09:38:33 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307220938.aa03249 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : TELNET MPX option
Author(s) : J. Caradec, M. Mercado
Filename : draft-caradec-telnet-mpx-option-00.txt
Pages : 10
This Internet Draft specifies a multiplexing protocol for TELNET hosts and
devices using the Internet TCP/IP protocol stack. Hosts that exchange
TELNET Multiplexing (MPX) information within the TELNET protocol are
expected to adopt and implement this protocol.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-caradec-telnet-mpx-option-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-caradec-telnet-mpx-option-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-caradec-telnet-mpx-option-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-caradec-telnet-mpx-option-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03480;
22 Jul 93 9:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03468;
22 Jul 93 9:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11720;
22 Jul 93 9:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03440;
22 Jul 93 9:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03302;
22 Jul 93 9:40 EDT
Received: from pooh.cc.iastate.edu by CNRI.Reston.VA.US id aa11646;
22 Jul 93 9:40 EDT
Received: by iastate.edu with sendmail-5.57/4.7
id <AA01138 at iastate.edu>; Thu, 22 Jul 93 08:41:22 -0500
Message-Id: <9307221341.AA01138 at iastate.edu>
To: ietf at CNRI.Reston.VA.US
Cc: Bob Stewart <rlstewart at eng.xyplex.com>
Subject: Re: Posting by Goodfellow
In-Reply-To: Bob Stewart's message of Thu, 22 Jul 93 09:20:32 -0500.
<9307221420.AA01615 at xap.xyplex.com>
Date: Thu, 22 Jul 93 08:41:21 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Hascall <john at iastate.edu>
Phil Karn sez:
> >If it takes something as rudimentary as fax to make the Internet truly
> >ubiquitous and a household word, I'm all in favor.
> Ubiquity and householdness are fine things. Like most of us, I enjoy my
> "free" Internet access (that my company pays NEARnet big bucks for).
> Like most of us, I'd much rather use free email, free faxes, free talk, and
> such, but I do occasionally feel a little guilty. I do have to pay for U.S.
> mail and my home phone service with some consideration for how much I use it.
But do you feel guilty when you use the "free" highway system?
Nothing is really free, we pay for everything -- the only difference
is whether the paying is obvious or not.
I think the fundamental question is whether something is important
enough that the paying be structured to encourage use (as opposed to
being structured to contain use).
In my opinion the "internet" is that important -- no doubt those
with vested interests in "competing" technologies will see it
different.
-------------------------------------------------------------------------------
John Hascall An ill-chosen word is the fool's messenger.
Project Vincent
Iowa State University Computation Center john at iastate.edu
Ames, IA 50011 (515) 294-9551
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03527;
22 Jul 93 9:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11742;
22 Jul 93 9:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03514;
22 Jul 93 9:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03336;
22 Jul 93 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-cat-secservice-03.txt
Date: Thu, 22 Jul 93 09:41:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307220941.aa03336 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Note: This revision reflects only minor typographical
changes since the IESG approved the Internet-Draft for
publication as a Proposed Standard.
Title : Generic Security Service API : C-bindings
Author(s) : John Wray
Filename : draft-ietf-cat-secservice-03.txt
Pages : 46
This draft document specifies C language bindings for the Generic Security
Service Application Program Interface (GSS-API), which is described at a
language-independent conceptual level in other drafts.
The Generic Security Service Application Programming Interface (GSS-API)
provides security services to its callers, and is intended for
implementation atop alternative underlying cryptographic mechanisms.
Typically, GSS-API callers will be application protocols into which
security enhancements are integrated through invocation of services
provided by the GSS-API. The GSS-API allows a caller application to
authenticate a principal identity associated with a peer application, to
delegate rights to a peer, and to apply security services such as
confidentiality and integrity on a per-message basis.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-cat-secservice-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-cat-secservice-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-cat-secservice-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-secservice-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03746;
22 Jul 93 9:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03739;
22 Jul 93 9:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12013;
22 Jul 93 9:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03726;
22 Jul 93 9:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03671;
22 Jul 93 9:47 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa11972;
22 Jul 93 9:47 EDT
Received: by xap.xyplex.com id <AA02212 at xap.xyplex.com>; Thu, 22 Jul 93 11:47:06 -0500
Date: Thu, 22 Jul 93 11:47:06 -0500
Message-Id: <9307221647.AA02212 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: John Hascall's message of Thu, 22 Jul 93 08:41:21 CDT <9307221341.AA01138 at iastate.edu>
Subject: Re: Who Pays for What (was "Posting by Goodfellow")
>But do you feel guilty when you use the "free" highway system?
Nope. I have a better sense of how that's paid for, and I've bought most of
the argument about its widespread common benefit to justify paying for it
with taxes.
In terms of the entire U.S. (world?) population, the Internet benefits only a
small percentage. If that benefit every approaches universality, then taxes
rather than usage fees become more appropriate.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04686;
22 Jul 93 10:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04679;
22 Jul 93 10:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13998;
22 Jul 93 10:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04667;
22 Jul 93 10:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04638;
22 Jul 93 10:35 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa13876;
22 Jul 93 10:35 EDT
Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by venera.isi.edu (5.65c/5.61+local-12)
id <AA01372>; Thu, 22 Jul 1993 07:35:39 -0700
Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690)
id AA13181; Thu, 22 Jul 93 07:34:43 -0700
To: the terminal of Geoff Goodfellow <geoff at radiomail.net>
Cc: com-priv at psi.com, ietf at isi.edu
Reply-To: com-priv at psi.com
Subject: Re: Internet BYPASS makes its debut - for transmission of FAX's
In-Reply-To: Your message of "Wed, 21 Jul 1993 13:19:33 BST." <9307212014.AA20569 at radiomail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Jul 1993 07:34:39 -0700
Message-Id: <13176.743351679 at dbc.mtview.ca.us>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marshall Rose <mrose at dbc.mtview.ca.us>
There appears to be a misunderstanding here. I'll try to make things clearer.
In the grand Internet tradition, Carl and I are running an EXPERIMENT.
The full details of this EXPERIMENT can be found in the forthcoming
EXPERIMENTAL RFC entitled
An EXPERIMENT in Remote Printing
(The document was submitted at the beginning of the month and is
undergoing an advisory review by the IESG prior to publication.)
For now, people interested in general information on the EXPERIMENT, can
consult an FAQ (interested parties should send a note to
tpc-faq at town.hall.org
and an automated reply will return a copy of the FAQ).
There are of course many EXPERIMENTS being undertaken in the Internet.
This is one of them. It is perfectly fine to EXPERIMENT. Sometimes we
learn things from them. And sometimes other things grow from them as well...
/mtr
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04827;
22 Jul 93 10:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04820;
22 Jul 93 10:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14124;
22 Jul 93 10:41 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04802;
22 Jul 93 10:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04760;
22 Jul 93 10:39 EDT
Received: from mitsou.inria.fr by CNRI.Reston.VA.US id aa14063;
22 Jul 93 10:39 EDT
Received: by mitsou.inria.fr
(5.65c/IDA-1.2.8) id AA09663; Thu, 22 Jul 1993 16:41:17 +0200
Message-Id: <199307221441.AA09663 at mitsou.inria.fr>
To: Bob Stewart <rlstewart at eng.xyplex.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Posting by Goodfellow
In-Reply-To: Your message of "Thu, 22 Jul 93 09:20:32 CDT."
<9307221420.AA01615 at xap.xyplex.com>
Date: Thu, 22 Jul 93 16:41:17 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Christian Huitema <Christian.Huitema at sophia.inria.fr>
Bob,
The Internet is not free. As you mention, a number of companies pay real money
for their connections (INRIA is no exception). Also, a number of companies
gain real money by selling Internet connections. They are probably bound to
gain more if more people connect to the Internet.
The one point where Internet billing differs from, say, telephone, is that
these companies tend to pay fixed bills and share a fixed amount of resources
"dynamically" rather than pay on demand and get dynamic amounts of resources.
Experience has shown that the "dynamic sharing" model is very well adapted to
data transmission -- that is in fact what packet switching is all about...
Christian Huitema
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05404;
22 Jul 93 11:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05397;
22 Jul 93 11:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14931;
22 Jul 93 11:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05383;
22 Jul 93 11:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05314;
22 Jul 93 11:00 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa14869;
22 Jul 93 11:00 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA23778; Thu, 22 Jul 93 08:00:39 -0700
Message-Id: <9307221500.AA23778 at Mordor.Stanford.EDU>
To: John Hascall <john at iastate.edu>
Cc: ietf at CNRI.Reston.VA.US, Bob Stewart <rlstewart at eng.xyplex.com>
Subject: Re: Posting by Goodfellow
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Thu, 22 Jul 93 08:41:21 -0500. <9307221341.AA01138 at iastate.edu>
Date: Thu, 22 Jul 93 08:00:39 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
The fact that portions of the Internet are funded with government money
is certainly an important point.
Another issue which, I hope, does not get lost, is that most Internet
usage is funded on a usage-INsensitive manner. Even when the funding
is private, users tend to pay for a connection and get to use as much
of it as they are able, with no incremental charges. I believe that this
is very important to maintain -- to the extent reasonable -- even as we
shift to fully-private/commercial funding. Usage-sensitive payment tends
to cause folks to be overly concerned with limiting their use.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05605;
22 Jul 93 11:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05598;
22 Jul 93 11:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15339;
22 Jul 93 11:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05585;
22 Jul 93 11:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05540;
22 Jul 93 11:10 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa15307;
22 Jul 93 11:10 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA23842; Thu, 22 Jul 93 08:10:35 -0700
Message-Id: <9307221510.AA23842 at Mordor.Stanford.EDU>
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: uk national press...on IPng
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Thu, 08 Jul 93 16:26:56 +0100. <9307081126.aa13167 at CNRI.Reston.VA.US>
Date: Thu, 22 Jul 93 08:10:34 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
Houldsworth says: ``the matter will be decided ultimately by the
weight of opinion amongst Internet members''. Opinions can be emailed
to the Internet Architectural Board's network Operations working
party': noop at merit.edu. "
This is the second time that we have seen OSI-based advocates being
directed to register their opinions with the noop list. Who is
given them this suggestion and why? Surely such folk know that that is
most definitely NOT the way we work in the IETF and that the end effect
of that sort of lobbying is to alienate factions.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05850;
22 Jul 93 11:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05843;
22 Jul 93 11:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16216;
22 Jul 93 11:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05831;
22 Jul 93 11:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05803;
22 Jul 93 11:27 EDT
Received: from ivory.educom.edu by CNRI.Reston.VA.US id aa16038;
22 Jul 93 11:27 EDT
Received: by ivory.educom.edu (5.64/A/UX-3.00)
id AA00512; Thu, 22 Jul 93 11:30:36 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike Roberts <roberts at ivory.educom.edu>
Message-Id: <9307221530.AA00512 at ivory.educom.edu>
Subject: Unpriced Doesn't Mean Free
To: ietf at CNRI.Reston.VA.US
Date: Thu, 22 Jul 93 11:30:36 EDT
X-Mailer: ELM [version 2.3 PL0]
There's a thread of irresponsibility that runs through some of the recent
postings about "free" use of the Internet. We all know it isn't free,
and most of know that very little of the total cost of the Internet -
WAN's, LAN's and workstations - is paid by the federal taxpayers.
Well over 80% of the current cost of the Internet, and that's several
hundreds of millions of dollars a year, is paid by employers in
research, education and the private sector. The fact that they
generally choose not to charge back the associated costs to company
cost centers and harrass us all with infernal budget justifications
and submissions shouldn't be taken to mean that there is not a
company concern for intelligent use of the resource. If the people
who know the most about the net can't be trusted to use it well,
then there is a nasty day of retribution coming when the auditors
and accountants are sic'd on us. Worse yet, some of the faithful
will be put to work writing packet accounting and audit trail routines.
And there is a second order effect as well. The press picks up this
insider chit chat and by the time it gets to Capitol Hill, we're
all a bunch of irresponsible kids passing pornography around, espec
now that we have Internet fax. In the current highly competitive
budget situation, little things make a difference....
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06554;
22 Jul 93 12:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06547;
22 Jul 93 12:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18112;
22 Jul 93 12:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06535;
22 Jul 93 12:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06437;
22 Jul 93 12:09 EDT
Received: from faline.bellcore.com by CNRI.Reston.VA.US id aa17927;
22 Jul 93 12:09 EDT
Received: by faline.bellcore.com (4.1/4.7)
id <AA25998> for ietf at CNRI.Reston.VA.US; Thu, 22 Jul 93 12:09:56 EDT
Date: Thu, 22 Jul 93 12:09:56 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Liang T. Wu" <ltwu at faline.bellcore.com>
Message-Id: <9307221609.AA25998 at faline.bellcore.com>
To: Christian.Huitema at sophia.inria.fr, rlstewart at eng.xyplex.com
Subject: Re: Posting by Goodfellow
Cc: ietf at CNRI.Reston.VA.US
Being a new convert to the Internet world, I was fascinated by the fixed billing
aspect of the Internet. However, upon further look, I don't see the
difference between the telephone billing model and the Internet model.
There are cost related to transport and to processing. Transport tends
to be usage sensitive, depending on whether you are using leased line,
dial-ups, long-haul vs. short-haul. Processing, such as routing or database
look-ups tends to be flat cost. Granted that a mid-level generally charge
you fixed billing, based on the general traffic volume instead of per call.
But it is also your responsibility to pay for the access line, whether it's
a leased T1 or a dial-up. It would be nice if someone can sort out all this
mess to unbundle the cost associated with providing Internet service, possibly
based on costs associated with different layers of the protocol stack. This
information could become the rational basis for commercialized Internet.
Liang Wu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07304;
22 Jul 93 13:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07297;
22 Jul 93 13:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22100;
22 Jul 93 13:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07284;
22 Jul 93 13:35 EDT
Received: from apache.telebit.com by IETF.CNRI.Reston.VA.US id aa07243;
22 Jul 93 13:34 EDT
Received: from america.Sunnyvale.Telebit.CO (america-bb.sunnyvale.telebit.com) by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718)
id AA01984 to ietf at IETF.CNRI.Reston.VA.US; Thu, 22 Jul 93 10:34:50 PDT
Received: from napa.Sunnyvale.Telebit.COM by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718)
id AA14574 to ietf at IETF.CNRI.Reston.VA.US; Thu, 22 Jul 93 10:34:48 PDT
Date: Thu, 22 Jul 93 10:34:48 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steven Bjork <bjork at america.sunnyvale.telebit.com>
Message-Id: <9307221734.AA14574 at america.Sunnyvale.Telebit.COM>
Received: by napa.Sunnyvale.Telebit.COM (4.1/SMI-4.1)
id AA16206; Thu, 22 Jul 93 10:34:48 PDT
To: ietf at IETF.CNRI.Reston.VA.US
Subject: Network benefits, was Re: Who Pays for What
Newsgroups: telebit.netblazer.ietf
In-Reply-To: <9307221647.AA02212 at xap.xyplex.com>
References: <9307221341.AA01138 at iastate.edu>
Organization: Telebit Corporation; Sunnyvale, CA, USA
Cc:
In article <9307221647.AA02212 at xap.xyplex.com> you write:
[someone else on who pays for, versus users of, internet]
>>But do you feel guilty when you use the "free" highway system?
>Nope. I have a better sense of how that's paid for, and I've bought most of
>the argument about its widespread common benefit to justify paying for it
>with taxes.
>In terms of the entire U.S. (world?) population, the Internet benefits only a
>small percentage. If that benefit every approaches universality, then taxes
>rather than usage fees become more appropriate.
I'd say that from a broader perspective, the research done
at the Universities and Medical facilities that use the
Internet end up benefitting all. You don't see a produce
truck delivering lettuce on the Internet, but the benefits
are there.
With the White House making a splashy move into access via
Internet, I feel this can only motivate others into doing so.
Thus, the benefits are spreading.
After all, you still have to pay for your auto and gas,
with regards to the hiway analogy. Likewise, there's
the access charges for Internet connection. So I'd not
say it's "free."
../Steven
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07554;
22 Jul 93 13:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07547;
22 Jul 93 13:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22983;
22 Jul 93 13:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07535;
22 Jul 93 13:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07496;
22 Jul 93 13:51 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22922;
22 Jul 93 13:51 EDT
Received: from relay.philips.nl by venera.isi.edu (5.65c/5.61+local-12)
id <AA07323>; Thu, 22 Jul 1993 10:51:37 -0700
Return-Path: <geertj at ica.philips.nl>
Received: from philica.ica.philips.nl ([130.144.131.1]) by relay.philips.nl with SMTP (5.65c/smail2.5/05-10-87);
id AA13514; Thu, 22 Jul 1993 19:48:47 +0200
Received: from ica04.ica.philips.nl by philica.ica.philips.nl;
id AA13043; Thu, 22 Jul 93 19:51:32 +0200
Received: by ica04.ica.philips.nl
id AA07383; Thu, 22 Jul 93 19:51:32 +0200
Message-Id: <9307221751.AA07383 at ica04.ica.philips.nl>
To: ietf at isi.edu
Cc: internet-drafts at CNRI.Reston.VA.US
Subject: Proposed change to Internet Draft Requirements
Date: Thu, 22 Jul 1993 19:51:31 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Geert Jan de Groot <geertj at ica.philips.nl>
I recently found out that I was commenting to an author about a draft that
was expired. I should have looked better, but I found:
-r--r--r-- 1 1620 218288 Dec 9 1992 draft-ietf-dns-mibext-05.ps
-rw-rw-rw- 1 1620 257 Jun 15 00:18 draft-ietf-dns-mibext-05.txt
I was tired, so I printed the postscript file, looked at it, and gave
comments, which were useless.
There are three problems here:
1. While the text file was expired, the postscript file is still here
(on ds.internic.net, and on nic.nordu.net);
2. It is not easy to see that the draft has expired, except for the
large difference in size and the 'suspect' short text file.
3. From my printed, postscript (which appears to have been expired),
it is not easy to see from where it came.
I propose three changes:
1. Would it be a good idea to name the expire note
draft-ietf-dns-mibext-05.expired instead of .txt?
This way, by looking at the name, one could see that the draft is
no longer effective.
2. Remove _all_ versions of a draft text once it has expired
(both ps and txt);
3. In the required 'status of this memo', add a sentence telling the
exact file name of the draft. The RFC number of and RFC is in the
RFC itself; why not use this with drafts?
Because of the format of some drafts, I cannot add the name myself
because this would usually make the page too long for the paper.
There are a number of dead ps drafts out there. Possible candidates are:
draft-crocker-ip-encaps-01.ps
draft-hardcastle-mapping-00.ps
draft-ietf-dns-mibext-05.ps
draft-ietf-822ext-text-enriched-00.ps
draft-ietf-mhsds-convert-00.ps
draft-ietf-mhsds-infotree-02.ps
draft-ietf-mhsds-mhsprofile-02.ps
draft-ietf-mhsds-mhsuse-02.ps
draft-ietf-mhsds-routdirectory-02.ps
draft-ietf-mhsds-subtrees-02.ps
draft-ietf-mhsds-supmapping-02.ps
draft-ietf-nntp-news-01.ps
draft-ietf-tuba-address-00.ps
draft-rosenbaum-dns-storage-00.ps
so it looks like this is not an incident, but a generic problem.
Because of my thin pipe to the Internet (9600), I did not check the
contents of each corresponding .txt file. Maybe someone with better
connectivity can.
Comments?
Geert Jan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07628;
22 Jul 93 13:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07621;
22 Jul 93 13:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23240;
22 Jul 93 13:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07609;
22 Jul 93 13:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07576;
22 Jul 93 13:55 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa23161; 22 Jul 93 13:55 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Thu, 22 Jul 93 10:55:21 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA01475; Thu, 22 Jul 93 10:55:55 PDT
Date: Thu, 22 Jul 93 10:55:55 PDT
Message-Id: <9307221755.AA01475 at mel-brooks.empirical.com>
To: jhaverty at us.oracle.com
Subject: How much did it cost to build "the Internet"? Was: Re: Posting by Goodfellow
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: carl at trystero.malamud.com, ietf at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
> Carl - how do you know the Internet can provide a service "efficiently"? If
> the Internet were a business and had to charge for a fax, how much would it
> charge compared to a phone call fax?
To make that computation we would have to know how much it cost to
build the internet. I wonder whether we could make even an order of
magnitude guess as to the dollars that have been invested in
hardware, software, operations, etc, since "the beginning", into the
infrastructure we call "the Internet"?
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08462;
22 Jul 93 14:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08455;
22 Jul 93 14:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25030;
22 Jul 93 14:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08442;
22 Jul 93 14:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08407;
22 Jul 93 14:24 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa24810;
22 Jul 93 14:24 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA01020>; Thu, 22 Jul 1993 11:24:46 -0700
Date: Thu, 22 Jul 1993 11:24:46 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Braden <braden at isi.edu>
Message-Id: <199307221824.AA01020 at zephyr.isi.edu>
To: john at iastate.edu, dcrocker at mordor.stanford.edu
Subject: Re: Posting by Goodfellow
Cc: ietf at CNRI.Reston.VA.US, rlstewart at eng.xyplex.com
*>
*> The fact that portions of the Internet are funded with government money
*> is certainly an important point.
*>
*> Another issue which, I hope, does not get lost, is that most Internet
*> usage is funded on a usage-INsensitive manner. Even when the funding
*> is private, users tend to pay for a connection and get to use as much
*> of it as they are able, with no incremental charges. I believe that this
*> is very important to maintain -- to the extent reasonable -- even as we
*> shift to fully-private/commercial funding. Usage-sensitive payment tends
*> to cause folks to be overly concerned with limiting their use.
*>
*> Dave
*>
Dave Crocker,
Unfortunately, it will probably not be possible to maintain usage
INsensitive charging in the future Internet that provides resource
reservation for realtime service -- voice, video, etc.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08716;
22 Jul 93 14:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08712;
22 Jul 93 14:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26455;
22 Jul 93 14:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08696;
22 Jul 93 14:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08691;
22 Jul 93 14:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26445;
22 Jul 93 14:48 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08683;
22 Jul 93 14:48 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-ppp at ucdavis.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Compressing IPX Headers Over WAN Media (CIPX) to
Proposed Standard
Date: Thu, 22 Jul 93 14:48:29 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9307221448.aa08683 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider <draft-ietf-pppext-cipx-04.txt>
"Compressing IPX Headers Over WAN Media (CIPX)" for the status of
Proposed Standard.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any comments to
the iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists
by 5 August.
John Stewart
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08961;
22 Jul 93 14:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08952;
22 Jul 93 14:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26746;
22 Jul 93 14:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08931;
22 Jul 93 14:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08822;
22 Jul 93 14:50 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa26653;
22 Jul 93 14:50 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA28254; Thu, 22 Jul 93 11:51:32 -0700
Message-Id: <9307221851.AA28254 at Mordor.Stanford.EDU>
To: Bob Braden <braden at isi.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Posting by Goodfellow
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Thu, 22 Jul 93 11:24:46 -0700. <199307221824.AA01020 at zephyr.isi.edu>
Date: Thu, 22 Jul 93 11:51:32 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
Bob, et al,
We well might not be able to sustain across-the-board flat-fee
charging.
But I hope that we can develop something that is along the lines of
the typical home-use telephone model, which has a fixed-fee core.
And usage-sensitive pricing for extra services.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08992;
22 Jul 93 14:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08985;
22 Jul 93 14:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26766;
22 Jul 93 14:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08963;
22 Jul 93 14:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08841;
22 Jul 93 14:51 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa26670;
22 Jul 93 14:51 EDT
Received: from interlock.ans.net by venera.isi.edu (5.65c/5.61+local-12)
id <AA09508>; Thu, 22 Jul 1993 11:51:50 -0700
Received: by interlock.ans.net id AA17997
(InterLock SMTP Gateway 1.1 for ietf at isi.edu);
Thu, 22 Jul 1993 14:46:51 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Thu, 22 Jul 1993 14:46:51 -0400
Message-Id: <199307221847.AA06886 at home.ans.net>
To: Geert Jan de Groot <geertj at ica.philips.nl>
Cc: ietf at isi.edu, internet-drafts at CNRI.Reston.VA.US
Subject: Re: Proposed change to Internet Draft Requirements
In-Reply-To: (Your message of Thu, 22 Jul 93 19:51:31 O.)
<9307221751.AA07383 at ica04.ica.philips.nl>
Date: Thu, 22 Jul 93 14:47:09 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Phill Gross <pgross at ans.net>
I propose three changes: ....
Geert Jan,
These are good suggestions. You seem to have found a hole in
our process. I'll make sure the Secretariat looks at the problem
and your suggestions.
(Postscript documents have been a problem from the beginning!)
Phill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09286;
22 Jul 93 15:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09279;
22 Jul 93 15:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27735;
22 Jul 93 15:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09267;
22 Jul 93 15:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09220;
22 Jul 93 15:08 EDT
Received: from sadye.emba.uvm.edu by CNRI.Reston.VA.US id aa27666;
22 Jul 93 15:08 EDT
Received: by sadye.emba.uvm.edu id AA00783
(5.65/1.23); Thu, 22 Jul 93 15:09:03 -0400
Date: Thu, 22 Jul 93 15:09:03 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: wollman at uvm-gen.emba.uvm.edu
Message-Id: <9307221909.AA00783 at sadye.emba.uvm.edu>
To: Bob Braden <braden at isi.edu>
Cc: dcrocker at mordor.stanford.edu, ietf at CNRI.Reston.VA.US, john at iastate.edu,
rlstewart at eng.xyplex.com
Subject: Re: Posting by Goodfellow
In-Reply-To: <199307221824.AA01020 at zephyr.isi.edu>
References: <199307221824.AA01020 at zephyr.isi.edu>
(I'm not sure where followups should go, but the IETF list is probably
not a good place. Think before you press `F'.)
<<On Thu, 22 Jul 1993 11:24:46 -0700, Bob Braden <braden at isi.edu> said:
> Unfortunately, it will probably not be possible to maintain usage
> INsensitive charging in the future Internet that provides resource
> reservation for realtime service -- voice, video, etc.
Currently, this university pays for its Internet connection based on a
combination of bandwidth and usage, in a manner not uncommon among
smaller sites. We pay some fixed amount for our 128-kbit service,
with extra charges if we exceed that usage for a significant period of
time. (That is, we get 256-kbit latency, but can only use 50% of that
capacity over a period of time.)
It would seem to me that, once we have resource reservation, we will
be looking at a similar scheme for flow charging as well. That is to
say, our service (which I hope will be at least T-1 by then) will
include in the basic price a certain amount of simultaneous reserved
traffic, and attempts to reserve more will either result in someone
being charged for it (if they are willing to pay), or have the
reservation request rejected by an intermediate switch (otherwise).
Does this seem reasonable?
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman at emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman | It is a bond more powerful than absence. We like people
UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09910;
22 Jul 93 15:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09903;
22 Jul 93 15:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29848;
22 Jul 93 15:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09891;
22 Jul 93 15:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09799;
22 Jul 93 15:42 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa29713;
22 Jul 93 15:42 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA02574>; Thu, 22 Jul 1993 12:43:06 -0700
Date: Thu, 22 Jul 1993 12:43:06 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Braden <braden at isi.edu>
Message-Id: <199307221943.AA02574 at zephyr.isi.edu>
To: braden at isi.edu, dcrocker at mordor.stanford.edu
Subject: Re: Posting by Goodfellow
Cc: ietf at CNRI.Reston.VA.US
*>
*> Bob, et al,
*>
*> We well might not be able to sustain across-the-board flat-fee
*> charging.
*>
*> But I hope that we can develop something that is along the lines of
*> the typical home-use telephone model, which has a fixed-fee core.
*> And usage-sensitive pricing for extra services.
*>
*> Dave
*>
Dave,
I agree.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10496;
22 Jul 93 16:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10489;
22 Jul 93 16:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01208;
22 Jul 93 16:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10477;
22 Jul 93 16:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10385;
22 Jul 93 16:08 EDT
Received: from eco.twg.com by CNRI.Reston.VA.US id aa01121; 22 Jul 93 16:07 EDT
Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $)
id AA06955; Thu, 22 Jul 93 16:09:07 -0400
Message-Id: <9307222009.AA06955 at eco.twg.com>
Received: from apache.twg.com by apache.twg.com id <11669-0 at apache.twg.com>; Thu, 22 Jul 1993 13:07:52 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Herron <david at twg.com>
Subject: Re: Posting by Goodfellow
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: Bob Braden <braden at isi.edu>,
IPM Return Requested <ietf at CNRI.Reston.VA.US>
Date: Thu, 22 Jul 93 13:07:51 PDT
In-Reply-To: Your message of Thu, 22 Jul 93 11:51:32 -0700.<9307221851.AA28254 at Mordor.Stanford.EDU>
Sensitivity: Personal
Conversion: Prohibited
Conversion-With-Loss: Prohibited
Encoding: 50 TEXT , 4 TEXT
>Bob, et al,
>
>We well might not be able to sustain across-the-board flat-fee
>charging.
Hmm.. We already have usage sensitive fees in at least a few extremities
of the network. My Internet connection to my home computer (davids.mmdf.com)
costs me $17/mo & $2/hr. For which cost I can access any TCP service on the
easily reachable part of the Internet, so long as I wish to pay for the
connect time.
The primary use for this is e-mail delivery to home and there is an
architecture problem in that the MTA my service provider runs is of the
traditional model which continually scans its queue to see about delivering
mail. So when my system connects the server has no idea I'm there and
in order for mail to flow I have to wait for them to take notice (by atempting
to deliver a message). This can sometimes take a long time, depending on
the state of their queue, costing me a bit of money.
To solve this problem I wrote a little daemon which can be poked to say
that my system is now connected, and it turns around to start up some
process (/usr/lib/sendmail -Rdavids.mmdf.com).
Usage insensitive pricing is real nice. But it also seems to have allowed
for abominations like some of Usenet's picture-oriented groups to blow up
out of proportion. So in some ways it isn't nice.
One last point. Someone asked about the cost for building all the wonderful
infrastructure out there. Part of the infrastructure is owned by the
organizations who are users. For instance I frequently ftp into .edu or
.com machines owned by organizations who are `end users' of the network
rather than `network providers'. The end user systems generally have more
interesting software toys to play with than the network providers ...
For many of those systems, they are ones which the organization would have
bought anyway. After all, they need to have computing facilities regardless
of whether they are network connected instead. So much of that infrastructure
should not be counted if you wanted to calculate the cost to taxpayers.
(And taxpayers of which countries for that matter!)
A counter argument is that for an organization connected to the Internet, they
generally require more machines. Usenet, for instance, tends to take up
an entire machine (and if not today, then next year...).
<- David Herron <david at twg.com> (work) <david at davids.mmdf.com> (home)
<-
<- All hard work brings a profit, but mere talk leads only to poverty.
<- Proverbs 14:23
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11366;
22 Jul 93 17:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11359;
22 Jul 93 17:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04404;
22 Jul 93 17:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11347;
22 Jul 93 17:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11309;
22 Jul 93 17:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04327;
22 Jul 93 17:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11304;
22 Jul 93 17:11 EDT
To: karl at empirical.com
cc: jhaverty at us.oracle.com, carl at trystero.malamud.com,
ietf at CNRI.Reston.VA.US
Subject: Re: How much did it cost to build "the Internet"? Was: Re: Posting by Goodfellow
In-reply-to: Your message of "Thu, 22 Jul 93 10:55:55 PDT."
<9307221755.AA01475 at mel-brooks.empirical.com>
Date: Thu, 22 Jul 93 17:11:22 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9307221711.aa11304 at IETF.CNRI.Reston.VA.US>
Karl,
we even have problems figuring out the annual cost of operations
let alone sunk capital!
Vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11523;
22 Jul 93 17:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11516;
22 Jul 93 17:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04891;
22 Jul 93 17:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11501;
22 Jul 93 17:22 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11468;
22 Jul 93 17:20 EDT
To: Steven Bjork <bjork at america.sunnyvale.telebit.com>
cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Network benefits, was Re: Who Pays for What
In-reply-to: Your message of "Thu, 22 Jul 93 10:34:48 PDT."
<9307221734.AA14574 at america.Sunnyvale.Telebit.COM>
Date: Thu, 22 Jul 93 17:20:46 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9307221720.aa11468 at IETF.CNRI.Reston.VA.US>
Although it was once the case that the defense department
paid for most of the cost of the Internet (when ARPANET was
the primary backbone network), this hasn't been true for
a long time. Even NSF's important contribution to the cost
of the NSFNET backbone is relatively modest compared to the
costs borne by the aggregate local area network users
at universities and businesses (I mean here that the local
capital and operational costs are largely borne by the
business or institution).
It is fair to ask who sees what bills and pays the costs.
An increasing number of private users see costs from the
dial-up service providers. Businesses and institutions and
even government agencies see costs for access as well as
local net operations. Many individual users are relatively
oblivious to these invoices and think of the service as
a free good, despite the facts.
TANSTAAFL.
Vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11899;
22 Jul 93 17:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11892;
22 Jul 93 17:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05878;
22 Jul 93 17:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11879;
22 Jul 93 17:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11848;
22 Jul 93 17:43 EDT
Received: from BBN.COM by CNRI.Reston.VA.US id aa05839; 22 Jul 93 17:43 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Cyndi Mills <cmills at bbn.com>
Subject: Re: Posting by Goodfellow
To: ietf at CNRI.Reston.VA.US, john at iastate.edu
In-Reply-To: <9307221341.AA01138 at iastate.edu>
Date: Thu, 22 Jul 93 15:59:16 EDT
Mail-System-Version: <BBN/MacEMail_v1.6 at BBN.COM>
Message-ID: <9307221743.aa05839 at CNRI.Reston.VA.US>
Re: using the Internet to get "free" fax transmission.
>But do you feel guilty when you use the "free" highway system?
>
>Nothing is really free, we pay for everything -- the only difference
>is whether the paying is obvious or not.
>
Currently an individual can only drive ONE vehicle (one packet) at a
time on the highway system, and it can only be on ONE road or
intersection at a time, so individual (ab)use of the free highway system
has a built-in upper limit. Even if I drive illegally, violating custom
or law, this upper limit of "one person, one vehicle, one location" at a
time still applies. If I have an accident, I might close or congest a
portion of the highway system, but not the whole system nationwide. For
congestion to occur, causing incremental investment, e.g. new highways
and lanes, many individuals must cooperate in raising the demand.
Truckers also pay extra taxes to compensate for increased wear and tear.
On the internet "highway", however, I can simultaneously drive as many
packets from as many sources as I can beg borrow or steal to as many
destinations as I can address. From my 2400 bps dial-up line I can
start many remote processes which use multiple megabit resources
simultaneously over multiple lines and vast distances. One individual
can saturate a resource/line designed to be shared by many users of
"normal" appetites, individually creating a demand for significant
incremental investment.
A lot depends on how much of the shared resource one individual can
consume as well as what it costs. What is the incremental
cost/aggravation/loss of compensating for an individual who takes more
than a fair share of a limited resource?
Yes, we need to design policies which encourage use and strive for
ubiquitous connectivity, like roads and telephone. Yet we should also
be able to identify and discourage abuses. I think we also need to
consider financially acceptable means of coping with unusual excesses
and common differences in level of use.
Who pays how much of the incremental cost of use?
Cyndi
-----------------------
Imagine changing the telephone system to allow any human being anywhere,
adult or child, to anonymously ring any or all of the telephones in the
world simultaneously at no charge.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab12010;
22 Jul 93 17:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11999;
22 Jul 93 17:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06074;
22 Jul 93 17:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11978;
22 Jul 93 17:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11945;
22 Jul 93 17:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06059;
22 Jul 93 17:48 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11938;
22 Jul 93 17:48 EDT
To: Bob Stewart <rlstewart at eng.xyplex.com>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: Posting by Goodfellow
In-reply-to: Your message of "Thu, 22 Jul 93 09:20:32 CDT."
<9307221420.AA01615 at xap.xyplex.com>
Date: Thu, 22 Jul 93 17:48:35 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9307221748.aa11938 at IETF.CNRI.Reston.VA.US>
Bob,
by this time you probably have received some mail trying to
explain that the Internet is anything but free, even if you
don't see any of the bills. I imagine that Xyplex pays one
of the regional carriers for access to Internet and for the
access circuit to the nearest POP of the regional Internet
service provider.
Mike Roberts' point about the collateral damage caused by
leading people to think that the Internet is paid for by
the US Government or mostly by taxes should be well taken.
The bulk of the costs, even for backbone service, could out
of charges to users. The transit service networks pay their
costs, even for CIX and GIX facilities. The only facility
which has any continuing short term subsidy is the NSFNET
backbone. The ESNET and NSINET (DOE and NASA) are not transit
nets for general use. There is a diminishing subsidy for
the regional nets - most of which have moved to full self-
support.
Hope this is helpful.
vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12438;
22 Jul 93 18:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12431;
22 Jul 93 18:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07829;
22 Jul 93 18:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12416;
22 Jul 93 18:24 EDT
Received: from xap.xyplex.com by IETF.CNRI.Reston.VA.US id aa12393;
22 Jul 93 18:23 EDT
Received: by xap.xyplex.com id <AA09330 at xap.xyplex.com>; Thu, 22 Jul 93 20:23:20 -0500
Date: Thu, 22 Jul 93 20:23:20 -0500
Message-Id: <9307230123.AA09330 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: "Vinton G. Cerf"'s message of Thu, 22 Jul 93 17:20:46 -0400 <9307221720.aa11468 at IETF.CNRI.Reston.VA.US>
Subject: Re: Network benefits, was Re: Who Pays for What
So what it boils down to is that the Internet is truly the world's largest
friendly, cooperative by-choice venture. I know, countries are bigger, but
most people are part of a country by default, and it was handed to them by
their parents...
Actually, the Internet is sort of like a country.
My not-so-humble opinion is that it's good that the Internet is largely
supported by its users' organizations, and the more it's that way the better.
It's a cooperative organism, with no central control. Actually, it's more
like an ecology.
Neat.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12527;
22 Jul 93 18:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12520;
22 Jul 93 18:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07952;
22 Jul 93 18:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12506;
22 Jul 93 18:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12481;
22 Jul 93 18:28 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa07907;
22 Jul 93 18:28 EDT
Received: by xap.xyplex.com id <AA09349 at xap.xyplex.com>; Thu, 22 Jul 93 20:28:29 -0500
Date: Thu, 22 Jul 93 20:28:29 -0500
Message-Id: <9307230128.AA09349 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: "Vinton G. Cerf"'s message of Thu, 22 Jul 93 17:48:35 -0400 <9307221748.aa11938 at IETF.CNRI.Reston.VA.US>
Subject: Re: Posting by Goodfellow
Vint,
Actually, one of my early messages, if not my first, obliquely said that I'm
aware that Xyplex pays for my "free" access. What was news to me, and is
therefore probably news to lots of other folks, is how little government
support there is for infrastructure. To redundantly repeat what I just said
again in another message before, that's the really fine news.
Rather than see more government support of the Internet, I'd prefer to see
less. Let's keep doing it ourselves. Governments generally only screw things
up. The Internet is an outstanding example of a major entity with minimum
central control. Anarchy at its finest.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12845;
22 Jul 93 19:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12838;
22 Jul 93 19:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09359;
22 Jul 93 19:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12826;
22 Jul 93 19:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12801;
22 Jul 93 19:03 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa09349;
22 Jul 93 19:03 EDT
Received: from itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-12)
id <AA17919>; Thu, 22 Jul 1993 16:04:10 -0700
Received: from ascent.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA24164; Thu, 22 Jul 93 19:04:07 EDT
Date: Thu, 22 Jul 93 19:04:07 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Randall Atkinson <atkinson at itd.nrl.navy.mil>
Message-Id: <9307222304.AA24164 at itd.nrl.navy.mil>
To: ietf at isi.edu
Subject: Re: UK nat'l press and IPtng
Dave,
If you are only aware of _2_ efforts to advertise the noop list as
the place to put in two cents in favour of TUBA, then you are among
the blessed. Rest assured that the NOISEnet (USENET :-) has had many
more postings suggesting that the way for CLNP to be IP:TNG was to
"lobby the IETF" to make it so.
For my part I find it quite odd that people would ever pick some
technology and lobby for it on political grounds. It seems to me
that the rational and scientific way to proceed when faced with
a technical problem is to identify as many potential solutions as
possible and then select the most technically promising one that
appears sufficiently feasible.
Now I left industry for a research lab precisely because I find many
parts of that world to be irrational, so my views are probably quite
unorthodox in the minds of those advocating "noop lobbying". I only
hope my views are in the mainstream of the IETF. When they become
fringe views in the IETF, it will be time for me to leave...
Ran
atkinson at itd.nrl.navy.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12899;
22 Jul 93 19:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12892;
22 Jul 93 19:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09410;
22 Jul 93 19:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12880;
22 Jul 93 19:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12857;
22 Jul 93 19:05 EDT
Received: from gatekeeper.oracle.com by CNRI.Reston.VA.US id aa09387;
22 Jul 93 19:05 EDT
Received: from rivendell.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
id AA29718; Thu, 22 Jul 93 16:05:38 PDT
Received: by rivendell.us.oracle.com (5.59.11/37.7)
id AA08619; Thu, 22 Jul 93 16:04:39 PDT
Message-Id: <9307222304.AA08619 at rivendell.us.oracle.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jack Haverty <jhaverty at us.oracle.com>
To: Cyndi Mills <cmills at bbn.com>
Cc: ietf at CNRI.Reston.VA.US, john at iastate.edu
Subject: Re: Posting by Goodfellow
In-Reply-To: Your message of Thu, 22 Jul 93 15:59:16 -0400.
<9307221743.aa05839 at CNRI.Reston.VA.US>
Date: Thu, 22 Jul 93 16:04:38 PDT
Cyndi makes a good point - users can abuse the system and there should be
ways to address that reality. I've been noticing a related effect --
technology can itself abuse the system, or at least assist users in doing so
unwittingly. For example, I didn't mean to annoy thousands of people with
the message that started this, and I wish I had a mail system that had said
"You are about to send this message to at least 1000 recipients. OK?"
This is not a hypothetical problem. Over the last several months, we've
tracked down a situation where lots of people here were experiencing
performance problems and long delays, not across the Internet but just across
our campus LAN (FDDI and Ethernets, lots of them). We've traced this down to
the fact that we've introduced lots of very high-performance workstations --
each of which is fully capable of saturating a LAN, as well as LOCKING OUT
service to other users on less capable machines. So you don't have to go to
the trouble of starting up hundreds of processes to cause a problem -- simply
starting a large file transfer or compilation on a single workstation as you
leave for lunch will do the trick. And there's no "knob" for the user even
to tell the machine to be a good citizen and "drive slow".
What do you do about this? Either make sure that all components in your
network path are as fast as the fastest component (think about this), or go
find a vendor with SLOWER technology (I can see the marketing brochures now).
It's kind of like if you had people buying Formula-1 race cars for use on the
highway system, and they came from the factory with the gas pedal welded to
the floor. It will be interesting to see what happens to the Internet as
end-sites upgrade their access connections that are currently holding these
beasts at bay.
The point? With a bit more cost awareness and fair-sharing attention,
vendors might build technology that didn't accidentally make users into bad
citizens.
Jack
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13006;
22 Jul 93 19:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13002;
22 Jul 93 19:11 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa09525;
22 Jul 93 19:11 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA02464; Thu, 22 Jul 93 18:12:15 CDT
Received: by hemlock.cray.com
id AA12949; 4.1/CRI-5.6; Thu, 22 Jul 93 18:12:10 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
id AA12945; 4.1/CRI-5.6; Thu, 22 Jul 93 18:12:05 CDT
Received: from rockall.qdeck.com (qdeck.com) by cray.com (4.1/CRI-MX 2.19)
id AA02459; Thu, 22 Jul 93 18:12:04 CDT
Received: from angel.qdeck.com by rockall.qdeck.com (4.1/SMI-4.1)
id AA08690; Thu, 22 Jul 93 16:11:17 PDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jordan Brown <jbrown at qdeck.com>
To: stevea at lachman.com, telnet-ietf at cray.com
Subject: Environment Option
X-Mailer: ScoMail 1.0
Date: Thu, 22 Jul 1993 16:06:22 -0700 (PDT)
Message-Id: <9307221606.aa21460 at angel.qdeck.com>
> 1. Assign a new option value to the Environment option.
> -- this would primarily be done for three reasons
> A. Enable detection of up-to-date systems so that the heuristics
> for interoperability could be safely avoided.
> B. Ensure that over time the old option will die out and
> avoid dragging the heuristics along forever.
> C. Implementations that pre-date the introduction of USERVAR
> will be confused if they ever receive a USERVAR, so in
> some sense there is an additional problem, even if the
> heuristics to detect the VAR/VALUE swap are used
I favor this approach because it will (one would hope) tend to lead to
a well-defined deterministic protocol, not one based on imperfect
heuristics.
In other words, the situation now is a mess and can't really be cleaned up.
Throw it away (with perhaps a bit of work for backwards compatibility)
and make the standard clean.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13153;
22 Jul 93 19:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13146;
22 Jul 93 19:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09808;
22 Jul 93 19:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13134;
22 Jul 93 19:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13097;
22 Jul 93 19:16 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa09777;
22 Jul 93 19:15 EDT
Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA03059 (mail destined for ietf at CNRI.Reston.VA.US) on Thu, 22 Jul 93 19:16:16 -0400
Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0)
id AA12659; Thu, 22 Jul 93 19:08:11 -0400
Message-Id: <9307222308.AA12659 at expresso.bunyip.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Peter Deutsch <peterd at bunyip.com>
Date: Thu, 22 Jul 1993 19:08:10 -0400
In-Reply-To: Cyndi Mills's message as of Jul 22, 15:59
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: Cyndi Mills <cmills at bbn.com>, ietf at CNRI.Reston.VA.US, john at iastate.edu
Subject: Saturating the links... (was: Re: Posting by Goodfellow)
[ Somebody wrote: ]
. . .
> Currently an individual can only drive ONE vehicle (one packet) at a
> time on the highway system, and it can only be on ONE road or
> intersection at a time, so individual (ab)use of the free highway system
> has a built-in upper limit. Even if I drive illegally, violating custom
> or law, this upper limit of "one person, one vehicle, one location" at a
> time still applies. . . .
And any user with access to a single 56k link onto the
network can only generate 56k of data onto the backbone
from that connection. True, if a user can generate traffic
from three such connections then they can potentially
generate up to three times the traffic of a single link,
but only by taking away from the generating capacity of
other users of the same links. That seems to imply that we
should be counting not users, but rather functional network
endpoint connections and their aggregate bandwidth.
Put another way, the important metric here is not the
number of cars a driver owns (ie. his or her internal data
generating capacity), but the number of simultaneous cars
they can feed onto the road system (ie. the bandwidth in
cars per connection). It doesn't matter if there are
twelve drivers in a house, if there is only one car that
can be driven out of the driveway.
> On the internet "highway", however, I can simultaneously drive as many
> packets from as many sources as I can beg borrow or steal to as many
> destinations as I can address. From my 2400 bps dial-up line I can
> start many remote processes which use multiple megabit resources
> simultaneously over multiple lines and vast distances. One individual
> can saturate a resource/line designed to be shared by many users of
> "normal" appetites, individually creating a demand for significant
> incremental investment.
Yes, a single user can be responsible for the generation
of a multitude of packets, but each network _connection_
can only generate a bounded and finite amount of traffic
and it seems to me that it is this generating capacity
that determines if the overall system will saturate. A 56k
connection cannot source or sink more than 56k of data, no
matter how hard we try so even if a single user is
responsible for simultaneously saturating six such links,
that does not mean that any more generating capacity has
been added or traffic can be generated than was attached.
All it means is that a single user is dominating six
endpoint links. Would we be any better of if six
individuals dominated six endpoint links?
Now, we don't want to try and engineer a national
backbone that is capable of carrying the simple sum of the
bandwidth of all endpoint connections, since that seems a
tad wasteful, but this does suggest that doomsday
scenarios that suggest that a single user can destroy the
Internet are perhaps a little too extreme. The issue is
still engineering for average use and making sure we have
a handle on how much traffic an average _connection_ (not
an average user) will feed into the data stream.
> A lot depends on how much of the shared resource one individual can
> consume as well as what it costs. What is the incremental
> cost/aggravation/loss of compensating for an individual who takes more
> than a fair share of a limited resource?
If I buy a single 56k link, and use the total capacity of
my 56k link, I don't see that I have really performed
anything like a denial of service attack on my neighbors.
The engineers who spec'ed out how many such 56k links are
fed into a T1 to the backbone, and how many such T1s feed
into the T3, etc. do need to make some assumptions about
how heavily I'm going to be loading up my 56k, and how our
collective of 56ks will be loading the T1, and so on and I
will hopefully on average behave as expected, but it seems
that any one pathological connection (and its corresponding
pathalogical user) shouldn't be in a position to do damage
on a global scale, assuming they are not a significant
percentage of the total capacity...
This does suggest that resellers of connections (who
appear to be in a position to generate higher average link
traffic) should be paying a higher price for their feeds,
and their links should be rated as higher average
contribution into the network, but we should be able to
identify classes of traffic and allow for that.
- peterd
--
------------------------------------------------------------------------------
Peter Deutsch, (514) 875-8611 (phone)
Bunyip Information Systems Inc. (514) 875-8134 (fax)
<peterd at bunyip.com>
"Charging for information is not a crime, any more than charging for food is
a crime. On the other hand, I agree that letting people _starve_ is a crime."
------------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13800;
22 Jul 93 20:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13793;
22 Jul 93 20:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12121;
22 Jul 93 20:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13781;
22 Jul 93 20:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13054;
22 Jul 93 19:13 EDT
To: Bob Stewart <rlstewart at eng.xyplex.com>
cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Network benefits, was Re: Who Pays for What
In-reply-to: Your message of "Thu, 22 Jul 93 20:23:20 CDT."
<9307230123.AA09330 at xap.xyplex.com>
Date: Thu, 22 Jul 93 19:13:44 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9307221913.aa13054 at IETF.CNRI.Reston.VA.US>
There was a suggestion that we should register the Internet
as a country in the ISO 3166 document (makes handling email
easier...)
:-)
vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14021;
22 Jul 93 20:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14014;
22 Jul 93 20:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13777;
22 Jul 93 20:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14002;
22 Jul 93 20:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13966;
22 Jul 93 20:56 EDT
Received: from vnet.ibm.com by CNRI.Reston.VA.US id aa13577; 22 Jul 93 20:56 EDT
Received: from RHQVM21.SOMERS.HQREGION.IBM.COM by vnet.IBM.COM
(IBM VM SMTP V2R2) with BSMTP id 1146; Thu, 22 Jul 93 20:55:54 EDT
Message-Id: <19930722.205658.RHB at RHQVM21>
Date: 22 Jul 93 20:56:57 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: rboivie at vnet.ibm.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
To: ietf at CNRI.Reston.VA.US, peterd at bunyip.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: (U) Clogging the network from low-speed lines
From:
Couldn't a user telneting in to a supercomputer at 2400 baud launch
some program on the supercomputer that would generate enough stuff
to fill the multiple 155 Mb/sec vBNS lines that will be connected to
that supercomputer next year?
Rick Boivie
----------------------------------------------------------------
from Peter Deutsch's note
. . .
> Currently an individual can only drive ONE vehicle (one packet) at a
> time on the highway system, and it can only be on ONE road or
> intersection at a time, so individual (ab)use of the free highway system
> has a built-in upper limit. Even if I drive illegally, violating custom
> or law, this upper limit of "one person, one vehicle, one location" at a
> time still applies. . . .
And any user with access to a single 56k link onto the
network can only generate 56k of data onto the backbone
from that connection. True, if a user can generate traffic
from three such connections then they can potentially
generate up to three times the traffic of a single link,
but only by taking away from the generating capacity of
other users of the same links. That seems to imply that we
should be counting not users, but rather functional network
endpoint connections and their aggregate bandwidth.
Put another way, the important metric here is not the
number of cars a driver owns (ie. his or her internal data
generating capacity), but the number of simultaneous cars
they can feed onto the road system (ie. the bandwidth in
cars per connection). It doesn't matter if there are
twelve drivers in a house, if there is only one car that
can be driven out of the driveway.
> On the internet "highway", however, I can simultaneously drive as many
> packets from as many sources as I can beg borrow or steal to as many
> destinations as I can address. From my 2400 bps dial-up line I can
> start many remote processes which use multiple megabit resources
> simultaneously over multiple lines and vast distances. One individual
> can saturate a resource/line designed to be shared by many users of
> "normal" appetites, individually creating a demand for significant
> incremental investment.
Yes, a single user can be responsible for the generation
of a multitude of packets, but each network _connection_
can only generate a bounded and finite amount of traffic
and it seems to me that it is this generating capacity
that determines if the overall system will saturate. A 56k
connection cannot source or sink more than 56k of data, no
matter how hard we try so even if a single user is
responsible for simultaneously saturating six such links,
that does not mean that any more generating capacity has
been added or traffic can be generated than was attached.
All it means is that a single user is dominating six
endpoint links. Would we be any better of if six
individuals dominated six endpoint links?
Now, we don't want to try and engineer a national
backbone that is capable of carrying the simple sum of the
bandwidth of all endpoint connections, since that seems a
tad wasteful, but this does suggest that doomsday
scenarios that suggest that a single user can destroy the
Internet are perhaps a little too extreme. The issue is
still engineering for average use and making sure we have
a handle on how much traffic an average _connection_ (not
an average user) will feed into the data stream.
> A lot depends on how much of the shared resource one individual can
> consume as well as what it costs. What is the incremental
> cost/aggravation/loss of compensating for an individual who takes more
> than a fair share of a limited resource?
If I buy a single 56k link, and use the total capacity of
my 56k link, I don't see that I have really performed
anything like a denial of service attack on my neighbors.
The engineers who spec'ed out how many such 56k links are
fed into a T1 to the backbone, and how many such T1s feed
into the T3, etc. do need to make some assumptions about
how heavily I'm going to be loading up my 56k, and how our
collective of 56ks will be loading the T1, and so on and I
will hopefully on average behave as expected, but it seems
that any one pathological connection (and its corresponding
pathalogical user) shouldn't be in a position to do damage
on a global scale, assuming they are not a significant
percentage of the total capacity...
This does suggest that resellers of connections (who
appear to be in a position to generate higher average link
traffic) should be paying a higher price for their feeds,
and their links should be rated as higher average
contribution into the network, but we should be able to
identify classes of traffic and allow for that.
- peterd
--
------------------------------------------------------------------------------
Peter Deutsch, (514) 875-8611 (phone)
Bunyip Information Systems Inc. (514) 875-8134 (fax)
<peterd at bunyip.com>
"Charging for information is not a crime, any more than charging for food is
a crime. On the other hand, I agree that letting people _starve_ is a crime."
------------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14113;
22 Jul 93 21:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14106;
22 Jul 93 21:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14089;
22 Jul 93 21:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14093;
22 Jul 93 21:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14070;
22 Jul 93 21:07 EDT
Received: from nic.near.net by CNRI.Reston.VA.US id aa13928; 22 Jul 93 21:07 EDT
Received: from nic.near.net by nic.near.net id aa11017; 22 Jul 93 21:07 EDT
To: Dave Crocker <dcrocker at mordor.stanford.edu>
cc: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>, ietf at CNRI.Reston.VA.US
Subject: Re: uk national press...on IPng
In-reply-to: Your message of Thu, 22 Jul 1993 08:10:34 -0700.
<9307221510.AA23842 at Mordor.Stanford.EDU>
Date: Thu, 22 Jul 1993 21:07:57 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Curran <jcurran at nic.near.net>
Message-ID: <9307222107.aa13928 at CNRI.Reston.VA.US>
--------
] From: Dave Crocker <dcrocker at mordor.stanford.edu>
] Subject: Re: uk national press...on IPng
] Date: Thu, 22 Jul 93 08:10:34 -0700
] ...
] This is the second time that we have seen OSI-based advocates being
] directed to register their opinions with the noop list. Who is
] given them this suggestion and why? Surely such folk know that that is
] most definitely NOT the way we work in the IETF and that the end effect
] of that sort of lobbying is to alienate factions.
I agree. There is not much to be gained from such mailings, and
soliciting random "letters of support" for IETF direction may not
be the best precedent to set.
It wouldn't hurt, however, to conduct a _generic_ poll of the features
desired in IPng. It might be better to know now (rather than later) what
Mr.Average-Internet-User expects out of IPng. Is such input gathering a
potential role for ISOC?
/John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14270;
22 Jul 93 21:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14263;
22 Jul 93 21:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14727;
22 Jul 93 21:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14251;
22 Jul 93 21:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14226;
22 Jul 93 21:25 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14702;
22 Jul 93 21:25 EDT
Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-12)
id <AA08252>; Thu, 22 Jul 1993 18:25:30 -0700
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA07631; Thu, 22 Jul 93 18:25:28 -0700
Message-Id: <9307230125.AA07631 at Mordor.Stanford.EDU>
To: Randall Atkinson <atkinson at itd.nrl.navy.mil>
Cc: ietf at isi.edu
Subject: Re: UK nat'l press and IPtng
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Thu, 22 Jul 93 19:04:07 -0400. <9307222304.AA24164 at itd.nrl.navy.mil>
Date: Thu, 22 Jul 93 18:25:27 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
Ran,
---- Included message:
Now I left industry for a research lab precisely because I find many
parts of that world to be irrational,
As always, beauty is in the eye of the beholder.
I left research, going into the commercial sector for similar reasons
as you went the other direction...
No doubt, the real analysis is the you and I are the irrational
ones, and the research and academic communities are just fine.
Sure. you bet.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17841;
22 Jul 93 23:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17834;
22 Jul 93 23:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18852;
22 Jul 93 23:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17819;
22 Jul 93 23:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17782;
22 Jul 93 23:08 EDT
Received: from sadye.emba.uvm.edu by CNRI.Reston.VA.US id aa18792;
22 Jul 93 23:08 EDT
Received: by sadye.emba.uvm.edu id AA15802
(5.65/1.23); Thu, 22 Jul 93 23:09:23 -0400
Date: Thu, 22 Jul 93 23:09:23 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: wollman at uvm-gen.emba.uvm.edu
Message-Id: <9307230309.AA15802 at sadye.emba.uvm.edu>
To: John Curran <jcurran at nic.near.net>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: uk national press...on IPng
In-Reply-To: <9307222107.aa13928 at CNRI.Reston.VA.US>
References: <9307221510.AA23842 at Mordor.Stanford.EDU>
<9307222107.aa13928 at CNRI.Reston.VA.US>
<<On Thu, 22 Jul 1993 21:07:57 -0400, John Curran <jcurran at nic.near.net> said:
> It wouldn't hurt, however, to conduct a _generic_ poll of the features
> desired in IPng. It might be better to know now (rather than later) what
> Mr.Average-Internet-User expects out of IPng. Is such input gathering a
> potential role for ISOC?
Speaking as someone who works with a lot of J. Random Internet-Users,
I think that the answer is ``nothing''. J. Random Internet-User has
no idea what IPng is, or might be, or even why we see a need to
discuss things. At my site, J. Random User is just barely getting
connected to ``The Network'', and knows, for the most part, more about
international politics than about the ROAD crisis. It is my hope that
we will have a solution already in the process of deployment before
any users here even find out that there was a problem.
In other words, they don't know how ``The Network'' works, and they
don't care, so long as it continues to work. (So I guess you could
say that the average user wants a zero failure rate for the rest of
time, or at least that things not break while she's in the office
trying to get her work done.)
Of course, this is one of the reasons why some people think that NAT
boxes might be a good business to get into right now.
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman at emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman | It is a bond more powerful than absence. We like people
UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21298;
23 Jul 93 0:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21291;
23 Jul 93 0:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20876;
23 Jul 93 0:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21279;
23 Jul 93 0:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21256;
23 Jul 93 0:07 EDT
Received: from Valinor.Stanford.EDU by CNRI.Reston.VA.US id aa20865;
23 Jul 93 0:07 EDT
Received: by Valinor.Stanford.EDU (5.65/inc-1.0)
id AA00513; Thu, 22 Jul 93 21:08:07 -0700
Date: Thu, 22 Jul 93 21:08:07 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf at valinor.stanford.edu>
To: wollman at uvm-gen.emba.uvm.edu
Cc: John Curran <jcurran at nic.near.net>, ietf at CNRI.Reston.VA.US
Office: Spruce Hall F15, (415) 723-6860
Usmail: Pine Hall 115, Stanford, CA, 94305-4122
Subject: Re: uk national press...on IPng
In-Reply-To: Your message of Thu, 22 Jul 93 23:09:23 -0400
Message-Id: <CMM.0.90.2.743400487.vaf at Valinor.Stanford.EDU>
> It wouldn't hurt, however, to conduct a _generic_ poll of the features
> desired in IPng. It might be better to know now (rather than later) what
> Mr.Average-Internet-User expects out of IPng. Is such input gathering a
> potential role for ISOC?
Speaking as someone who works with a lot of J. Random Internet-Users,
I think that the answer is ``nothing''. J. Random Internet-User has
no idea what IPng is, or might be, or even why we see a need to
discuss things. At my site, J. Random User is just barely getting
connected to ``The Network'', and knows, for the most part, more about
international politics than about the ROAD crisis. It is my hope that
we will have a solution already in the process of deployment before
any users here even find out that there was a problem.
I suspect that a lot of J. Random Internet-Users would like to see IPng be
easier to use from a user perspective. Things like auto-configuration, service
discovery, and (my favorite) automatic address renumbering would go a long way
toward making the Internet more like Appletalk in ease of use. Yes, there are
a *lot* of bad things to say about Appletalk (and Novell, etc.) but they are
a lot more plug-and-play for J. Random Internet-User who doesn't want to deal
with configuring IP addresses, server ports, or routing and doesn't want to
have to, along with 6000 other J. Random Internet-User's, have to reconfigure
everything when his company changes service providers and the company routing
prefix needs to be changed.
--Vince
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21451;
23 Jul 93 0:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21441;
23 Jul 93 0:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21546;
23 Jul 93 0:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21427;
23 Jul 93 0:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21397;
23 Jul 93 0:25 EDT
Received: from qdeck.com by CNRI.Reston.VA.US id aa21508; 23 Jul 93 0:25 EDT
Received: from angel.qdeck.com by rockall.qdeck.com (4.1/SMI-4.1)
id AA14739; Thu, 22 Jul 93 21:25:06 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jordan Brown <jbrown at qdeck.com>
To: vaf at valinor.stanford.edu, wollman at uvm-gen.emba.uvm.edu
Subject: Re: uk national press...on IPng
Cc: jcurran at nic.near.net, ietf at CNRI.Reston.VA.US
X-Mailer: ScoMail 1.0
Date: Thu, 22 Jul 1993 21:20:11 -0700 (PDT)
Message-Id: <9307222120.aa22972 at angel.qdeck.com>
> I suspect that a lot of J. Random Internet-Users would like to see IPng be
> easier to use from a user perspective. Things like auto-configuration, ...
Yes! Everything he said!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21860;
23 Jul 93 1:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21853;
23 Jul 93 1:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24422;
23 Jul 93 1:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21840;
23 Jul 93 1:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21812;
23 Jul 93 1:56 EDT
Received: from ERNST.MACH.CS.CMU.EDU by CNRI.Reston.VA.US id aa24403;
23 Jul 93 1:56 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Christopher Maeda <cmaeda at ernst.mach.cs.cmu.edu>
Date: Fri, 23 Jul 93 01:56:23 EDT
To: jhaverty at us.oracle.com
CC: cmills at bbn.com, ietf at CNRI.Reston.VA.US, john at iastate.edu
In-reply-to: Jack Haverty's message of Thu, 22 Jul 93 16:04:38 PDT <9307222304.AA08619 at rivendell.us.oracle.com>
Subject: Posting by Goodfellow
Reply-to: cmaeda at cs.cmu.edu
Message-ID: <9307230156.aa24403 at CNRI.Reston.VA.US>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Jack Haverty <jhaverty at us.oracle.com>
Date: Thu, 22 Jul 93 16:04:38 PDT
The point? With a bit more cost awareness and fair-sharing attention,
vendors might build technology that didn't accidentally make users into bad
citizens.
Give me a break. If I buy a high-performance workstation, the last
thing I want to do is be a good network citizen. Buy faster networks
or have fewer machines per ethernet segment.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00628;
23 Jul 93 3:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00621;
23 Jul 93 3:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02799;
23 Jul 93 3:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00592;
23 Jul 93 3:35 EDT
Received: from ecrc.de by IETF.CNRI.Reston.VA.US id aa00563; 23 Jul 93 3:30 EDT
Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA29512
(5.65c/IDA-1.4.4 for <ietf at ietf.cnri.reston.va.us>); Fri, 23 Jul 1993 09:30:25 +0200
Received: by acrab25.ecrc (4.1/SMI-3.2)
id AA03341; Fri, 23 Jul 93 09:28:06 +0200
Date: Fri, 23 Jul 93 09:28:06 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Morton <Dave.Morton at ecrc.de>
Message-Id: <9307230728.AA03341 at acrab25.ecrc>
To: rlstewart at eng.xyplex.com, vcerf at CNRI.Reston.VA.US
Subject: Re: Network benefits, was Re: Who Pays for What
Cc: ietf at IETF.CNRI.Reston.VA.US
>There was a suggestion that we should register the Internet
>as a country in the ISO 3166 document (makes handling email
>easier...)
>:-)
>
>vint
>
No just, it might also help avoid some sticky political situations
with the country tlds.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00700;
23 Jul 93 3:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00693;
23 Jul 93 3:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03349;
23 Jul 93 3:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00681;
23 Jul 93 3:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00657;
23 Jul 93 3:52 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03178;
23 Jul 93 3:52 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.18678-0 at bells.cs.ucl.ac.uk>; Fri, 23 Jul 1993 08:52:41 +0100
To: Cyndi Mills <cmills at bbn.com>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: Posting by Goodfellow
In-reply-to: Your message of "Thu, 22 Jul 93 15:59:16 EDT." <9307221743.aa05839 at CNRI.Reston.VA.US>
Date: Fri, 23 Jul 93 08:52:34 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Message-ID: <9307230352.aa03178 at CNRI.Reston.VA.US>
>Imagine changing the telephone system to allow any human being anywhere,
>adult or child, to anonymously ring any or all of the telephones in the
>world simultaneously at no charge.
imagine a world weith 5* 10**9 people, and 5* 10**9 * 64 * 10**3 bps
total switching capacity....
imagine it has no operational staff, and has a mean time between
failure of switching boxes of 100 years where failure is more that 1%
of lines not functioning...
you've just imnagined the net as it will be within 25 years....
jon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03670;
23 Jul 93 8:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03663;
23 Jul 93 8:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12909;
23 Jul 93 8:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03649;
23 Jul 93 8:31 EDT
Received: from mon.cise.nsf.gov by IETF.CNRI.Reston.VA.US id aa03586;
23 Jul 93 8:29 EDT
Received: by mon.cise.nsf.gov (920330.SGI/920502.SGI)
for ietf at IETF.CNRI.Reston.VA.US id AA07910; Fri, 23 Jul 93 08:30:05 -0500
Date: Fri, 23 Jul 1993 08:29:46 -0500 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Stephen Wolff <steve at mon.cise.nsf.gov>
X-Orig-Sender: Stephen Wolff <steve at mon.cise.nsf.gov>
Reply-To: Stephen Wolff <steve at mon.cise.nsf.gov>
Subject: Re: Network benefits, was Re: Who Pays for What
To: Bob Stewart <rlstewart at eng.xyplex.com>
Cc: ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: <9307230123.AA09330 at xap.xyplex.com>
Message-Id: <Pine.3.07.9307230816.B7846-8100000 at mon.cise.nsf.gov>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
My usual analogy to "Who's in charge of the Internet?" is "Who's in charge
of the national footpath and sidewalk system?". I agree that's the way it
ought to be. Messy. Neat. Yes. -s
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04451;
23 Jul 93 9:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04444;
23 Jul 93 9:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14741;
23 Jul 93 9:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04432;
23 Jul 93 9:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04399;
23 Jul 93 9:16 EDT
Received: from ux1.cso.uiuc.edu by CNRI.Reston.VA.US id aa14694;
23 Jul 93 9:15 EDT
Received: from DialupEudora (mossberg.cso.uiuc.edu) by ux1.cso.uiuc.edu with SMTP id AA17603
(5.67a8/IDA-1.5 for <ietf at CNRI.Reston.VA.US>); Fri, 23 Jul 1993 08:04:49 -0500
Date: Fri, 23 Jul 1993 08:04:49 -0500
Message-Id: <199307231304.AA17603 at ux1.cso.uiuc.edu>
X-Sender: krol at ux1.cso.uiuc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Phil Karn <karn at qualcomm.com>, carl at trystero.malamud.com,
jhaverty at us.oracle.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ed Krol <e-krol at uiuc.edu>
Subject: Re: Posting by Goodfellow
Cc: ietf at CNRI.Reston.VA.US
My problem was more with the stories adding more fuel to the fire
about the Internet/NSF vs the telcos on capitol hill.
The story wasn't "Users use different telephone services to do things
more competitivly and cheaper".
It connoted "Internet screws telcos out of their due"
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06931;
23 Jul 93 11:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06924;
23 Jul 93 11:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22484;
23 Jul 93 11:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06911;
23 Jul 93 11:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06860;
23 Jul 93 11:54 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22309;
23 Jul 93 11:54 EDT
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-12)
id <AA01914>; Fri, 23 Jul 1993 08:54:54 -0700
Received: from hercules.rutgers.edu by rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA02949; Fri, 23 Jul 93 11:54:51 EDT
Received: by hercules.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA05534; Fri, 23 Jul 93 11:54:49 EDT
To: ru-comp-dev-ietf at rutgers.edu
Path: hercules.rutgers.edu!brisco
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Thomas P. Brisco" <brisco at hercules.rutgers.edu>
Newsgroups: ru.comp.dev.ietf
Subject: Re: uk national press...on IPng
Message-Id: <Jul.23.11.54.47.1993.5533 at hercules.rutgers.edu>
Date: 23 Jul 93 15:54:48 GMT
References: <CMM.0.90.2.743400487.vaf at Valinor.Stanford.EDU>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 42
In <CMM.0.90.2.743400487.vaf at Valinor.Stanford.EDU>, vaf at VALINOR.STANFORD.EDU (Vince Fuller) says
[...]
>I suspect that a lot of J. Random Internet-Users would like to see IPng be
>easier to use from a user perspective. Things like auto-configuration, service
>discovery, and (my favorite) automatic address renumbering would go a long way
>toward making the Internet more like Appletalk in ease of use. Yes, there are
>a *lot* of bad things to say about Appletalk (and Novell, etc.) but they are
>a lot more plug-and-play for J. Random Internet-User who doesn't want to deal
>with configuring IP addresses, server ports, or routing and doesn't want to
>have to, along with 6000 other J. Random Internet-User's, have to reconfigure
>everything when his company changes service providers and the company routing
>prefix needs to be changed.
>
> --Vince
Well, as a voice from the other side; while auto-configuration
probably appeals to the users, it's living hell to deal with in
terms of actually operating a network. Autoconfiguration with
appropriate administrative hooks would be acceptable -- but stuff
like the address allocation schemes that AppleTalk uses is
definately out.
Automatic address allocation effectively negates any ability
of people to trace back the who/where/when when things are going
awry .... Let's try and think of it more along the lines of
the automatic resolution of system parameters, rather than the
dynamic generation of system parameters. Let's face it, in
a large network, some level of central control is a dire
necessity ...
Tp.
--
...!rutgers!brisco (UUCP) brisco at pilot.njin.net (ARPA)
brisco at ZODIAC (BITNET) 908-932-2351 (VOICE)
T.P. Brisco, Manager of Network Operations, Computing Services
Rutgers University, Piscataway, NJ 08855-0879
Just say "Moo"
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07253;
23 Jul 93 12:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07246;
23 Jul 93 12:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23323;
23 Jul 93 12:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07232;
23 Jul 93 12:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07189;
23 Jul 93 12:09 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa23200;
23 Jul 93 12:09 EDT
Received: from GINGER.LCS.MIT.EDU by venera.isi.edu (5.65c/5.61+local-12)
id <AA02590>; Fri, 23 Jul 1993 09:09:54 -0700
Received: by ginger.lcs.mit.edu
id AA04132; Fri, 23 Jul 93 11:41:04 -0400
Date: Fri, 23 Jul 93 11:41:04 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9307231541.AA04132 at ginger.lcs.mit.edu>
To: atkinson at itd.nrl.navy.mil, ietf at isi.edu
Subject: Re: UK nat'l press and IPtng
Cc: jnc at ginger.lcs.mit.edu
It seems to me that the rational and scientific way to proceed when faced
with a technical problem is to identify as many potential solutions as
possible and then select the most technically promising one that appears
sufficiently feasible.
I just about fell off my chair laughing when I read this. Not because I
think it's a bad idea; I actually hold very strongly to this as a personal
guiding light. I was just amused by the way you explicitly answer your
question in the way you put it, i.e. "the rational and scientific way". I
understand that different people have different goals (e.g. some people want
to make money, and don't care about technology), but *in the long run*
little good comes from deliberately picking bad options for short-term
personal reasons.
There are just a lot of people out there who don't think this way, there
always have been (even though it's been 2500 years since Western culture
produced the rational analaytical model), and, given this history, there
probably always will be (sad to say); at least until one of them gets his
hands on too much power and trashes the planet (the best reasons for a space
program, but I digress).
I only hope my views are in the mainstream of the IETF. When they
become fringe views in the IETF, it will be time for me to leave...
The challenge of history is "how do the rational people have an effect on
the world?" They can't just throw up our hands and say "oops, they are
losers, let's just go curl up in a corner and let them loose". In the IETF
context, I think the way to go is to stay, and work hard, and provide an
explained example for others to follow.
If and (almost inevitably) when the IETF falls completely away from the
guide of "best technical solution", it will be time to leave, but not
because of personal frustration, but rather because an organization which
deserts that guide is doomed to failure, and there's no point in throwing
good energy after bad.
Ooops, sorry to ramble on. Off to work...
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07361;
23 Jul 93 12:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07354;
23 Jul 93 12:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23752;
23 Jul 93 12:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07334;
23 Jul 93 12:16 EDT
Received: from tadpole.Tadpole.COM by IETF.CNRI.Reston.VA.US id aa07298;
23 Jul 93 12:15 EDT
Received: from ono-sendai (ono-sendai.tadtec.co.uk) by tadpole.tadpole.com (4.1/SMI-4.1)
id AA04089; Fri, 23 Jul 93 11:15:49 CDT
Received: by ono-sendai (4.1/SPARCbook_POP1.3)
id AA01056; Fri, 23 Jul 93 16:15:11 GMT
Date: Fri, 23 Jul 93 16:15:11 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: jim at tadpole.com
Message-Id: <9307231615.AA01056 at ono-sendai>
To: brisco at hercules.rutgers.edu, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: uk national press...on IPng
> Automatic address allocation effectively negates any ability
> of people to trace back the who/where/when when things are going
> awry .... Let's try and think of it more along the lines of
> the automatic resolution of system parameters, rather than the
> dynamic generation of system parameters. Let's face it, in
> a large network, some level of central control is a dire
> necessity ...
If you're depending on your addressing being static enough
that you can catch people, you're operating under a false sense
of security.
This has been said before, many times.
Jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07635;
23 Jul 93 12:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07628;
23 Jul 93 12:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24353;
23 Jul 93 12:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07612;
23 Jul 93 12:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07539;
23 Jul 93 12:24 EDT
Received: from upeksa.sdsc.edu by CNRI.Reston.VA.US id aa24240;
23 Jul 93 12:24 EDT
Received: by upeksa.sdsc.edu (AIX 3.2/UCB 5.64/4.03)
id AA11443; Fri, 23 Jul 1993 09:25:13 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Hans-Werner Braun <hwb at upeksa.sdsc.edu>
Message-Id: <9307231625.AA11443 at upeksa.sdsc.edu>
Subject: Re: uk national press...on IPng
To: ietf at CNRI.Reston.VA.US
Date: Fri, 23 Jul 93 9:25:12 PDT
I suspect the Mr. J. Random Internet-*user* in the first place just
does not want to care about petty details in the network. The best
network is a working, but otherwise invisible network. In the end, what
does not matter to him how the bits in the packets are sorted, as long
as it works. The next thing is what Vince is saying, if a user *really*
has to go down to the level of having to do some work to make things
happen, it should be as painless as possible. The next level would be
trying to do the same thing with host administrators, and so on. Right,
plug'n'play is what you need. We just cannot view the Internet as an
environment for network researchers and people having fun in computer
science departments any more. We cannot expect being able to ask a
random user about what the 15th byte in the packet will look like (like
you perhaps could a bunch of years ago). But those users would get
quite upset if the network became suddenly visible to them, be it for
service qualities in general, or implementations of unmanageable and
unintegratable architectures/protocols/... as applied to a global
scale. I also suspect that the network will have bigger problems than
routing and addressing before too long. Things like service qualities
in the age of many thousands of simultaneous multimedia real time
flows, for example. Needs for multiple service levels. Who cares about
whether routing works, if as a user you don't get your bits through as
2000 people leave their cameras on, pointing into a dark office in the
evening or having all day sessions with their friends across the
country, just because its easy and free, and the network being
congested.
For me the principal issue is how the multilevel (and often autonomous)
components of the network (end user, host/network administrator,
regional tech, national backbones, international links, ..., and, most
importantly the whole thing taken together at the systems level) can be
managed, coordinated, and operated, and is viable, even politically.
Once you figure that out, the specific IPng is a detail.
Hans-Werner
>I suspect that a lot of J. Random Internet-Users would like to see IPng be
>easier to use from a user perspective. Things like auto-configuration, service
>discovery, and (my favorite) automatic address renumbering would go a long way
>toward making the Internet more like Appletalk in ease of use. Yes, there are
>a *lot* of bad things to say about Appletalk (and Novell, etc.) but they are
>a lot more plug-and-play for J. Random Internet-User who doesn't want to deal
>with configuring IP addresses, server ports, or routing and doesn't want to
>have to, along with 6000 other J. Random Internet-User's, have to reconfigure
>everything when his company changes service providers and the company routing
>prefix needs to be changed.
>
> --Vince
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08134;
23 Jul 93 13:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08127;
23 Jul 93 13:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26164;
23 Jul 93 13:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08115;
23 Jul 93 13:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08084;
23 Jul 93 13:00 EDT
Received: from eco.twg.com by CNRI.Reston.VA.US id aa26101; 23 Jul 93 13:00 EDT
Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $)
id AA28520; Fri, 23 Jul 93 12:58:54 -0400
Message-Id: <9307231658.AA28520 at eco.twg.com>
Received: from apache.twg.com by apache.twg.com id <20494-0 at apache.twg.com>; Fri, 23 Jul 1993 09:59:59 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Herron <david at twg.com>
Subject: Re: Posting by Goodfellow
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Cc: Cyndi Mills <cmills at bbn.com>,
IPM Return Requested <ietf at CNRI.Reston.VA.US>
Date: Fri, 23 Jul 93 9:59:57 PDT
In-Reply-To: Your message of Fri, 23 Jul 93 08:52:34 +0100.<9307230352.aa03178 at CNRI.Reston.VA.US>
Sensitivity: Personal
Conversion: Prohibited
Conversion-With-Loss: Prohibited
Encoding: 10 TEXT
Jon,
>imagine it has no operational staff, and has a mean time between
>failure of switching boxes of 100 years where failure is more that 1%
>of lines not functioning...
Do you realize how scary this is? What happens when it breaks after 100 years
and everybody's forgotten how to fix it?
David
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08194;
23 Jul 93 13:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08183;
23 Jul 93 13:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26421;
23 Jul 93 13:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08169;
23 Jul 93 13:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08143;
23 Jul 93 13:04 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa26201;
23 Jul 93 13:04 EDT
Received: from zoo.toronto.edu (zoo.utoronto.ca) by venera.isi.edu (5.65c/5.61+local-12)
id <AA04422>; Fri, 23 Jul 1993 10:04:54 -0700
Message-Id: <199307231704.AA04422 at venera.isi.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: henry at zoo.toronto.edu
Date: Fri, 23 Jul 93 13:04:47 EDT
To: IETF mailing list <ietf at isi.edu>
Subject: Re: Posting by Goodfellow
>Usage insensitive pricing is real nice. But it also seems to have allowed
>for abominations like some of Usenet's picture-oriented groups to blow up
>out of proportion. So in some ways it isn't nice.
This is actually a somewhat amusing development, since Usenet in its early
days was the epitome of usage-*sensitive* pricing, with most long-haul
data shipment done by modems making toll calls. Gratuitous bulk could
bring complaints from all corners of the network -- and well it should,
since a significant fraction of those connections were 300 baud... Both
software and hardware technology were improved several times to keep the
phone bills down as Usenet traffic grew.
However, the traffic did keep growing, partly because the people who
actually posted and read the news weren't the ones paying the bills.
The same situation actually holds in the Internet: to a large extent,
the costs are *not* being passed down to the individual user, so there
is little pressure on him to moderate his use. This is both a good
thing and a bad thing: good because it encourages innovative use
rather than nervous it's-costing-too-much clockwatching, bad because
it provides no real incentive to restrain volume.
Anyone seeking Internet analogies to Usenet's picture-oriented groups
does not have to look very hard...
Henry Spencer at U of Toronto Zoology
henry at zoo.toronto.edu utzoo!henry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08258;
23 Jul 93 13:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08251;
23 Jul 93 13:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26486;
23 Jul 93 13:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08223;
23 Jul 93 13:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08181;
23 Jul 93 13:05 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa26427;
23 Jul 93 13:05 EDT
Received: from zoo.toronto.edu (zoo.utoronto.ca) by venera.isi.edu (5.65c/5.61+local-12)
id <AA04439>; Fri, 23 Jul 1993 10:06:16 -0700
Message-Id: <199307231706.AA04439 at venera.isi.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: henry at zoo.toronto.edu
Date: Fri, 23 Jul 93 13:06:12 EDT
To: IETF mailing list <ietf at isi.edu>
Subject: Re: Network benefits, was Re: Who Pays for What
>So what it boils down to is that the Internet is truly the world's largest
>friendly, cooperative by-choice venture...
Provided that it's bigger than Usenet. It probably is.
This is a bit amusing, for those of us on Usenet who remember some of
the Arpanet people sneering at Usenet's cooperative anarchy as hopelessly
unmanageable... Welcome to the club. You might want to consider learning
from our mistakes rather than reinventing the wheel.
Henry Spencer at U of Toronto Zoology
henry at zoo.toronto.edu utzoo!henry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab08857;
23 Jul 93 13:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08850;
23 Jul 93 13:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28121;
23 Jul 93 13:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08825;
23 Jul 93 13:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08781;
23 Jul 93 13:42 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa28093;
23 Jul 93 13:42 EDT
Received: from cunixf.cc.columbia.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA08577>; Fri, 23 Jul 1993 10:43:29 -0700
Received: from hermes.gsb.columbia.edu by cunixf.cc.columbia.edu (5.59/FCB/jba)
id AA19212; Fri, 23 Jul 93 13:42:56 EDT
Received: From ADMIN/WORKQUEUE by hermes.gsb.columbia.edu
via Charon-4.0A-VROOM with IPX id 100.930723134319.320;
23 Jul 93 13:43:31 +0500
Message-Id: <MAILQUEUE-101.930723134300.480 at research.gsb.columbia.edu>
To: ietf at isi.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Lehr <WLEHR at research.gsb.columbia.edu>
Date: 23 Jul 93 13:43:00 EST
Subject: Re: UK nat'l press and IPtng
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Regarding....
> Date: Thu, 22 Jul 93 19:04:07 EDT
> From: Randall Atkinson <atkinson at itd.nrl.navy.mil>
> To: ietf at isi.edu
> Subject: Re: UK nat'l press and IPtng
>
> For my part I find it quite odd that people would ever pick some
> technology and lobby for it on political grounds. It seems to me
> that the rational and scientific way to proceed when faced with
> a technical problem is to identify as many potential solutions as
> possible and then select the most technically promising one that
> appears sufficiently feasible.
Were it always as simple. Even the most public spirited may differ
regarding what is scientifically the best solution. Moreover,
since adopting new technologies usually imposes transition costs which
affect users asymmetrically, private incentives and social incentives
often differ. I suspect that agreement may be even tougher to reach
in the future -- not because the process is busted -- but because the
environment is changing. When the number of people participating
increases, their goals differ and their level of expertise differs,
reaching agreement becomes more difficult.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08986;
23 Jul 93 13:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08979;
23 Jul 93 13:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28558;
23 Jul 93 13:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08950;
23 Jul 93 13:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08919;
23 Jul 93 13:50 EDT
Received: from relay2.UU.NET by CNRI.Reston.VA.US id aa28465;
23 Jul 93 13:50 EDT
Received: from hoho.agile.com (via [198.3.104.110]) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA00664; Fri, 23 Jul 93 13:50:40 -0400
Message-Id: <9307231750.AA00664 at relay2.UU.NET>
Received: by hoho.agile.com
(1.37.109.4/16.2) id AA06989; Fri, 23 Jul 93 13:46:21 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Nik Langrind <nlangrind at agile.com>
Subject: Re: Posting by Goodfellow
To: David Herron <david at twg.com>
Date: Fri, 23 Jul 93 13:46:20 EDT
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9307231658.AA28520 at eco.twg.com>; from "David Herron" at Jul 23, 93 9:59 am
Mailer: Elm [revision: 70.85]
>
> Jon,
>
> >imagine it has no operational staff, and has a mean time between
> >failure of switching boxes of 100 years where failure is more that 1%
> >of lines not functioning...
>
> Do you realize how scary this is? What happens when it breaks after 100 years
> and everybody's forgotten how to fix it?
>
> David
>
No need to worry about that. With 5 billion users, each of whom has 64kb of
personal bandwidth, there will be so many switches that thousands, maybe
millions will fail every year.
--
Nik Langrind nlangrind at agile.com
Agile Networks (508) 287-0700 x110
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09336;
23 Jul 93 14:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09329;
23 Jul 93 14:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29261;
23 Jul 93 14:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09298;
23 Jul 93 14:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab09232;
23 Jul 93 14:00 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa29153;
23 Jul 93 14:00 EDT
Received: from apple.com by venera.isi.edu (5.65c/5.61+local-12)
id <AA09633>; Fri, 23 Jul 1993 11:00:52 -0700
Received: by apple.com with SMTP (5.61/19-Jul-1993-eef)
id AA08297; Fri, 23 Jul 93 11:00:42 -0700
for ietf at isi.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Erik E. Fair" (Your Friendly Postmaster) <fair at apple.com>
Subject: Re: Network benefits, was Re: Who Pays for What
In-Reply-To: <199307231706.AA04439 at venera.isi.edu>
To: henry at zoo.toronto.edu
X-Return-Path: ietf-request at ietf.nri.reston.va.us
Cc: IETF mailing list <ietf at isi.edu>
Date: Fri, 23 Jul 93 11:00:40 -0700
Message-Id: <8294.743450440 at apple.com>
X-Orig-Sender: fair at apple.com
Which mistakes were you thinking of, Henry?
Erik E. Fair apple!fair fair at apple.com
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09919;
23 Jul 93 14:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00370;
23 Jul 93 14:19 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09901;
23 Jul 93 14:19 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09751;
23 Jul 93 14:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-teraoka-mobileip-vip-00.txt
Date: Fri, 23 Jul 93 14:15:30 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307231415.aa09751 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : The Virtual Network Protocol for Host Mobility
Author(s) : F. Teraoka, K. Uehara
Filename : draft-teraoka-mobileip-vip-00.txt
Pages : 20
This memo describes the general virtual network protocol that provides the
transport layer with host migration transparency. This protocol is based
on the concept of a `virtual network' and the `propagating cache method'.
Basically, this protocol can be applied to any connectionless network layer
protocol. This memo also describes two virtual network protocols: `VIP'
(Virtual Internet Protocol) and `ISO-VIP'. The former is derived from IP,
the network layer protocol of Internet, while the latter is derived from
CLNP, the connectionless-mode network layer protocol of ISO.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-teraoka-mobileip-vip-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-teraoka-mobileip-vip-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-teraoka-mobileip-vip-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-teraoka-mobileip-vip-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab10569;
23 Jul 93 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10565;
23 Jul 93 14:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01155;
23 Jul 93 14:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10554;
23 Jul 93 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10548;
23 Jul 93 14:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01144;
23 Jul 93 14:35 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10542;
23 Jul 93 14:35 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: tuba at lanl.gov
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Use of ISO CLNP in TUBA Environments to Proposed
Standard
Date: Fri, 23 Jul 93 14:35:14 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9307231435.aa10542 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the TCP/UDP over CLNP-addressed
Networks Working Group to consider <draft-ietf-tuba-clnp-03.txt> "Use
of ISO CLNP in TUBA Environments" for the status of Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
06 August.
John Stewart
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11627;
23 Jul 93 15:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03919;
23 Jul 93 15:19 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11579;
23 Jul 93 15:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11419;
23 Jul 93 15:16 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa03831;
23 Jul 93 15:16 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA17772>; Fri, 23 Jul 1993 12:17:17 -0700
Message-Id: <199307231917.AA17772 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1477 on IDPR
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:17:15 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1477:
Title: IDPR as a Proposed Standard
Author: M. Steenstrup
Mailbox: msteenst at bbn.com
Pages: 13
Characters: 32,238
Updates/Obsoletes: none
This document contains a discussion of inter-domain policy routing
(IDPR), including an overview of functionality and a discussion of
experiments. The objective of IDPR is to construct and maintain
routes between source and destination administrative domains, that
provide user traffic with the services requested within the
constraints stipulated for the domains transited.
This memo provides information for the Internet community. It does
not specify an Internet standard. 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1477.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1477.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11625;
23 Jul 93 15:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03921;
23 Jul 93 15:19 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11582;
23 Jul 93 15:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11447;
23 Jul 93 15:17 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa03856;
23 Jul 93 15:17 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA17801>; Fri, 23 Jul 1993 12:17:53 -0700
Message-Id: <199307231917.AA17801 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1479 on IDPR Protocol
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:17:50 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1479:
Title: Inter-Domain Policy Routing Protocol
Specification: Version 1
Author: M. Steenstrup
Mailbox: msteenst at bbn.com
Pages: 108
Characters: 275,823
Updates/Obsoletes: none
This RFC describes the set of protocols and procedures that constitute
Inter-Domain Policy Routing (IDPR). IDPR includes the virtual gateway
protocol, the flooding protocol, the route server query protocol, the
route generation procedure, the path control protocol, and the data
message forwarding procedure.
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1479.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1479.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11632;
23 Jul 93 15:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03923;
23 Jul 93 15:19 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11587;
23 Jul 93 15:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11430;
23 Jul 93 15:16 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa03845;
23 Jul 93 15:16 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA17791>; Fri, 23 Jul 1993 12:17:32 -0700
Message-Id: <199307231917.AA17791 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1478 on IDPR Architecture
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:17:30 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1478:
Title: An Architecture for Inter-Domain Policy Routing
Author: M. Steenstrup
Mailbox: msteenst at bbn.com
Pages: 35
Characters: 90,673
Updates/Obsoletes: none
This RFC presents an architecture for inter-domain policy routing
(IDPR). The objective of IDPR is to construct and maintain routes,
between source and destination administrative domains, that provide
user traffic with the requested services within the constraints
stipulated for the domains transited. The IDPR architecture is
designed to accommodate an internetwork containing tens of thousands
of administrative domains with heterogeneous service requirements and
restrictions.
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1478.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1478.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11872;
23 Jul 93 15:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04512;
23 Jul 93 15:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11860;
23 Jul 93 15:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11836;
23 Jul 93 15:27 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa04380;
23 Jul 93 15:27 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA17965>; Fri, 23 Jul 1993 12:28:02 -0700
Message-Id: <199307231928.AA17965 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1440 on SIFT/UFT
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:28:00 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1440:
Title: SIFT/UFT: Sender-Initiated/Unsolicited File
Transfer
Author: R. Troth
Mailbox: troth at rice.edu
Pages: 9
Characters: 17,366
Updates/Obsoletes: none
This document describes a Sender-Initiated File Transfer (SIFT)
protocol, also commonly called Unsolicited File Transfer (UFT)
protocol. The acronyms SIFT and UFT are synonymous throughout this
document. The term "unsolicited" does not imply that the file is
unwanted, but that the receiver did not initiate the transaction.
Sender-Initiated File Transfer contrasts with other file transfer
methods in that the sender need not have an account or any
registration on the target host system, and the receiving user may
have less steps to take to retrieve the file(s) sent. Unlike
traditional file transfer, UFT lends itself handily to background or
deferred operation, though it may be carried out immediately, even
interactively.
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard. Discussion
and suggestions for improvement are requested. Please refer to the
current edition of the "IAB Official Protocol Standards" 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1440.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1440.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12029;
23 Jul 93 15:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05066;
23 Jul 93 15:35 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12015;
23 Jul 93 15:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab11980;
23 Jul 93 15:33 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa04792;
23 Jul 93 15:33 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA18009>; Fri, 23 Jul 1993 12:34:05 -0700
Message-Id: <199307231934.AA18009 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1489 on Registration of a Cyrillic Character Set
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:34:04 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1489:
Title: Registration of a Cyrillic Character Set
Author: A. Chernov
Mailbox: ache at astral.msk.su
Pages: 5
Characters: 7,798
Updates/Obsoletes: none
Though the proposed character set "koi8-r" is not currently an
international standard, there is very large user community (including
Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard
for Unix and global network applications in the former Soviet Union.
This is the reason the Society of Unix User Groups (SUUG) believes
"koi8-r" should be registered.
This memo provides information for the Internet community. It does
not specify an Internet standard. 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1489.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1489.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12201;
23 Jul 93 15:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05690;
23 Jul 93 15:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12189;
23 Jul 93 15:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12152;
23 Jul 93 15:44 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa05453;
23 Jul 93 15:44 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA18177>; Fri, 23 Jul 1993 12:45:21 -0700
Message-Id: <199307231945.AA18177 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1490 on Multiprotocol over Frame Relay
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:45:19 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1490:
Title: Multiprotocol Interconnect over Frame Relay
Author: T. Bradley, C. Brown, & A. Malis
Mailbox: tbradley at wellfleet.com, cbrown at wellfleet.com,
malis_a at timeplex.com
Pages: 35
Characters: 75,206
Obsoletes: 1294
This memo describes an encapsulation method for carrying network
interconnect traffic over a Frame Relay backbone. It covers aspects
of both Bridging and Routing. Additionally, it describes a simple
fragmentation procedure for carrying large frames over a frame relay
network with a smaller MTU. Systems with the ability to transfer both
the encapsulation method described in this document, and others must
have a priori knowledge of which virtual circuits will carry which
encapsulation method and this encapsulation must only be used over
virtual circuits that have been explicitly configured for its use.
This RFC is a product of the IP over Large Public Data Networks
Working Group of the IETF.
This is now a Draft Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1490.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1490.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab12401;
23 Jul 93 15:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05979;
23 Jul 93 15:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12389;
23 Jul 93 15:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12336;
23 Jul 93 15:53 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa05918;
23 Jul 93 15:53 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA18337>; Fri, 23 Jul 1993 12:54:06 -0700
Message-Id: <199307231954.AA18337 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1492 on TACACS
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:54:04 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1492:
Title: An Access Control Protocol, Sometimes Called
TACACS
Author: C. Finseth
Mailbox: Craig.A.Finseth-1 at umn.edu
Pages: 21
Characters: 41,880
Updates/Obsoletes: none
There used to be a network called ARPANET. This network consisted of
end nodes (hosts), routing nodes (IMPs) and links. There were (at
least) two types of IMPs: those that connected dedicated lines only
and those that could accept dial up lines. The latter were called
"TIPs." People being what they were, there was a desire to control
who could use the dial up lines. Someone invented a protocol, called
"TACACS", which allowed a TIP to accept a username and password and
send a query to a TACACS authentication server, sometimes called a
TACACS daemon or simply TACACSD. This RFC documents the extended
TACACS protocol use by the Cisco Systems terminal servers. This same
protocol is used by the University of Minnesota's distributed
authentication system.
This memo provides information for the Internet community. It does
not specify an Internet standard. 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1492.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1492.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12689;
23 Jul 93 16:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06615;
23 Jul 93 16:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12666;
23 Jul 93 16:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12594;
23 Jul 93 16:06 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa06395;
23 Jul 93 16:06 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA18470>; Fri, 23 Jul 1993 13:06:51 -0700
Message-Id: <199307232006.AA18470 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI21, RFC1491 on X.500 Advanced Usages
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 13:06:48 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
FYI 21:
RFC 1491:
Title: A Survey of Advanced Usages of X.500
Author: C. Weider & R. Wright
Mailbox: clw at merit.edu, wright at lbl.gov
Pages: 18
Characters: 34,883
Updates/Obsoletes: none
This document is the result of a survey asking people to detail their
advanced usages of X.500. It is intended to show how various
organizations are using X.500 in ways which extend the view of X.500
as a "White Pages" service. This RFC is a product of the Integrated
Directory Services Working Group of the Application and User Services
Areas of the IETF.
This memo provides information for the Internet community. It does
not specify an Internet standard. 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1491.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1491.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13266;
23 Jul 93 16:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13257;
23 Jul 93 16:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07992;
23 Jul 93 16:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13233;
23 Jul 93 16:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13171;
23 Jul 93 16:43 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07966;
23 Jul 93 16:43 EDT
Received: from zoo.toronto.edu (zoo.utoronto.ca) by venera.isi.edu (5.65c/5.61+local-12)
id <AA20308>; Fri, 23 Jul 1993 13:43:34 -0700
Message-Id: <199307232043.AA20308 at venera.isi.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: henry at zoo.toronto.edu
Date: Fri, 23 Jul 93 16:43:00 EDT
To: "Erik E. Fair" (Your Friendly Postmaster) <fair at apple.com>
Subject: Re: Network benefits, was Re: Who Pays for What
Cc: IETF mailing list <ietf at isi.edu>
>Which mistakes were you thinking of, Henry?
I actually hadn't thought about it in depth, but I expect there are some
lessons to be learned... Like the assumption some made that the pictures
newsgroups were a passing fad...
Actually, I think the biggest mistake was building tools for today's
problems instead of tomorrow's. Too many things don't scale well when
we start talking about several orders of magnitude.
Henry Spencer at U of Toronto Zoology
henry at zoo.toronto.edu utzoo!henry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13279;
23 Jul 93 16:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13271;
23 Jul 93 16:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08000;
23 Jul 93 16:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13245;
23 Jul 93 16:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13187;
23 Jul 93 16:43 EDT
Received: from stein.u.washington.edu by CNRI.Reston.VA.US id aa07976;
23 Jul 93 16:43 EDT
Received: by stein.u.washington.edu
(5.65/UW-NDC Revision: 2.28 ) id AA16852; Fri, 23 Jul 93 13:44:12 -0700
X-Sender: rmholt at stein.u.washington.edu
Date: Fri, 23 Jul 1993 13:32:02 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rose Marie Holt <rmholt at u.washington.edu>
Subject: Re: Who Pays for What (was "Posting by Goodfellow")
To: Bob Stewart <rlstewart at eng.xyplex.com>
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9307221647.AA02212 at xap.xyplex.com>
Message-Id: <Pine.3.05.9307231359.A14804-b100000 at stein.u.washington.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=us-ascii
On Thu, 22 Jul 1993, Bob Stewart wrote:
> >But do you feel guilty when you use the "free" highway system?
>
> Nope. I have a better sense of how that's paid for, and I've bought most of
> the argument about its widespread common benefit to justify paying for it
> with taxes.
>
> In terms of the entire U.S. (world?) population, the Internet benefits only a
> small percentage. If that benefit every approaches universality, then taxes
> rather than usage fees become more appropriate.
>
> Bob
Currently, everyone pays their own way, sort of analogous to health
insurance, either self-pay or as a company benefit. The demand will
become greater, geometrically, I expect, as more people become familiar with
the net and its benefits, especially if user-friendliness continues to be
a high priority. As an intermediate form of payment, many schools are
taking advantage of services for K-12, paid for by taxes, and benefitting
society, one presumes, as other taxpayer-provided educational services do.
Similarly, taxes provide the net, and other benefits such as health
insurance, to govt employees. The net access actually helps us get our
work done. If we can bypass faxes and longdistance phone calls and send
email cheaper and faster than by other methods, then we are being more
efficient with our time and with taxpayer money. If the net demands
increase to a level approaching that of personal computers, then every
household will have net access, and will benefit from freedom from
expensive longdistance charges and snail mail. So, the fax and phone
companies need to see this as a realistic possibility for the future and
get their R & D butts in gear to a) not get bypassed and thus avoid
bankruptcy and b) invest time, $$, and ideas for getting themselves
incorporated into the net. Thus endeth my scrambled thoughts. Long live
internet. May it prosper and multiply while preserving my $$ and privacy.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13648;
23 Jul 93 17:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13641;
23 Jul 93 17:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09557;
23 Jul 93 17:15 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13629;
23 Jul 93 17:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13597;
23 Jul 93 17:13 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa09490;
23 Jul 93 17:13 EDT
Received: by xap.xyplex.com id <AA19030 at xap.xyplex.com>; Fri, 23 Jul 93 19:13:31 -0500
Date: Fri, 23 Jul 93 19:13:31 -0500
Message-Id: <9307240013.AA19030 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: Rose Marie Holt's message of Fri, 23 Jul 1993 13:32:02 -0700 (PDT) <Pine.3.05.9307231359.A14804-b100000 at stein.u.washington.edu>
Subject: Re: Who Pays for What (was "Posting by Goodfellow")
>The demand will
>become greater, geometrically, I expect, as more people become familiar with
>the net and its benefits, especially if user-friendliness continues to be
>a high priority.
At the risk of starting another cocktail party thread, I had to stop and think
of how you could call the Internet user friendly. Most people have a Unixoid
inteface which is relatively flexible but somewhat arcane and primitive. The
net itself has its friendly aspects in the incredible availability of
information and help, once you get enough clues.
The Internet will REALLY be user friendly when hooking up is no more
complicated than hooking a Macintosh to a printer with a coax cable, or
plugging your telephone into the wall, and the applications are as intuitive
as the older video games.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13762;
23 Jul 93 17:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13755;
23 Jul 93 17:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09936;
23 Jul 93 17:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13743;
23 Jul 93 17:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13705;
23 Jul 93 17:20 EDT
Received: from stein.u.washington.edu by CNRI.Reston.VA.US id aa09721;
23 Jul 93 17:20 EDT
Received: by stein.u.washington.edu
(5.65/UW-NDC Revision: 2.28 ) id AA21397; Fri, 23 Jul 93 14:21:16 -0700
X-Sender: rmholt at stein.u.washington.edu
Date: Fri, 23 Jul 1993 14:17:18 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rose Marie Holt <rmholt at u.washington.edu>
Subject: Re:Accidents on the net ( Posting by Goodfellow)
To: Jack Haverty <jhaverty at us.oracle.com>
Cc: Cyndi Mills <cmills at bbn.com>, ietf at CNRI.Reston.VA.US, john at iastate.edu
In-Reply-To: <9307222304.AA08619 at rivendell.us.oracle.com>
Message-Id: <Pine.3.05.9307231415.D14804-9100000 at stein.u.washington.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=us-ascii
by illustrating how your site tracked down and solved its problems with
accidental overuse, you illustrate why internet has done so well without
a big brother to police us for such problems. Although you regret
accidentally sending to hundreds of people the message which started this
interesting discussion, hasnt it all been overall worthwhile? So where's
the problem?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15023;
23 Jul 93 18:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15016;
23 Jul 93 18:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12675;
23 Jul 93 18:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15002;
23 Jul 93 18:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14926;
23 Jul 93 18:29 EDT
Received: from gatekeeper.us.oracle.com by CNRI.Reston.VA.US id aa12630;
23 Jul 93 18:29 EDT
Received: from rivendell.us.oracle.com by gatekeeper.oracle.com (5.59.11/37.7)
id AA20146; Fri, 23 Jul 93 15:29:52 PDT
Received: by rivendell.us.oracle.com (5.59.11/37.7)
id AA09905; Fri, 23 Jul 93 15:28:52 PDT
Message-Id: <9307232228.AA09905 at rivendell.us.oracle.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jack Haverty <jhaverty at us.oracle.com>
To: Rose Marie Holt <rmholt at u.washington.edu>
Cc: Jack Haverty <jhaverty at us.oracle.com>, Cyndi Mills <cmills at bbn.com>,
ietf at CNRI.Reston.VA.US, john at iastate.edu
Subject: Re: Accidents on the net ( Posting by Goodfellow)
In-Reply-To: Your message of Fri, 23 Jul 93 14:17:18 -0700.
<Pine.3.05.9307231415.D14804-9100000 at stein.u.washington.edu>
Date: Fri, 23 Jul 93 15:28:51 PDT
The Internet has certainly been worthwhile, and I never intended to imply
otherwise. I've been involved off and on since I implemented the first Unix
TCP in 1978 (there wasn't an "IP" at the time!), and it's been a fun ride.
There are 2 problems, which I may have mixed together in that message. First
is the accidental use problem, an example of which is the email-to-the-world.
This is solved mostly by having a fast "delete" finger, to get rid of the
duplicate copies, subscribe/unsubscribe messages, and other noise. At least
I guess you could say that "solves" the problem, as long as no one cares
about the costs.
The second problem we have NOT solved, and it really has little to do with
the Internet per se at this point; it's a LAN and workstation problem, where
a single state-of-the-art workstation can now saturate an Ethernet, to the
point where older, slower machines (i.e., last year's) don't get enough
service to even do character echoing. Curiously, this happens with "hubs" as
well as traditional Ethernets. The investigation continues, but the only
"solution" so far has been to get a patch which slows the workstations down.
There is no problem in the Internet -- yet. It's protected by the relatively
low-bandwidth access links. But as things like multimedia, conferencing, et
al become more common, access links will get upgraded, and end-user
workstations will be powerful enough to saturate them without the end-user
even being aware of it, or able to do anything about it. That's what we're
seeing now in the LAN environment; processors and network interface cards
have gotten fast enough that they are no longer a bottleneck. A single user
can drag an icon to copy some files from one place to another, which might
take a few minutes or even longer, during which other users on slower
machines get very poor service.
That user doesn't know that this is happening, and neither the user
nor any administrator can do anything to avoid it. I don't like the big
brother (administrator) approach either, and as users appear who are
non-technically oriented, it seems unreasonable to expect them to be aware of
this kind of issue, even if there were "knobs" they could use. I think that
leaves the technology as the place to put the intelligence to do the right
thing.
Meanwhile, we will be reconfiguring wiring to isolate the bad guys -- not
because they *need* the bandwidth but because they *want* the bandwidth and
like schoolyard bullies elbow others out of the way to get it. Hmmm, I
wonder, if I buy one of those Formula-1 racers with the gas pedal welded
down, the local highway department should be willing to reconfigure the
interstate system to give me a clear path wherever I want to go, in the
interests of public safety.
You might guess that I have one of those "slower machines"...
Jack
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16019;
23 Jul 93 19:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16012;
23 Jul 93 19:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14740;
23 Jul 93 19:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15996;
23 Jul 93 19:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15963;
23 Jul 93 19:33 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14703;
23 Jul 93 19:33 EDT
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by venera.isi.edu (5.65c/5.61+local-12)
id <AA27759>; Fri, 23 Jul 1993 16:34:17 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15890;
23 Jul 93 19:28 EDT
To: henry at zoo.toronto.edu
Cc: "Erik E. Fair" (Your Friendly Postmaster) <fair at apple.com>,
IETF mailing list <ietf at isi.edu>
Subject: Re: Network benefits, was Re: Who Pays for What
In-Reply-To: Your message of "Fri, 23 Jul 93 16:43:00 EDT."
<199307232043.AA20308 at venera.isi.edu>
Date: Fri, 23 Jul 93 19:28:50 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-Id: <9307231928.aa15890 at IETF.CNRI.Reston.VA.US>
boy, scaling is a bear - and one never really knows what the
scale to design for...
vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16900;
23 Jul 93 20:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16891;
23 Jul 93 20:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16768;
23 Jul 93 20:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16873;
23 Jul 93 20:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16830;
23 Jul 93 20:22 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa16744;
23 Jul 93 20:22 EDT
Received: from research.att.com by venera.isi.edu (5.65c/5.61+local-12)
id <AA01232>; Fri, 23 Jul 1993 17:23:06 -0700
Message-Id: <199307240023.AA01232 at venera.isi.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: smb at research.att.com
Received: by bigbird.zoo.att.com; Fri Jul 23 20:21:41 EDT 1993
To: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Cc: henry at zoo.toronto.edu,
"Erik E. Fair" (Your Friendly Postmaster) <fair at apple.com>,
IETF mailing list <ietf at isi.edu>
Subject: Re: Network benefits, was Re: Who Pays for What
Date: Fri, 23 Jul 93 20:21:38 EDT
boy, scaling is a bear - and one never really knows what the
scale to design for...
Indeed. The first design of Usenet assumed 1-2 articles a day,
from 50-100 sites, maximum. OK, so we were unduly pessimistic...
--Steve Bellovin
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24353;
23 Jul 93 23:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24346;
23 Jul 93 23:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24946;
23 Jul 93 23:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24332;
23 Jul 93 23:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24305;
23 Jul 93 23:50 EDT
Received: from BBN.COM by CNRI.Reston.VA.US id aa24930; 23 Jul 93 23:50 EDT
Date: Fri, 23 Jul 93 23:30:35 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Cyndi Mills <cmills at bbn.com>
To: ietf at CNRI.Reston.VA.US
cc: cmills at bbn.com
Subject: Who pays What?
Message-ID: <9307232350.aa24930 at CNRI.Reston.VA.US>
I should have known better than to post something just before I go on vacation
-- unless you airdrop a radio modem and a battery-powered laptop into the right
place in the wilderness for me, I'm off the ether for a week or so.
Anyway, my intention was to point out that there ARE different classes and
levels of service which are not entirely dependent on connection speed
And we need to allocate the INCREMENTAL costs of growing the network somehow,
and it would be nice to approximate a reasonably fair and measurable
method.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24576;
24 Jul 93 0:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24569;
24 Jul 93 0:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25899;
24 Jul 93 0:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24555;
24 Jul 93 0:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24529;
24 Jul 93 0:15 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa25853;
24 Jul 93 0:15 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA08967; Sat, 24 Jul 93 00:16:17 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA02813; Sat, 24 Jul 93 00:18:31 EDT
Message-Id: <9307240418.AA02813 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: Peter Deutsch <peterd at bunyip.com>
Cc: Cyndi Mills <cmills at bbn.com>, ietf at CNRI.Reston.VA.US, john at iastate.edu
Subject: Re: Saturating the links... (was: Re: Posting by Goodfellow)
In-Reply-To: Your message of "Thu, 22 Jul 93 19:08:10 EDT."
<9307222308.AA12659 at expresso.bunyip.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 24 Jul 93 00:18:31 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
Peter Deutsch <peterd at bunyip.com> writes:
>that determines if the overall system will saturate. A 56k
>connection cannot source or sink more than 56k of data, no
>matter how hard we try so even if a single user is
A 56k connection may not be able to succesfully sink more than 56k, but
it can easily cause unbounded amounts of traffic to be generated over an
arbitrary backbone.
Obvious examples:
Generate a stream of pings first to a site with long response time (I've
seen links with a response time of over 30 seconds). Then switch to a
closer host; traffic will peak way above 56k.
Request a file using some unconfirmed UDP based protocol from a site with
a faster connection; traffice on the backbone will be generated at the
faster rate. For unbounded growth, request transfers from more sites
simultaneously.
Send to a multicast address (coughs, looks innocent)
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01744;
24 Jul 93 9:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01735;
24 Jul 93 9:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14690;
24 Jul 93 9:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01707;
24 Jul 93 9:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01638;
24 Jul 93 9:43 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14503;
24 Jul 93 9:43 EDT
Received: from itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-12)
id <AA22638>; Sat, 24 Jul 1993 06:43:54 -0700
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA01036; Sat, 24 Jul 93 09:43:48 EDT
Date: Sat, 24 Jul 93 09:43:48 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ran Atkinson <atkinson at itd.nrl.navy.mil>
Message-Id: <9307241343.AA01036 at itd.nrl.navy.mil>
To: ietf at isi.edu
Subject: who pays for what ?
I think that the continuance of the currently widespread "pay by the
size of your pipe, not by usage of that pipe" is important to the
continuance of the current (mostly good) Internet culture and to making
the Internet more useable by more people.
In a world where we have resource reservation, this model can continue.
However, a pipe of size N where no "resource reservation" traffic is
sent would reasonably be cheaper than a pipe of size N where some
"resource reservation" traffic (e.g. MBONE only) is used and would in
turn be cheaper than that pipe of size N where unlimited amounts of
traffic use "resource reservation" hooks. The important thing is that
the ordinary (ftp/telnet/no flows) customer continue to get "basic service"
at a flat rate that is reasonably low.
Ran
atkinson at itd.nrl.navy.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01755;
24 Jul 93 9:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01743;
24 Jul 93 9:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14691;
24 Jul 93 9:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01708;
24 Jul 93 9:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01668;
24 Jul 93 9:46 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14548;
24 Jul 93 9:46 EDT
Received: from itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-12)
id <AA22773>; Sat, 24 Jul 1993 06:47:30 -0700
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA01051; Sat, 24 Jul 93 09:47:28 EDT
Date: Sat, 24 Jul 93 09:47:28 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ran Atkinson <atkinson at itd.nrl.navy.mil>
Message-Id: <9307241347.AA01051 at itd.nrl.navy.mil>
To: ietf at isi.edu
Subject: congestion & personal computing
One concern that I have is that the sundry small startup implementations
of TCP/IP for { Macintosh, DOS, Windows, Windows/NT, etc} might omit the
VJCC algorithms to cut development costs. I would assert that those kinds
of systems will be a huge part of the Internet very soon (Windows/NT includes
a TCP/IP stack with every copy as a bundled part of the OS) and it is really
important that they include the VJCC algorithms.
I don't know how to affect what gets implemented, but if a bunch of NT
machines appear on your net and things start to go south it might be wise
to see whether NT does things right. Earlier implementations of TCP inside
the NT beta (from last spring) didn't get the window aspects fully correct.
Microsoft indicated that they would look into things, but I never heard
if that was fully corrected.
Ran
atkinson at itd.nrl.navy.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04164;
24 Jul 93 18:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04157;
24 Jul 93 18:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07011;
24 Jul 93 18:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04143;
24 Jul 93 18:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04121;
24 Jul 93 18:15 EDT
Received: from cdp.igc.org by CNRI.Reston.VA.US id aa06991; 24 Jul 93 18:15 EDT
Received: by igc.apc.org (4.1/Revision: 1.100 )
id AA15005; Sat, 24 Jul 93 15:15:17 PDT
Received: by nexsys.nexsys.net (4.1/SMI-4.1)
id AA00766; Sat, 24 Jul 93 15:12:43 PDT
Date: Sat, 24 Jul 93 15:12:43 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Geoff White <geoffw at nexsys.net>
Message-Id: <9307242212.AA00766 at nexsys.nexsys.net>
To: peterd at bunyip.com, ses at tipper.oit.unc.edu
Subject: Re: Saturating the links... (was: Re: Posting by Goodfellow)
Cc: cmills at bbn.com, ietf at CNRI.Reston.VA.US, john at iastate.edu
>
> Peter Deutsch <peterd at bunyip.com> writes:
>
> >that determines if the overall system will saturate. A 56k
> >connection cannot source or sink more than 56k of data, no
> >matter how hard we try so even if a single user is
>
> A 56k connection may not be able to succesfully sink more than 56k, but
> it can easily cause unbounded amounts of traffic to be generated over an
> arbitrary backbone.
> Obvious examples:
> Generate a stream of pings first to a site with long response time (I've
> seen links with a response time of over 30 seconds). Then switch to a
> closer host; traffic will peak way above 56k.
>
> Request a file using some unconfirmed UDP based protocol from a site with
> a faster connection; traffice on the backbone will be generated at the
> faster rate. For unbounded growth, request transfers from more sites
> simultaneously.
Can anyone provide some metrics or formulars for estimating aggregate
bandwidth in situations like these. In other words, If I have several
users in a say, ISDN network, where several workstations will be "single
user" (some 56 kbps(B) some 2x 56kbs(2B) links, as well as several links with
LANs on the other side. All of these ISDN links feed into a "Hub" which
has a T1 grade link into some backbone
cloud. What kind of model, with what kind of parameters do I have to
construct to estimate the actual loading on the T1 in response to the
type and number of users that are coming in on the ISDN lines? I.e.
one T1 is equivalent in bandwidth to around 23 ISDN B channels, but
even the most tenacious single user, would have a hard time driving a B
channel at 56 kbps for a majority of the hours in a day. I would think
that single user traffic would be very bursty, with potentially major
spikes due to ftp transfers or other high volume traffic; but you could
also expect a lot of idle time, (after so many seconds the line would
be "taken down" and re-established when packets started to flow again),
LANs using ISDN links , I would think, would opperate with a lot less
idle time. What happens to service for aggregates of users as the idle
time (headroom) on the link decreases? Has anyone written any papers
or articles on this? Can anybody recommend and books or software or
whatever?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15703;
25 Jul 93 15:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15696;
25 Jul 93 15:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25470;
25 Jul 93 15:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15681;
25 Jul 93 15:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15635;
25 Jul 93 14:54 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa25291;
25 Jul 93 14:54 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA02791; Sun, 25 Jul 93 14:54:58 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA03647; Sun, 25 Jul 93 14:57:13 EDT
Message-Id: <9307251857.AA03647 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: ietf at CNRI.Reston.VA.US
Subject: Experiments in Remote Audio playback and recording
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 25 Jul 93 14:57:13 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
Whilst we're talking about a scheme for remote printing, I thought I might
as well mention a smaller scale experiment which I prepared before Amsterdam.
Thanks to the addition of a Pacific Microsystems DSP board with an interface
that allows input and output to a two-wire circuit, tipper is able to
make use of audio technology separate from the speaker and microphone
bundled with all sparc-stations. Output devices can be selected by
the use of combinations of two tones, and 8-bit ulaw signals can be send
and recieved.
An async version of the software was completed before the IETF, and a
synchronus version was in-progress when the airport shuttle arrived.
It is interested to speculate how such technology might function using a
similar infrastructure to that used by the remote printing experiment.
Simon // ses at 1-919-933-0102.tpc.int
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26634;
26 Jul 93 7:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26627;
26 Jul 93 7:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29672;
26 Jul 93 7:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26609;
26 Jul 93 7:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26546;
26 Jul 93 7:34 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa29603;
26 Jul 93 7:34 EDT
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.61+local-12)
id <AA04105>; Mon, 26 Jul 1993 04:35:08 -0700
Message-Id: <199307261135.AA04105 at venera.isi.edu>
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.28485-0 at bells.cs.ucl.ac.uk>; Mon, 26 Jul 1993 12:34:49 +0100
To: Ran Atkinson <atkinson at itd.nrl.navy.mil>
Cc: ietf at isi.edu
Subject: Re: congestion & personal computing
In-Reply-To: Your message of "Sat, 24 Jul 93 09:47:28 EDT." <9307241347.AA01051 at itd.nrl.navy.mil>
Date: Mon, 26 Jul 93 12:34:48 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
> One concern that I have is that the sundry small startup implementations
>of TCP/IP for { Macintosh, DOS, Windows, Windows/NT, etc} might omit the
>VJCC algorithms to cut development costs. I would assert that those kinds
>of systems will be a huge part of the Internet very soon (Windows/NT includes
>a TCP/IP stack with every copy as a bundled part of the OS) and it is really
>important that they include the VJCC algorithms.
If anyone does this, I suggest they get a very very black mark against
anyone's shopping list - they have no excuse - one feature of Van's
ideas is that they are expressed in smaller code than systems without
them. ANother is that the source code is freely available, therefore
there are no excuses permissable.
A feature of the Internet Protocols and Community that distinguishes
it from other standards making bodies is the specification
of sensible implementation strategies by example as opposed to
exclusion of these factors from standards as being part of the so-called
"value" added by vendors that other standards communities feel
obliged to protect.
> I don't know how to affect what gets implemented, but if a bunch of NT
>machines appear on your net and things start to go south it might be wise
>to see whether NT does things right.
of course, there are other reasons you might want to think twice
about NT in the light of (sic) memory factories burning down and
spiralling PC upgrade costs....:-)
jon
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00645;
26 Jul 93 10:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06479;
26 Jul 93 10:12 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00624;
26 Jul 93 10:12 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa00514;
26 Jul 93 10:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iiir at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-iiir-html-01.txt, .ps
Date: Mon, 26 Jul 93 10:07:54 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307261007.aa00514 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integration of Internet
Information Resources Working Group of the IETF.
Title : Hypertext Markup Language (HTML): A Representation of
Textual Information and MetaInformation for Retrieval
and Interchange
Author(s) : T. Berners-Lee, D. Connolly
Filename : draft-ietf-iiir-html-01.txt, .ps
Pages : 41
HyperText Markup Language (HTML) can be used to represent
Hypertext news, mail, online documentation, and collaborative hypermedia;
Menus of options;
Database query results;
Simple structured documents with inlined graphics.
Hypertext views of existing bodies of information.
The World Wide Web (W3) initiative links related information throughout the
globe. HTML provides one simple format for throughout the globe. HTML
provides one simple format for providing linked information, and all W3
compatible programs are required to be capable of handling HTML. W3 uses
an Internet protocol (Hypertext Transfer Protocol, HTTP), which allows
transfer representations to be negotiated between client and server, the
result being returned in an extended MIME message. HTML is therefore just
one, but an important one, of the representations used with W3.
HTML is proposed as a MIME content type.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iiir-html-01.txt".
Or
"get draft-ietf-iiir-html-01.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-iiir-html-01.txt".
Or
"SEND draft-ietf-iiir-html-01.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-iiir-html-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iiir-html-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00970;
26 Jul 93 10:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00963;
26 Jul 93 10:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07334;
26 Jul 93 10:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00948;
26 Jul 93 10:31 EDT
Received: from pilot.njin.net by IETF.CNRI.Reston.VA.US id aa00881;
26 Jul 93 10:29 EDT
Received: by pilot.njin.net (5.59/SMI4.0/RU1.5/3.08)
id AA11985; Mon, 26 Jul 93 10:30:11 EDT
Date: Mon, 26 Jul 93 10:30:08 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tp Brisco <brisco at pilot.njin.net>
To: jim at tadpole.com
Cc: ietf at IETF.CNRI.Reston.VA.US
X-Mm: A real program for real people!
X-Phone: (908) 932-2351
X-Fax: (908) 932-2968
Reply-To: brisco at pilot.njin.net
Subject: Re: uk national press...on IPng
In-Reply-To: Your message of Fri, 23 Jul 93 16:15:11 GMT
Message-Id: <CMM-RU.1.3.743697008.brisco at pilot.njin.net>
> > Automatic address allocation effectively negates any ability
> > of people to trace back the who/where/when when things are going
> > awry .... Let's try and think of it more along the lines of
> > the automatic resolution of system parameters, rather than the
> > dynamic generation of system parameters. Let's face it, in
> > a large network, some level of central control is a dire
> > necessity ...
>
> If you're depending on your addressing being static enough
> that you can catch people, you're operating under a false sense
> of security.
>
> This has been said before, many times.
>
> Jim
>
>
No, it's more along the lines of avoiding duplicate IP addresses,
helping/finding/fixing users who decided to "fool around" with the
config, etc ....
With a probably-not-atypical network staff to machine ratio of
1:600 (10 networking staff, about 6000 machines), and a geographic
dispersement of over 100 miles, and a user base that ranges from
rocket scientists (literally) to ``Kelly Girls'' (data entry types
hired for maybe a week at a clip), a basic level of centralized
control works decidedly in our favor (btw: it's the rocket
scientists that give us the problems :-).
Having deterministic IP addresses (dynamically obtained - we're
currently using BOOTP) enable us to use the ethernet address, IP
address, and other extraneous information (such as highly specific
location information that we drop into the DNS "TXT" records) to do
99% of our low-level network troubleshooting from our desks.
Additionally, other centrally configurable options - such as the
nameserver - allow us to account for known forthcoming outages with a
minimum amount of pain.
Other designs, such as the most recent work of the Resource
Location Group, provides at least some level of centralized
administrative control (their "servers"). There are a number of
tradeoffs between the convenience of fully dynamic information vs.
fully static information -- frankly I'd rather go back to host tables
before going with something like fully dynamic addressing like
AppleTalk (the last screwup - a vendor dialed in via AppleTalk Remote
- took us about two weeks to clean up). Granted, AppleTalk has
other braindeath that would (hopefully) not exist in IP, but at
least let's learn from the mistakes of others ....
Tp.
...!rutgers!brisco (UUCP) brisco at pilot.njin.net (ARPA)
brisco at ZODIAC (BITNET) 908-932-2351 (VOICE)
T.P. Brisco, Manager of Network Operations, Computing Services
Rutgers University, Piscataway, NJ 08855-0879
Just say "Moo"
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04472;
26 Jul 93 13:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04465;
26 Jul 93 13:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15232;
26 Jul 93 13:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04439;
26 Jul 93 13:24 EDT
Received: from phoebus.nisc.sri.com by IETF.CNRI.Reston.VA.US id aa04394;
26 Jul 93 13:21 EDT
Received: by phoebus.nisc.sri.com (4.1/SRI-NISC1.1)
id AA19320; Mon, 26 Jul 93 10:22:06 PDT
Date: Mon, 26 Jul 93 10:22:05 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Lottor <mkl at nisc.sri.com>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: Internet Domain Survey - Jul 1993
Message-Id: <CMM.0.90.2.743707325.mkl at phoebus.nisc.sri.com>
Network Information Systems Center July 1993
SRI International Internet Domain Survey
The Domain Survey attempts to discover every host on the Internet by doing a
complete search of the Domain Name System. The latest results gathered
during mid-July 1993 are listed. For more information see RFC 1296; for
more info see the pub/zone directory on ftp.nisc.sri.com.
-- Mark Lottor
Number of Hosts, Domains, and Nets Advertised in the Domain Name System
July 1993 Apr 93 Jan 93 Oct 92 Jul 92 Change (year)
==============================================================================
Hosts: 1,776,000 1,486,000 1,313,000 1,136,000 992,000 79%
PingReply: 464,000 421,000
%ofHosts: 26% 28%
Domains: 26,000 22,000 21,000 18,100 16,300 59%
Nets:
Class A: 67 58 54 52 60 12%
Class B: 3728 3409 3206 2985 2714 37%
Class C: 9972 6255 4998 4468 3795 163%
Total: 13767 9722 8258 7505 6569 110%
Host Distribution by Top-Level Domain Name
539668 edu 27033 fi 3165 nz 498 my 19 bg
460848 com 25151 no 3092 cs 455 si 15 ro
109550 gov 18305 net 2734 cz 415 tr 13 tn
91987 de 14746 it 2093 mx 349 su 13 gb
89788 uk 11741 at 1956 pt 298 ve 10 lv
88163 mil 8773 es 1802 sg 238 ee 4 aq
82157 au 7337 za 1728 ie 223 sk 3 ua
70977 ca 6232 hk 1403 hu 186 lu 2 yu
39860 fr 6160 dk 1340 us 175 int 2 li
39359 org 5625 kr 1317 gr 110 in 2 ar
35639 jp 5469 tw 1259 is 101 ec
35629 nl 5244 il 1101 br 61 th
31449 se 4361 be 1073 cl 56 cr
30697 ch 3511 pl 504 hr 30 cy
Host Distribution by Top-Level Domain Name
of Hosts Responding to a Ping
163532 edu 7194 nl 872 il 286 sg 30 ec
87602 com 6864 se 805 za 214 hu 20 hr
42431 gov 5297 org 795 hk 128 tr 16 cy
26462 de 5068 fi 670 pl 123 my 9 lv
24986 uk 4628 it 551 br 117 si 6 gb
23865 mil 2809 at 549 gr 70 sk 4 bg
23479 ca 2259 tw 517 cs 70 ee 3 ro
13966 jp 2115 es 381 cz 64 ve 2 li
12713 fr 1907 dk 378 us 64 int 1 yu
11886 au 1775 kr 329 is 52 in 1 tn
7943 ch 1217 be 327 cl 40 lu
7498 net 937 nz 321 pt 38 su
7320 no 908 mx 300 ie 34 cr
Top 50 Host Names
795 venus 578 mac2 446 mac4 410 titan 381 calvin
747 pluto 569 charon 443 pc3 401 sirius 378 phoenix
710 cisco 545 iris 442 alpha 398 fred 378 pc4
675 mars 539 mercury 434 apollo 394 gateway 378 mac13
672 gw 524 pc2 426 mac10 393 merlin 375 mac8
659 zeus 496 mac3 423 mac5 391 hobbes 371 mac14
640 jupiter 484 orion 419 thor 385 mac6 368 athena
615 mac1 478 eagle 418 ns 384 mac12 364 mac9
613 pc1 461 newton 416 hermes 382 mac7 360 mac15
607 saturn 459 neptune 411 gauss 381 mac11 356 ariel
Frequently Asked Questions about the Domain Survey
What do all those domain names stand for?
See pub/zone/iso-country-codes on ftp.nisc.sri.com.
Why do only 26% of the advertised hosts answer a ping?
Many advertised hosts are behind firewalls that only allow email
to get through. Technically, they would not be considered hosts
that are directly on the Internet. Smaller hosts such as PCs might
be turned off when they are not in use. Also, some pings are probably
lost due to links being down, and/or problems with the pinging process.
Where can I get more information?
See the pub/zone directory on ftp.nisc.sri.com.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04805;
26 Jul 93 13:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04797;
26 Jul 93 13:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17039;
26 Jul 93 13:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04779;
26 Jul 93 13:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04729;
26 Jul 93 13:56 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa16837;
26 Jul 93 13:56 EDT
Received: from netmail.microsoft.com by venera.isi.edu (5.65c/5.61+local-12)
id <AA15625>; Mon, 26 Jul 1993 10:57:34 -0700
Received: by netmail.microsoft.com (5.65/25-eef)
id AA24759; Mon, 26 Jul 93 10:56:12 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: jallard at microsoft.com
Message-Id: <9307261756.AA24759 at netmail.microsoft.com>
To: atkinson at itd.nrl.navy.mil
Cc: ietf at isi.edu
Subject: Re: congestion & personal computing
Date: Mon, 26 Jul 93 10:51:40
X-Orig-Sender: ietf-request at IETF.CNRI.Reston.VA.US
Ron> One concern that I have is that the sundry small startup
Ron> implementations of TCP/IP for { Macintosh, DOS, Windows,
Ron> Windows/NT, etc} might omit the VJCC algorithms to cut development
Ron> costs. I would assert that those kinds of systems will be a huge
Ron> part of the Internet very soon (Windows/NT includes a TCP/IP stack
Ron> with every copy as a bundled part of the OS) and it is really
Ron> important that they include the VJCC algorithms.
Ron> I don't know how to affect what gets implemented, but if a bunch of
Ron> NT machines appear on your net and things start to go south it
Ron> might be wise to see whether NT does things right.
microsoft is committed to supporting a fully interoperable tcp/ip
implementation on windows nt, including the vjcc algorithm. there was a
vjcc bug a long way back, but has since been resolved. as a side, our
interoperability testing has identified several unix-based systems which
do not support vjcc.
if you're interested in windows nt's tcp/ip behaviour, i recommend
connecting to our internet test server via anonymous ftp:
rhino.microsoft.com. our team frequents comp.protocols.tcp-ip.ibmpc as
well as the windows nt-related newsgroups to try to pick up on any
problems users are experiencing with windows tcp/ip networking.
if you have a specific issue, concern, or bug wrt windows nt tcp/ip i
urge you to contact me directly or to bring it up on one of the
aforementioned newsgroups. the ietf list is best left for ietf-related
issues.
_______________________________________________________________
J. Allard jallard at microsoft.com
Program Manager of TCP/IP Technologies work: (206)882-8080
Microsoft Corporation home: (206)860-8862
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01596;
27 Jul 93 7:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01590;
27 Jul 93 7:56 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa06620; 27 Jul 93 7:56 EDT
Received: by bitsy.MIT.EDU
id AA13847; Tue, 27 Jul 93 07:46:06 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA13841; Tue, 27 Jul 93 07:46:04 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA18739; Tue, 27 Jul 93 07:46:03 EDT
Received: from gza-server.aktis.com by pad-thai.aktis.com (8.4/) with SMTP
id <HAA21172 at pad-thai.aktis.com>; Tue, 27 Jul 1993 07:46:21 -0400
Received: by gza-server.aktis.com (4.1/4.7) id AA04071; Tue, 27 Jul 93 07:46:20 EDT
Message-Id: <9307271146.AA04071 at gza-server.aktis.com>
To: cat-ietf at mit.edu
Cc: linn at gza.com
Subject: Working draft Amsterdam CAT minutes
Date: Tue, 27 Jul 1993 07:46:20 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at gza.com>
Here's a snapshot draft of the Amsterdam CAT WG minutes; Sam Sjogren
is compiling an update which will add further detail on the FTP security
discussion.
--jl
The CAT WG met for two sessions at the Amsterdam IETF, discussing (in
about equal proportion) general CAT issues and FTP security integration.
REVIEW OF ACTIVITIES
We reviewed the status of CAT-related documents: GSS-API and GSS-API
C bindings are in the hands of the RFC editor pending advancement to
Proposed Standards, as is the Kerberos V5 protocol document. The
Kerberos V5 GSS-API implementation has not received recent development
effort, and is not currently compliant, but a plan to make volunteer
resources available is being explored.
Chuck McManis discussed CAT-related activities ongoing at Sun. Sun
currently supports Kerberos V4, and plans to migrate to V5. Kerberos
is invoked (using its native interface, rather than GSS-API) from RPC.
Separate work on layering RPC atop GSS-API had been ongoing at Sun,
but has not yet yielded conclusive results. One of the U.S. National
Laboratories had ported beta 2 of Kerberos V5 to Solaris, and Sun is
working with the resultant code base.
CAT TECHNICAL DISCUSSION
Two proposals for incremental changes to the GSS-API documents were
considered: a terminology change in response to a request from X/Open,
renaming the per-message protection primitives from GSS_Sign to
GSS_GetMIC, GSS_Seal to GSS_Wrap, GSS_Verify to GSS_VerifyMIC, and
GSS_Unseal to GSS_Unwrap (to avoid conflict with other usage, without
change to function, preserving (though deprecating use of) existing
names in existing code for backward compatibility) was tentatively
accepted pending E-mail review.
In evaluating the request and considering alternatives, it was
observed that ISO's usage of the term "seal" echoes the notion of
applying a wax seal to a document. It was also observed that the
current Kerberos V5 implementation of GSS_Sign emits a token
containing the entirety of the input message rather than just a
signature.
It was also observed that no GSS-API per-message protection interface
currently exists to provide confidentiality without integrity, and
post-meeting review (GSS-API spec, Sec. 1.2.2) confirmed the related
point that mechanisms indicating the availability of per-message
confidentiality services are also expected to indicate and offer
per-message integrity. No definitive conclusion was reached about the
level of demand for confidentiality without integrity.
A proposal to add GSS_set_default_cred and GSS_lookup_default_cred
routines was rejected for reasons of semantics which were considered
to be environment-specific (though considered as a likely initial
entry in a set of extensions for POSIX and like environments). Much
of the motivation for this feature derives from a desire to control
the set of credentials which will be transferred by inheritance across
the UNIX fork operation. It was observed that it would be difficult
to implement the set_default_cred function within the current Kerberos
V5 code base, and that different implementors could implement the
proposal as defined with conflicting semantics which would not support
application portability. Given an observation that credentials
structures are ephemeral, use of acquire_cred with (non-ephemeral)
principal names as arguments was recommended as an alternative
approach which would survive UNIX forks.
Chuck McManis expressed interest in using set_default_cred as a means
to spawn threads using different mechanisms for different threads, and
saw this as a more critical priority than use of different identities
within a single mechanism; he also expressed a desire that credentials
be "lightweight" structures.
FOLLOW-ON TASKS AND ACTION ITEMS
Follow-on tasks identified were: Kerberos V5 GSS-API mechanism spec
and code enhancement, Kerberos V4 GSS-API implementation, "negotiated"
mechanism definition (a task to which a framework discussion authored
by Bob Blakely and forwarded to the list was considered relevant),
CATS stream-oriented overlay definition, documentation of mechanism
implementor's guidance/agreements, environment-specific specifications
and extensions (e.g., credential inheritance semantics). Individuals
and subset groups were associated with several of these items. Activity
on the "negotiated" mechanism's design was argued as not being critical
at this time; it will assume greater importance once multiple mechanisms
are actively supported.
FTP SECURITY
These are brief notes on the FTP Security discussions conducted during
the CAT sessions at Amsterdam IETF.
The bulk of the work done during the sessions was review of the changes
made to the FTP Security Internet-draft since the previous meeting.
Steve Lunt, the editor of the draft, participated in the second session
via speaker phone.
Aside from small clarifications and corrections, the main issues
addressed were the detection of support for integrity and privacy
with various mechanisms, buffer size limitations, and principal
naming. Some progress was made on these issues, but there will need
to be more discussion on the mailing list before resolution is
achieved, especially on the subject of the size of buffer used on
protected file transfers.
In general, the draft RFC has achieved a high level of refinement.
After the latest round of changes are made to the document, the
next step will be to solicit several independent implementations
and test interoperability. It is hoped that by the next IETF we
will have acquired more implementation experience.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02325;
27 Jul 93 8:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02318;
27 Jul 93 8:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08557;
27 Jul 93 8:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02294;
27 Jul 93 8:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02049;
27 Jul 93 8:27 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08068;
27 Jul 93 8:27 EDT
Received: from mwunix.mitre.org by venera.isi.edu (5.65c/5.61+local-12)
id <AA00878>; Tue, 27 Jul 1993 05:27:32 -0700
Return-Path: <DURST_B%HOUSTON1 at MWMGATE1.mitre.org>
Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2)
id AA14237; Tue, 27 Jul 1993 08:27:29 -0400
Message-Id: <199307271227.AA14237 at mwunix.mitre.org>
Date: Tue, 27 Jul 93 08:28:45 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: DURST_B%HOUSTON1 at mwmgate1.mitre.org
To: ietf at isi.edu
Subject: Invitation and Payment-P1003.12
---------------------------------- Forwarded ----------------------------------
From: durst_b at houston1
Date: 7/26/93 2:56PM
*To: posix-net-ptp%ucbvax.cs.Berkeley.EDU at ucbvax.Berkeley.EDU at -smtp-
*To: socket-friends%vangogh.cs.Berkeley.EDU at ucbvax.Berkeley.EDU at -smtp-
*cc: akaczmar at stdsmail.ieee.org at -smtp-
*cc: a.oneill at ieee.org at -smtp-
Subject: Invitation and Payment-P1003.12
-------------------------------------------------------------------------------
---------------------------- Forwarded with Changes ---------------------------
From: akaczmar at stdsmail.ieee.org (A.Kaczmarek) at -smtp-
Date: 7/26/93 10:31AM
*To: durst at mitre.org at -smtp-
Subject: Invitation and Payment-P1003.12
-------------------------------------------------------------------------------
To .12ers, XTI folk, and socket friends:
Here's an invitation to ballot on the .12 document. We're scheduled to start
the official ballot period September 15 and end the 30-day ballot period on
October 15, which will allow us to begin ballot resolution at the October
meeting (10/18-22/93, Bethesda, MD). If we slip at all, we'll miss the ballot
window. Not good. Very not good. The critical dates to us to hit that ballot
window are these: 8 August, final document revisions in to Chris Harding for
incorporation into Draft 4 (the version going out to ballot); 30 August -
ballot group closes (if you're not in by then, you're out); 15 October - all
ballot responses back in, WITH STRONG PREFERENCE FOR EMAIL COMMENTS (full
instructions will be in an annex of the draft - observe the instructions
meticulously!).
Anyway, here's what to do now: Get in the ballot pool. The form follows this
note. Fill it out and return it to IEEE. There are three ways to pay: check,
NAPS account deduction, or credit card. You can physically return the form via
snail mail with any of those forms of payment. You can fax it with a credit
card or NAPS deduction. You can email it specifying a NAPS deduction. Get the
form and whatever payment you choose to use back to IEEE ASAP! August 30 is
the absolute latest if we are going to get our document out and start ballot
September 15. Don't even THINK of returning the form to the IEEE without some
form of payment. They won't know what to do with it, and will probably just
dump your request on the floor.
Anybody still working on changes to the document: time is running out. Get
your changes wrapped up and in by 8 August. Chris needs at least a week to
finish up the document, get it printed, and get it shipped to the IEEE. Give
him a break, he deserves it.
Keith and Chris, can you give this invitation a home where folks can get at it?
If so, announce where it is to the appropriate folks. People may receive this
email and also a hardcopy version. If so, fine. Respond to one of them.
(Responding to both won't get you two votes, I don't think.)
I'd say we're on the home stretch, but we're not. However, I think we're about
to have a major "change of life". Let's get on with it. Thanks for your help.
(Don't quit now!)
Regards,
Bob Durst
Chairman, IEEE P1003.12
durst at mitre.org
Bob,
Following is the info you requested. Top & Bottom margin = 1.00, Left & Right
= .50; Courier 12.
Call me if you have any problems.
Anna
============= snip snip ==========================================
Portable Application Standards Committee
of the IEEE Computer Society Invites You to Ballot On
P1003.12 Standard for Information Technology -- Portable Operating System
Interfaces (POSIX) -- PART 1: API Network Process-to-Process Communication
RETURN DEADLINE: 30 August 1993
SCOPE: To define a programmatic interface for network process-to-process
communication.
PURPOSE: To provide a programmatic interface that allows a protable
application
to communi-
cate with another entity in a network such that the aplication may be
independent of the underlying protocols. Furthermore, access to
protocol-specific features will be made available in a protocol-independent
framework.
Your Category of Interest in this Standards Ballot:
User Producer Academic General Interest
(Note: Please choose only ONE of the above. If you have any combination of
Interests, check the General Interest Category)
Name: Phone:
Company
Mailing Address
FAX: EMail:
IEEE or Computer Society Membership Number*:
Check here if NOT a member of IEEE or the Computer Society
[One of the two above lines must be filled out]
*Only IEEE or Computer Society members are eligible to ballot on IEEE proposed
Standards; non-members can participate as Non-Voters
Signature: Date
If you want positive confirmation back by mail that this form has been received
by the IEEE Standards Office, please enclose a stamped, pre-addressed post card
along with this form.
Please return to: Annamarie Kaczmarek
by IEEE Standards Office
30 August 1993 445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
FAX: 908/562-1571
Payment Form to Ballot on PASC
Be sure to include form indicating WHICH balloting
groups you are specifying payment:
1. Circle the total fee that corresponds to the quantity requested.
STANDARD - P1003.4b STANDARD - P1003.12
$50 $50
TOTAL______________________
*********************************************************************
2. Check one for payment method.
[___] Payment enclosed
Make check payable to: "IEEE"
in US dollars on US bank
[___] Deduct from my NAPS account
[___] Charge to credit card indicated
[____] American Express
[____] MasterCard/EuroCard
[____] Diners Club
[____] Visa
Card No. Exp. Date:
Signature Date:
Name: Please Print
*********************************************************************
3. Billing address for charge:
Address:
Please keep a copy of this form for your files!
Return by deadline on accompanying form indicating WHICH groups you are
specifying payment to:
Annamarie Kaczmarek
IEEE Standard Office
P.O. Box 1331
Piscataway NJ 08855-1331
FAX: 908/562-1571
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03998;
27 Jul 93 9:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13179;
27 Jul 93 9:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03942;
27 Jul 93 9:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03756;
27 Jul 93 9:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: frftc at nsco.network.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-frnetmib-fr-02.txt
Date: Tue, 27 Jul 93 09:46:00 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307270946.aa03756 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Frame Relay Service MIB
Working Group of the IETF.
Title : Definitions of Managed Objects for Frame Relay Service
Author(s) : T. Brown
Filename : draft-ietf-frnetmib-fr-02.txt
Pages : 39
This memo defines an extension to the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Frame Relay Service.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-frnetmib-fr-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-frnetmib-fr-02.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-frnetmib-fr-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-frnetmib-fr-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04007;
27 Jul 93 9:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13181;
27 Jul 93 9:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03941;
27 Jul 93 9:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03852;
27 Jul 93 9:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tn2370e at list.nih.gov
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-tn3270e-enhancements-00.txt
Date: Tue, 27 Jul 93 09:47:51 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307270947.aa03852 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Telnet TN3270 Enhancements
Working Group of the IETF.
Title : TN3270 Enhancements
Author(s) : B. Kelly
Filename : draft-ietf-tn3270e-enhancements-00.txt
Pages : 27
This document describes a protocol that more fully supports 3270 devices
than do the existing tn3270 practices. Specifically, it defines a method
of emulating both the terminal and printer members of the 3270 family of
devices via Telnet; it provides for the ability of a Telnet client to
request that it be assigned a specific device-name (also referred to as "LU
name" or "network name"); finally, it adds support for a variety of
functions such as the ATTN key, the SYSREQ key, and SNA response handling.
This protocol would be negotiated and implemented under a new Telnet Option
and would be unrelated to the Telnet 3270 Regime Option as defined in RFC
1041.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tn3270e-enhancements-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-tn3270e-enhancements-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-tn3270e-enhancements-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tn3270e-enhancements-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04033;
27 Jul 93 9:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13187;
27 Jul 93 9:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03945;
27 Jul 93 9:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03790;
27 Jul 93 9:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-haller-auth-requirements-00.txt
Date: Tue, 27 Jul 93 09:46:24 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307270946.aa03790 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Authentication Requirements
Author(s) : N. Haller, R. Atkinson
Filename : draft-haller-auth-requirements-00.txt
Pages : 8
The authentication requirements of computing systems and network protocols
vary greatly with their intended use, accessibility, and their network
connectivity. This document describes a spectrum of authentication
technologies and provides guidance to protocol developers on what kinds of
authentication might be suitable for what kinds of protocols and
applications used in the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-haller-auth-requirements-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-haller-auth-requirements-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-haller-auth-requirements-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-haller-auth-requirements-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04046;
27 Jul 93 9:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13203;
27 Jul 93 9:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03944;
27 Jul 93 9:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03728;
27 Jul 93 9:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mospf at comet.cit.cornell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mospf-analysis-02.txt
Date: Tue, 27 Jul 93 09:45:34 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307270945.aa03728 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Multicast Extensions to OSPF
Working Group of the IETF.
Title : MOSPF: Analysis and Experience
Author(s) : J. Moy
Filename : draft-ietf-mospf-analysis-02.txt
Pages : 14
This memo documents how the MOSPF protocol satisfies the requirements
imposed on Internet routing protocols by "Internet Engineering Task Force
internet routing protocol standardization criteria" ([RFC 1264]). This
memo provides information for the Internet community. It does not specify
any Internet standard. Distribution of this memo is unlimited.
Please send comments to mospf at gated.cornell.edu.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mospf-analysis-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-mospf-analysis-02.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-mospf-analysis-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mospf-analysis-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab04051;
27 Jul 93 9:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13206;
27 Jul 93 9:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03946;
27 Jul 93 9:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03701;
27 Jul 93 9:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospfigp at trantor.umd.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-ospf-version2-03.txt, .ps
Date: Tue, 27 Jul 93 09:45:12 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307270945.aa03701 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Open Shortest Path First IGP
Working Group of the IETF.
Title : OSPF Version 2
Author(s) : J. Moy
Filename : draft-ietf-ospf-version2-03.txt, .ps
Pages : 212
This memo documents version 2 of the OSPF protocol. OSPF is a link-state
routing protocol. It is designed to be run internal to a single Autonomous
System. Each OSPF router maintains an identical database describing the
Autonomous System's topology. From this database, a routing table is
calculated by constructing a shortest-path tree.
OSPF recalculates routes quickly in the face of topological changes,
utilizing a minimum of routing protocol traffic. OSPF provides support
for equal-cost multipath. Separate routes can be calculated
for each IP Type of Service. An area routing capability is provided,
enabling an additional level of routing protection and a reduction
in routing protocol traffic. In addition, all OSPF routing protocol
exchanges are authenticated.
OSPF Version 2 was originally documented in RFC 1247. The differences
between RFC 1247 and this memo are explained in Appendix E. The
differences consist of bug fixes and clarifications, and are
backward-compatible in nature. Implementations of RFC 1247 and of this
memo will interoperate.
Please send comments to ospf at gated.cornell.edu.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ospf-version2-03.txt".
Or
"get draft-ietf-ospf-version2-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-ospf-version2-03.txt".
Or
"SEND draft-ietf-ospf-version2-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-ospf-version2-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-version2-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05080;
27 Jul 93 11:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05073;
27 Jul 93 11:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16412;
27 Jul 93 11:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05060;
27 Jul 93 11:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05021;
27 Jul 93 11:08 EDT
Received: from [134.9.48.4] by CNRI.Reston.VA.US id aa16213; 27 Jul 93 11:08 EDT
Received: from framsparc.ocf.llnl.gov.ocf by ocfmail.ocf.llnl.gov (4.1/SMI-4.0)
id AA18249; Tue, 27 Jul 93 08:09:31 PDT
Received: by framsparc.ocf.llnl.gov.ocf (4.1/SMI-4.1)
id AA03907; Tue, 27 Jul 93 08:09:29 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Boolootian <booloo at framsparc.ocf.llnl.gov>
Message-Id: <9307271509.AA03907 at framsparc.ocf.llnl.gov.ocf>
Subject: The Electronic Newsstand
To: ietf at CNRI.Reston.VA.US
Date: Tue, 27 Jul 1993 08:09:28 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4487
For Immeditate Release
Contact : Paul Vizza
(202) 331-7494
Info at enews.com
ELECTRONIC NEWSSTAND Launched on the Global Internet
(New York, July 25, 1993)-- The New Republic, Inc. of Washington,
D.C. and The Internet Company of Hudson, MA today launched Electronic
Newsstand Inc., a new company created to market subscription and single
copy sales for magazine publishers via the Global Internet -- the worldwide
computer communications network spanning more than 45 countries and 5
continents. The new company will also be involved in providing advertisers
access to Internet.
"We think this could become the newest and most efficient subscription
source for a wide range of publishers," says Jeffrey Dearth, President of
The New Republic magazine, founder and CEO of Electronic Newsstand Inc.
"The estimated 10 to 15 million Internet users can browse the table of
contents and selected articles from the publications of our newsstand 24
hours a day, seven days a week, and send orders to us electronically. It's
like being in the mail every day as far as circulation acquisition is
concerned. The publishing industry has been looking for a new subscription
source, and this is it, particularly as the Internet continues to grow
among consumers."
Publications that have signed up during the launch phase include: The
New Yorker, The Economist, The New Republic, Foreign Affairs, National
Review, Technology Review, Eating Well, Outside Magazine, The Journal of
NIH Research, The Source, and New Age Journal. These magazines will
receive subscription and single copy orders daily via electronic mail
generated by Electronic Newsstand. Other publications will be invited to
participate in the Electronic Newsstand in the coming months.
"The culture of the Global Internet is such that the information it
provides is shared freely and openly among its users," said Robert Raisch,
President of The Internet Company, and COO of Electronic Newsstand.
"That's why each of our first wave of publishers will be providing a table
of contents and one or more editorial features free through Electronic
Newsstand to users on the Internet."
"The idea is that the more people are exposed to a magazine's
editorial content, the more likely they are to be interested in subscribing
to a hard copy, or in purchasing a single issue. We've tested this concept
on one on-line computer network, and it works. Since the Internet is
really a collection of thousands of computer networks, all of which share
the same information, it's the next logical step," adds Dearth.
"The Internet Company was formed specifically to develop opportunities
like Electronic Newsstand," says Raisch. "Electronic Newsstand represents
one of the first attempts to develop general content specifically for the
Global Internet. As Internet users visit our 'store', so to speak, we will
provide them with valuable information about a wide range of products and
services and this will allow them to make truly informed purchasing
decisions."
"Our service is designed to showcase an advertiser's products and
services -- providing a 'point of presence' from which they can represent
their products and take orders. Once a customer accesses our service, we
are able to collect information from customers actively, by asking
questions, or passively, by simply watching where they visit and what
documents they retrieve," Raisch continues.
"Most users access the Global Internet by using personal computers
over traditional communications channels -- channels which excel at
transfering simple text. As these channels become faster and more
powerful, we'll provide a full multimedia service, including pictures,
sound and video, all over the same channel.
In the meantime, the Internet can serve vast amounts of information to
benefit advertisers and their customers. It's a win-win scenario."
---------------------------------------------------------------------------
Connecting to Electronic Newsstand --
Connections to the Electronic Newsstand are made via the 'gopher' protocol
to host 'gopher.netsys.com' on port 2100. If you are unable to use gopher
to access this host, you can telnet to gopher.netsys.com, login: enews
If you have any difficulties, please send mail to 'staff at enews.com'
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05540;
27 Jul 93 11:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17357;
27 Jul 93 11:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05513;
27 Jul 93 11:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05442;
27 Jul 93 11:34 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mospf at comet.cit.cornell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mospf-multicast-04.txt, .ps
Date: Tue, 27 Jul 93 11:33:56 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307271134.aa05442 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Multicast Extensions to OSPF
Working Group of the IETF.
Title : Multicast Extensions to OSPF
Author(s) : J. Moy
Filename : draft-ietf-mospf-multicast-04.txt, .ps
Pages : 101
This memo documents enhancements to the OSPF protocol enabling the routing
of IP multicast datagrams. In this proposal, an IP multicast packet is
routed based both on the packet's source and its multicast destination
(commonly referred to as source/destination routing). As it is routed, the
multicast packet follows a shortest path to each multicast destination.
During packet forwarding, any commonality of paths is exploited; when
multiple hosts belong to a single multicast group, a multicast packet will
be replicated only when the paths to the separate hosts diverge.
OSPF, a link-state based routing protocol, provides a database describing
the Autonomous System's topology. A new OSPF link state advertisement is
added describing the location of multicast destinations. A multicast packet's
path is then calculated by building a pruned shortest-path tree rooted at
the packet's IP source. These trees are built on demand, and the results
of the calculation are cached for use by subsequent packets.
Please send comments to mospf at gated.cornell.edu.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mospf-multicast-04.txt".
Or
"get draft-ietf-mospf-multicast-04.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-mospf-multicast-04.txt".
Or
"SEND draft-ietf-mospf-multicast-04.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-mospf-multicast-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mospf-multicast-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06096;
27 Jul 93 12:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06090;
27 Jul 93 12:18 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa19311;
27 Jul 93 12:18 EDT
Received: by bitsy.MIT.EDU
id AA17114; Tue, 27 Jul 93 12:10:45 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA17108; Tue, 27 Jul 93 12:10:43 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA27029; Tue, 27 Jul 93 12:10:42 EDT
Received: from gza-server.aktis.com by pad-thai.aktis.com (8.4/) with SMTP
id <MAA29921 at pad-thai.aktis.com>; Tue, 27 Jul 1993 12:11:01 -0400
Received: by gza-server.aktis.com (4.1/4.7) id AA04579; Tue, 27 Jul 93 12:11:00 EDT
Message-Id: <9307271611.AA04579 at gza-server.aktis.com>
To: cat-ietf at mit.edu
Cc: linn at gza.com
Subject: J. Wray query re GSS-API credentials
Date: Tue, 27 Jul 1993 12:10:59 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at gza.com>
In response to the draft CAT minutes, John Wray asks, and I forward
to the list with permission:
------- Forwarded Message
Received: from inet-gw-2.pa.dec.com by pad-thai.aktis.com (8.4/) with SMTP
id <KAA27812 at pad-thai.aktis.com>; Tue, 27 Jul 1993 10:46:20 -0400
Received: by inet-gw-2.pa.dec.com; id AA04703; Tue, 27 Jul 93 07:45:57 -0700
Received: by us1rmc.bb.dec.com; id AA16565; Tue, 27 Jul 93 10:44:29 -0400
Message-Id: <9307271444.AA16565 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Tue, 27 Jul 93 10:44:29 EDT
Date: Tue, 27 Jul 93 10:44:29 EDT
From: "John Wray, Digital DPE, (508) 486-5210 27-Jul-1993 1018" <wray at tuxedo.enet.dec.com>
To: jlinn at tuxedo.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: linn at gza.com
Subject: Default creds
John,
Can you go into a bit more detail as to what aspects of the set/lookup
_default_cred GSSAPI proposal were seen as having insufficiently well defined
semantics? Was it just the behavior across a fork (which isn't addressed
anywhere else in the specs, either), or were there other areas too?
John
------- End of Forwarded Message
Would any discussion participants like to comment? I'd like to give
the topic an opportunity for debate on the list.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08273;
27 Jul 93 14:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08266;
27 Jul 93 14:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26069;
27 Jul 93 14:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08252;
27 Jul 93 14:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08184;
27 Jul 93 14:23 EDT
Received: from munin.fnal.gov by CNRI.Reston.VA.US id aa25983;
27 Jul 93 14:23 EDT
Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA05645
(5.65c+/IDA-1.4.4 for ietf at cnri.reston.va.us); Tue, 27 Jul 1993 13:23:42 -0500
Message-Id: <199307271823.AA05645 at munin.fnal.gov>
To: Mark Boolootian <booloo at framsparc.ocf.llnl.gov>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: The Electronic Newsstand
In-Reply-To: Your message of Tue, 27 Jul 93 08:09:28 PDT.
<9307271509.AA03907 at framsparc.ocf.llnl.gov.ocf>
Date: Tue, 27 Jul 93 13:23:42 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Matt Crawford <crawdad at munin.fnal.gov>
> The new company will also be involved in providing advertisers
> access to Internet.
"Imminent death of the net predicted."
- anon.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08596;
27 Jul 93 14:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26549;
27 Jul 93 14:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08583;
27 Jul 93 14:36 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08502;
27 Jul 93 14:32 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-rekhter-cidr-environment-01.txt
Date: Tue, 27 Jul 93 14:32:27 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307271432.aa08502 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Exchanging Routing Information Across Provider
Boundaries in the CIDR Environment
Author(s) : Y. Rekhter, C. Topolcic
Filename : draft-rekhter-cidr-environment-01.txt
Pages : 9
Abstract not provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-rekhter-cidr-environment-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-rekhter-cidr-environment-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-rekhter-cidr-environment-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-cidr-environment-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09642;
27 Jul 93 15:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09635;
27 Jul 93 15:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29122;
27 Jul 93 15:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09614;
27 Jul 93 15:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09550;
27 Jul 93 15:26 EDT
Received: from SYNW03.elettra.trieste.it by CNRI.Reston.VA.US id aa29030;
27 Jul 93 15:26 EDT
Date: Tue, 27 Jul 1993 21:25:33 +0200 (WET-DST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Claudio Allocchio - +39 40 3758523 <ALLOCCHIO at elettra.trieste.it>
To: ietf at CNRI.Reston.VA.US
Message-Id: <930727212533.2ae00299 at elettra.trieste.it>
Subject: newstand...
If we start getting advertisement also via e-mail (remember that the
Internet is an essential tool for everyday's work of millions of researchers
worldwide!) we get somme immmediate nasty effect, and we should carefully
consider to rebuild another Internet where commercials etc. are strictly
banned... i.e. immediate death of the current network service. ...
well, I do not need to say anything else, is it?
regards
Claudio Allocchio - it postmaster
PS: mmmmhhh shall I finally use my lisp compiler to create an AI
anti-commercials filter?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10334;
27 Jul 93 16:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10327;
27 Jul 93 16:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00783;
27 Jul 93 16:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10307;
27 Jul 93 16:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10146;
27 Jul 93 16:10 EDT
Received: from [149.17.8.10] by CNRI.Reston.VA.US id aa00631;
27 Jul 93 16:10 EDT
Received: from angel.qdeck.com by rockall.qdeck.com (4.1/SMI-4.1)
id AA08904; Tue, 27 Jul 93 13:09:48 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jordan Brown <jbrown at qdeck.com>
To: ALLOCCHIO at elettra.trieste.it, ietf at CNRI.Reston.VA.US
Subject: newstand...
X-Mailer: ScoMail 1.0
Date: Tue, 27 Jul 1993 13:04:54 -0700 (PDT)
Message-Id: <9307271304.aa25047 at angel.qdeck.com>
> If we start getting advertisement also via e-mail (remember that the
> Internet is an essential tool for everyday's work of millions of researchers
> worldwide!) we get some immmediate nasty effect,
It is interesting to note that in postal mail junk-mail companies have the
fundamental advantage that it costs lots of money and takes lots of trouble
to send junk mail.
The costs are different in the Internet, and as they are not usually directly
connected to usage they do not directly impact most users. The effort
required to send large volumes of mail is also small.
Junk e-mail producers might well find themselves buried in return junk mail.
All it takes is one irritated person dropping a sendsys bomb on them...
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10563;
27 Jul 93 16:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10559;
27 Jul 93 16:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01294;
27 Jul 93 16:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10551;
27 Jul 93 16:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10547;
27 Jul 93 16:22 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa01279; 27 Jul 93 16:22 EDT
Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA14498 for IESG at cnri.reston.va.us; Tue, 27 Jul 93 16:22:54 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA06342; Tue, 27 Jul 93 13:21:31 PDT
Message-Id: <9307272021.AA06342 at aland.bbn.com>
To: IETF-Announce. at IETF.CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: IESG <IESG at CNRI.Reston.VA.US>
Cc: ietf-ppp at ucdavis.edu
Subject: re: Last Call: Compressing IPX Headers Over WAN Media (CIPX) to
Proposed Standard
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 27 Jul 93 13:21:30 -0700
X-Orig-Sender: craig at aland.bbn.com
> The IESG has received a request from the Point-to-Point Protocol
> Extensions Working Group to consider <draft-ietf-pppext-cipx-04.txt>
> "Compressing IPX Headers Over WAN Media (CIPX)" for the status of
> Proposed Standard.
Hi:
It isn't clear to me what we're standardizing here.
Presumably NOVELL (owner of IPX) not the IETF gets to say what they'd
like the general IPX header compression algorithm to be, yes?
More generally, this draft looks to me like the document one points to.
Viz: when a new PPP spec or amendment comes out, it would say "IPX headers,
if compressed, are to be compressed according to RFC 1XXX which the
the Compressing IPX Headers RFC.
Please note, I have no complaints about the technical content, merely
trying to puzzle out the notion it should become an IETF standard.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10667;
27 Jul 93 16:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10663;
27 Jul 93 16:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01421;
27 Jul 93 16:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10654;
27 Jul 93 16:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10650;
27 Jul 93 16:26 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa01409; 27 Jul 93 16:26 EDT
Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA15752 for ietf at cnri.reston.va.us; Tue, 27 Jul 93 16:27:26 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA06384; Tue, 27 Jul 93 13:26:03 PDT
Message-Id: <9307272026.AA06384 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Cc: IESG <IESG at CNRI.Reston.VA.US>
Cc: ietf-ppp at ucdavis.edu
Subject: re: Last Call: Compressing IPX Headers Over WAN Media (CIPX) to
Proposed Standard
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 27 Jul 93 13:26:03 -0700
X-Orig-Sender: craig at aland.bbn.com
[Sorry if this is a dupe -- my mailer reported the first version was
not delivered to anyone]
> The IESG has received a request from the Point-to-Point Protocol
> Extensions Working Group to consider <draft-ietf-pppext-cipx-04.txt>
> "Compressing IPX Headers Over WAN Media (CIPX)" for the status of
> Proposed Standard.
Hi:
It isn't clear to me what we're standardizing here.
Presumably NOVELL (owner of IPX) not the IETF gets to say what they'd
like the general IPX header compression algorithm to be, yes?
More generally, this draft looks to me like the document one points to.
Viz: when a new PPP spec or amendment comes out, it would say "IPX headers,
if compressed, are to be compressed according to RFC 1XXX which the
the Compressing IPX Headers RFC.
Please note, I have no complaints about the technical content, merely
trying to puzzle out the notion it should become an IETF standard.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11125;
27 Jul 93 16:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11118;
27 Jul 93 16:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02191;
27 Jul 93 16:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11101;
27 Jul 93 16:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11037;
27 Jul 93 16:42 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa02026; 27 Jul 93 16:42 EDT
Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA19497 for ietf at cnri.reston.va.us; Tue, 27 Jul 93 16:42:15 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA06484; Tue, 27 Jul 93 13:40:53 PDT
Message-Id: <9307272040.AA06484 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: Reminder: SIGCOMM '93 Registration
Reply-To: Craig Partridge <craig at aland.bbn.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 27 Jul 93 13:40:52 -0700
X-Orig-Sender: craig at aland.bbn.com
Hi folks:
A cordial reminder that the advance registration deadline for SIGCOMM '93
is August 10th. The advanced program is below.
Speaking personally (and yes I'm biased, I'm publicity chair, but anyway)
I think this should be a really good SIGCOMM. Several of the tutorials look
very good (for example, if you've never heard Paul Green talk on
optical networks, you should), and some of the papers are already the subject
of a lot of advance interest (like the Self-Similar paper that shows that
the burstiness of IP traffic is fractal -- it doesn't go away as traffic
increases).
Hope to see you there!
Craig
***************************************************************************
ADVANCE PROGRAM FOR ACM SIGCOMM '93
September 13-17th, San Francisco, California, USA
**************************************************************************
**************************************************************************
CONFERENCE LOCATION
The SIGCOMM '93 Conference will be held at the Westin St. Francis Hotel
in downtown San Francisco, California. The hotel is within walking
distance of San Francisco's Chinatown and an easy cable car ride
away from Ghiradelli Square and Fisherman's Wharf. Napa and Sonoma
Valleys, the heart of California wine country, are an hour's drive
away.
Weather: San Francisco in September is typically very pleasant. Sunny
and warm (about 70F) during the day, and cool (about 50F) in the
evenings. Note that the evening fog often makes it feel a bit
colder and we recommend you bring a jacket.
Transportation: The hotel is about 20 minutes away from San Francisco
International Airport. A taxi ride from the airport typically costs
about $25. Also, the SFO Airporter has direct service to the
hotel at 20-minute intervals. The fare is $8 one-way and $14
round-trip.
Rental Cars: HERTZ has been appointed as the car rental supplier for
SIGCOMM '93. Special rates with unlimited mileage have been negotiated
for SIGCOMM attendees and are also available the week prior and the
week after the symposium. To make reservations call HERTZ Meeting Services
at 1-800-654-2240 (In Canada 1-800-263-0600) and identify yourself as
SIGCOMM attendee (Meeting # 2499). Cars can be rented at most Bay-area
airports and also at the Westin St. Francis Hotel.
Social Event: An evening dinner-cruise on the San Francisco Bay is planned
for Wednesday, September 15. The cost of the cruise is included in
the registration fee. Additional tickets may be purchased at a price
of $53 each. The cruise will be held on the Hornblower Dining Yachts's
Empress. Beverages will include premium wine and beer, soft drinks,
fruit juices and mineral water. Dinner will be a Greek Salad, Rice
Pilaf, a choice of carved turkey or pasta, and dessert.
**************************************************************************
**************************************************************************
ADVANCE PROGRAM
Monday, September 13th
1:00-5:00 TUTORIALS
Tutorial T1A: High-Speed Transport Protocols
Krishan Sabnani, AT&T Bell Labs
Tutorial T1B: Interconnecting MANs and LANs to ATM
Mario Gerla, UCLA
------------------------------------------------------------------------------
Tuesday, September 14th
8:00-12:00 TUTORIALS
Tutorial T2A: Wireless Communication Worldwide for Cellular and PCS
Donald L. Schilling, InterDigital Communications Corporation
Tutorial T2B: Trends and Challenges in Broadband Networking
Richard D. Gitlin, AT&T Bell Labs
1:30-5:30 TUTORIALS
Tutorial T3A: All-Optical Networking
Paul E. Green Jr., IBM T.J. Watson Research Center
Tutorial T3B: Metropolitan Area Networks
James F. Mollenauer, Technical Strategy Associates
6:00-8:00 Reception at Westin St. Francis Hotel.
------------------------------------------------------------------------------
Wednesday, September 15th
9:00 - 10:30
Keynote Address: SIGCOMM Award Winner
11:00 - 12:30 REAL TIME COMMUNICATIONS
On Per-Session End-to-End Delay Distribution and the Call Admission
Problem for Real Time Applications with QOS Requirements
David Yates, Jim Kurose, Don Towsley (Univ. of Mass) and
Mike Hluchyj (Motorola/Codex Corp)
Analysis of Burstiness and Jitter in Real Time Communications
Zheng Wang and Jon Crowcroft (University College London)
An Adaptive Congestion Control Scheme for Real Time Packet Video Transport
Hemant Kanakia, Amy Reibman (AT&T Bell Lab) and
Partho P Misra (Univ. of Maryland - CP)
2:00 - 3:30 ROUTING
The Synchronization of Periodic Routing Messages
Sally Floyd and Van Jacobson (Lawrence Berkeley Lab.)
Dynamics of Internet Routing Information
Bilal Chinoy (San Diego Supercomputer Center)
Open Shortest Path First (OSPF) Routing Protocol Simulation
Deepinder Sidhu, Tayang Fu, Shukri Abdallah, Raj Nair
(Univ. of Maryland - BC) and Rob Coltun (Consultant)
4:00 - 5:00 PROTOCOL IMPLEMENTATION ISSUES
Implementation of Network Protocols at the User Level
Chandramohan Thekkath, Edward D. Lazowska, Thu. D. Nguyen
and Evelyn Moy (University of Washington)
Locking Effects in Multiprocessor Implementation of Protocols
Mats Bjorkman (Uppsala University) and
Per Gunningberg (Swedish Institute of Computer Science)
5:30 Busses Leave for Cruise.
6:30 - 9:00 SOCIAL EVENT
Cruise in San Francisco Bay.
------------------------------------------------------------------------------
Thursday, September 16th
9:00 - 10:30 MULTICAST
Core Based Trees
Tony Ballardie (University College London), Paul Francis (Bellcore)
and Jon Crowcroft (University College London)
Routing Reserved Bandwidth Multi-Point Connections
Dinesh C. Verma, P. M. Gopal (IBM T.J. Watson Research Center)
The Design of a Reliable Multicast Algorithm
R. Ajello, E. Pagani, G.P. Rossi (Universita' di Milano)
11:00 - 12:30 CONGESTION AND ADMISSION CONTROL, SCHEDULING
Optimizing File Transfer Response Time Using the Loss Load Curve Congestion
Control Mechanism. Carey Williamson (Univ. of Saskatchewan)
An Adaptive Framework for Dynamic Access to Bandwidth at High Speed.
Kerry W. Fendick and Manoel A. Rodrigues (AT&T Bell Laboratories)
Warp Control: A Dynamically Stable Congestion Protocol and its Analysis.
Kihong Park (Boston University)
2:00 - 3:30 PROTOCOL DESCRIPTION
Control Handling in Real-Time Communication Protocols.
Atsushi Shionozaki and Mario Tokoro (Keio University)
Structural Complexity and Execution Efficiency of Distributed Application
Protocols. K. Ravindran and X. T. Lin (Kansas State University)
A Data Labelling Technique for High-Performance Protocol Processing
and its Consequences. David C. Feldmeier (Bellcore)
4:00 - 5:00 TRAFFIC CHARACTERISTICS
On the Self-Similar Nature of Ethernet Traffic
Will E. Leland (Bellcore), Murad S. Taqqu (Boston University),
Walter Willinger and Daniel V. Wilson (Bellcore)
Application of Sampling Methodologies to Network Traffic Characterization
George Polyzos, K. C. Claffy and H. W. Braun
(UC, San Diego)
------------------------------------------------------------------------------
Friday, September 17th
9:00 - 10:30 SCHEDULING AND MANAGEMENT
ATM Scheduling with Queueing Delay Predictions
Daniel B. Schwartz (GTE Laboratories)
HAP: A New Model for Packet Arrivals with Implications for Broadband
Network Control. Ying Dar Lin, Tzu Chieh Tsai and Mario Gerla (UCLA)
Management of Virtual Private Networks for Integrated Broadband Communication
Juergen M. Schneider (IBM European Networking Center),
Thomas Preuss (Technische Universitaet Cottbus) and
Peter S. Nielsen (L. M. Ericsson A/S)
11:00 - 12:30 NETWORKING ISSUES
A Case for Caching File Objects Inside Internetworks
Peter B. Danzig (University of Southern California), Richard S. Hall
and Michael F. Schwartz (University of Colorado, Boulder)
Linear Recursive Networks and Their Applications in Topological Design and
Data Routing. Hsu Wen Jing, A. Das (Nanyang Technological Univ.,
Singapore), and M.J. Chung (Michigan State Univ.)
The Importance of Non-Data Touching Processing Overheads in TCP/IP.
Jonathon Kay and Joseph Pasquale (UC, San Diego)
2:00 - 3:30 PRACTICAL PROTOCOLS
A Distributed Queueing Random Access Protocol for a Broadcast Channel.
Graham Campbell and Wenxin Xu (Illinois Institute of Technology)
Fault Detection in an Ethernet Network Using Anomaly Signature Matching
Frank Feather (Hewlett-Packard Company), Dan Siewiorek and
Roy Maxion (Carnegie Mellon University)
End-to-End Packet Delay and Loss Behavior in the Internet
Jean - Chrysostome Bolot (INRIA)
**************************************************************************
**************************************************************************
TUTORIAL DESCRIPTIONS
Tutorial T1A: High-Speed Transport Protocols. Instructor: Krishan Sabnani,
AT&T Bell Laboratories (Monday, Sept. 13th, 1:00-5:00)
Advances in data transmission and switching over the last
decade promise deployment of communication systems with raw
bandwidth and switching speeds that are orders of magnitude
higher than the current systems. Optical fibers, for
example, allow transmission of tens of gigabits/sec over
several kilometers without repeaters and switch fabrics that
can switch bit-streams of more than hundreds of megabits/sec
have already been prototyped. To realize the fruits of
these advances, transport protocols capable of delivering
high end-to-end bandwidth to their users are needed.
Various approaches for doing this have been proposed:
(1) design of lightweight transport protocols such as NETBLT,
SNR, and VMTP; (2) VLSI implementations of transport
protocols such as PROVE and the Protocol Engine. Some
high-speed versions of standard protocols such as TCP have
also been developed. Many important advances in this area
will be discussed. A special effort will be made to
describe the underlying principles behind these approaches.
In addition, the adaptation layer protocols being proposed
for the ATM/BISDN networks will also be presented.
Biography: Krishan Sabnani is a researcher in the Distributed Systems
Research Department of AT&T Bell Laboratories. His major area of interest
is communication protocols. Krishan received the Leonard G. Abraham
Award from the IEEE Communications Society in 1991. He was awarded
the Bell Laboratories Distinguished Technical Staff Award in 1990.
He is also a fellow of the IEEE, and an editor for the IEEE/ACM
Transactions on Networking. He has been an editor of the IEEE
Transactions on Communications and of the IEEE Transactions on
Computers. He has served as a guest editor for the IEEE Journal
on Selected Areas in Communications (JSAC) and the Computer
Networks Journal. He also serves on the editorial boards
of Journal of Systems Integration and Journal of High
Speed Networks.
---------------------------------------------------------------
Tutorial T1B: Interconnecting MANs and LANs to ATM. Instructor: Mario Gerla,
Computer Science Department, UCLA. (Monday, Sept. 13, 1:00-5:00).
The need for higher data rates in local and metropolitan areas has
recently led to the development of several network products in the
100 MBPS speed range ( eg FDDI, DQDB etc). Following the introduction
of a nationwide ATM network, it will be natural to interconnect
these LANs and MANs to ATM, thus extending their services to
large geographical areas. One of the main challenges of the
LAN/MAN/ATM interconnect is the connectionless traffic support in
ATM. In fact, LANs and MANs are virtually all connectionless,
while ATM is connection oriented and requires bandwidth allocation
prior to connection setup. In this seminar, we will examine and
compare various alternatives for ATM connectionless service support,
including: dedicated VPs (Virtual Paths); on-the-fly burst
transmissions; fast reservations; and connectionless servers.
We will also discuss the problem of extending LAN and MAN multicast
services within ATM. Finally, we will consider the ATM LAN
solution for local and campus area coverage, and examine the
problem of interconnecting the ATM LAN to the ATM WAN.
Biography: Dr. Gerla was born in Milan, Italy. He received a
graduate degree in engineering from the Politecnico di Milano, in
1966, and the M.S. and Ph.D. degrees in engineering from UCLA in 1970
and 1973, respectively. He joined the faculty of the UCLA Computer
Science Department in 1977. His research interests cover the
performance evaluation, design and control of distributed computer
communication systems and high speed computer networks (ATM and
Optical Networks).
---------------------------------------------------------------
Tutorial T2A: Wireless Communication Worldwide for Cellular and PCS.
Instructor: Donald L. Schilling, InterDigital Communication Corporation
(Tuesday, Sept. 14th, 8:00-12:00)
This is the decade of wireless telecommunications. During the 1990s people
will demand, in increasing numbers, the ability to communicate
with a high degree of mobility, high quality voice, data at ISDN rates
and multimedia information such as video. Indeed, consumers demand
wired line quality with wireless convenience. The user of a cellular
or PCS system wants to use one phone for all of these intended needs.
Thus, a single portable phone should be able to operate in a residence
as a cordless phone, in a vehicle using a cellular system and in an
office using a WPBX. This tutorial discusses the two primary
technologies for wireless communications: TDMA and CDMA. Topics include:
principles of operation of TDMA and CDMA; channel
characterization-multipath fading, theory and experimental results;
as well as applications and comparison of TDMA and CDMA for cellular
and PCS.
Biography: Donald L. Schilling is Executive President of InterDigital
Communications Corporation where he directs programs leading to
the production and sale of Wireless TDMA and B-CDMA Communication's
products. Dr. Schilling retired in May 1992 as the Herbert
G. Kayser, Distinguished Professor of Electrical Engineering at
the City College of the City University of New York where he
had been a Professor since 1969. Dr. Schilling is an
internationally-known expert in the field of Communications Systems.
He has made many notable contributions in Meteor-Burst Communications
Systems, Spread Spectrum Communication Systems, FM and Phase Locked
Systems and HF systems. His design of a voice digitizer, called
an adaptive delta modulator, is used on the Space Shuttle. Dr.
Schilling was President of IEEE Communications Society from
1980-1981, and a member of the Board of Directors of the IEEE
from 1982-1983. He was Editor of the IEEE Transactions on
Communications for 1968-1978. He is a Fellow of the IEEE and a
member of Sigma Xi. He has co-authored eight textbooks and more than
140 papers in Telecommunications and Electronics.
---------------------------------------------------------------
Tutorial T2B: Trends and Challenges in Broadband Networking.
Instructor: Richard Gitlin, AT&T Bell Labs (Tuesday, Sept. 14th,
8:00-12:00)
This tutorial will present an overview of research in Broadband Networking
(B-ISDN) based on the Asynchronous Transfer Mode (ATM). ATM is the leading
candidate to provide a technological discontinuity that enables integrated
broadband telecommunication services (e.g., multimedia), high-speed
computer networking and scalable local, metropolitan, and wide area
networks. Specific topics that will be addressed are:
o The technological discontinuities between narrowband and broadband
networking;
o Challenges and barriers to a broadband network;
o Selected research topics (including the LuckyNet broadband testbed).
Biography: Richard D. Gitlin received the B.E.E. degree (cum laude) from
the City College of New York, N.Y., in 1964 and the M.S. and D.Eng.Sc.
degrees from Columbia University, New York, N.Y., in 1965 and 1969,
respectively. Since 1969, he has been with AT&T Bell Laboratories,
Holmdel, N.J. In November, 1992 he was appointed Director of the
Communications Systems Research Laboratory. He is now responsible for
research in broadband networking, wireless networks, and access
technologies. Dr. Gitlin is the author of more than 50 technical
papers, numerous conference papers, and he holds 25 patents in the
areas of data communications, digital signal processing, and broadband
networking. He is a co-author of the text, Data Communication Principles
(Plenum Press, 1992). He is a member of Sigma Xi, and in 1985 he was
elected a Fellow of the IEEE for his contributions to data communications
technology. In 1987 he was named an AT&T Bell Laboratories Fellow.
---------------------------------------------------------------
Tutorial T3A: All-Optical Networking. Instructor: P. E. Green, Jr.,
IBM TJ Watson Research Center. (Tuesday, Sept. 14th, 1:30-5:30).
This short course will focus on recent developments in
networks that exploit the multiprotocol and high bandwidth
possibilities of clear end-to-end optical fiber paths by sending
different sessions or connections at different wavelengths of light.
In the first hour, the motivation and overall principles of such
networks are reviewed. In the next, the appropriate fiber optic
technology is covered, focussing on those components that are special
to networking. In the third hour, various architectural topics are
covered, (including link budgets, topologies and protocols), and in
the final hour the status and prospects for real operational
all-optical networks of various types are presented.
Biography: Paul E. Green, Jr. is Manager of Advanced Optical
Networking Member at IBM Research in Hawthorne, NY. After some years
at M.I.T. Lincoln Laboratory, where he made pioneering contributions
to spread spectrum, adaptive receivers, radar astronomy and seismic
data processing, he joined IBM, where he has held a variety of
research and Corporate Technical Staff positions. His technical
interests have centered on computer network architecture, and he has
received several IBM Outstanding Innovation Awards for his role in
formulating and promoting Advanced Peer-to-Peer Networking, now the
basis for further evolution of IBM's System Network Architecture. He
is a member of the National Academy of Engineering, in 1983 was named
Distinguished Engineering Alumnus by North Carolina State University,
and received the IEEE's Simon Ramo Medal in 1991. He is the author of
many technical papers, has edited several books on computer
communications, and is the author of the textbook: Fiber Optic
Networks, (Prentice Hall, 1993), on which this course is based.
Currently he is President of the IEEE Communication Society.
---------------------------------------------------------------
Tutorial T3B: Metropolitan Area Networks. Instructor: James F. Mollenauer,
Technical Strategy Associates. (Tuesday, Sept. 14th, 1:30-5:30).
This tutorial will cover the applications, standards aspects, and
technology of metropolitan area networks and their relationship
to ATM technology. The need for segmented transmission to
support data, voice, and video services led early on to the
adoption of an ATM or cell-based transmission strategy. This
provides a close relationship to ATM as it has emerged as a
technology of choice for premises networks, replacing the shared
medium LAN. The tutorial will cover private multiservice networks
and public facilities and their support of voice and video in addition
to data. Implementation issues will be addressed, both for the
IEEE 802.6 MAN standard and for the public SMDS service based on it.
Biography: James F. Mollenauer is currently President, Technical
Strategy Associates, of Newton, Massachusetts, providing consultation
in metropolitan and other high-speed networks from both a technical
and product strategy point of view. Since 1982 he has chaired
the standardization group for metropolitan area networks, IEEE
Project 802.6. Prior to his present position Dr. Mollenauer was
Vice President, Advanced Technology at Artel Communications
Corporation, architecting a new line of very-high-performance LAN
bridging and routing products. Previously he spent 17 years at
Bell Laboratories, starting out in nuclear physics research and
moving on to work in real-time computing, time sharing, and
computer-aided design. He has also served at Prime Computer and
its Computervision division in data communication architectures
and planning, and at Codex Corporation, where he undertook
strategic studies in LAN's and metropolitan area networks, and
developed a wireless radio-based LAN. Dr. Mollenauer is the
author of many articles and conference papers on metropolitan and
high speed networks and is currently Chair of the IEEE Local
Computer Networks Conference. He received his bachelor's degree
at Amherst College and his PhD from the University of California
at Berkeley.
**************************************************************************
**************************************************************************
REGISTRATION INFORMATION
Advance registration is available using the form below through September
7th. (E-mail registration available only through August 10th, and must
use a credit card number). On site registration at the Westin St. Francis
Hotel will be available starting Sunday, September 12th from 1PM-5PM, and
every day of the conference starting at 7:30 AM.
Student Registration includes conference proceedings and presentations
but does not include the conference social event.
---------------------------------------------------------------------------
SIGCOMM '93
Registration Form
Please send this form and a check, credit card information,
or money order (no purchase orders) to SIGCOMM '93.
Registrations accepted via postal mail, FAX, or email only.
SIGCOMM '93 Registrar
Hewlett-Packard Laboratories, MS 1U-17
P.O. Box 10490
Palo Alto, CA 94303-0969
FAX: +1 415 813-3706
EMAIL: sigcomm93-registration at hp.com (**note)
Inquiries only: +1 415 857-3295 (voice)
-----------------------------------------------------------
If you are not an ACM or a SIGCOMM member at this time,
you may join now to take full advantage of ACM/SIG Member
or Student(*) rates for SIGCOMM '93:
ACM Associate Member Dues __ $79 US
Add SIGCOMM to ACM Membership __ $22 US
ACM Student Dues __ $24 US
Add SIGCOMM to ACM Student Membership __ $15 US
SIGCOMM Membership only (non-ACM) __ $50 US
Total New Membership Fees $_____ US
-----------------------------------------------------------
Tutorials (check the box for each tutorial attending)
Note: You may select at most one tutorial from each
session time (MAX 3).
___
High-Speed Transport Protocols ....................../__/ T1A
(Monday, 1-5)
___
Interconnecting MANs and LANS to ATM . ............../__/ T1B
(Monday, 1-5)
___
Wireless Communication Worldwide ..................../__/ T2A
for Cellular and PCS (Tuesday, 8-12AM)
___
Trends and Challenges in ............................/__/ T2B
Broadband Networking (Tuesday, 8-12AM)
___
All-Optical Networking ............................../__/ T3A
(Tuesday, 1:30-5:30)
___
Metropolitan Area Networks ........................../__/ T3B
(Tuesday, 1:30-5:30)
Enter total number of tutorials at the appropriate rate:
For registrations received (postmarked)
by after
August 10 1993 August 10 1993
# $'s Each # $'s Each
--------------- ---------------
ACM/SIG Member ___ @ $ 99 US ___ @ $125 US
Non-Member ___ @ $119 US ___ @ $145 US
Student* ___ @ $ 50 US ___ @ $ 50 US
Total Tutorial Fee: $_____ US
-----------------------------------------------------------
Conference (select one):
For registrations received (postmarked)
by after
August 10 1993 August 10 1993
ACM/SIG Member ___ $290 US ___ $340 US
Non-Member ___ $355 US ___ $395 US
Student* ___ $100 US ___ $100 US
Conference Fee: $_____ US
-----------------------------------------------------------
Extra Dinner/Cruise Tickets ___ @ $53 US
(September 15)
Total for extra tickets: $_____ US
-----------------------------------------------------------
Total Amount enclosed: $_____ US
-----------------------------------------------------------
Vegetarian Meals: ___ YES / ___ NO
-----------------------------------------------------------
Name: ____________________________________
Affiliation: _____________________________
Address: _________________________________
Phone: ___________________________________
FAX: _____________________________________
Email Address: ___________________________
ACM Member #: ____________________________
(write "new" if joining at this time)
SIGCOMM Member? ____ YES / ___ NO
Credit Card Payment
__ Visa __ Mastercard
Card Holder Name: ________________________
Card Number: _____________________________
Expiration Date: _________________________
Signature: _______________________________
* See the Advance Program section on student fees.
** Email registration is only available through August 10th and must
use credit card payment.
**************************************************************************
**************************************************************************
HOTEL REGISTRATION
The Westin St. Francis
Union Square
335 Powell Street
San Francisco, CA 94102 USA
A special conference rate has been arranged for attendees of
SIGCOMM '93. These rates are applicable from September 10-17, 1993.
When making reservations by telephone, identify yourself as an
attendee of SIGCOMM '93. Hotel reservation deadline: August 10,
1993. Reservations received after August 10, 1993 are subject to
availability and prevailing rates.
The Westin San Francisco will not hold your reservation after 6:00 PM
on the day of arrival without guaranteeing the reservation with a
check or money order in U.S. dollars covering the first night's stay
(including 11% occupancy tax) or a major credit card with expiration
date and authorized signature.
Deposits will be refunded only if cancellation notification is
received at least 24 hours prior to arrival. Check in time is 3:00 PM.
Type of Room Main Building Towers
Single Double Single Double
Standard $120 $120 - -
Medium $135 $135 $155 $155
Deluxe $150 $150 $170 $170
Arrival Date: __________________________________
Departure Date: ________________________________
Name: __________________________________________
Share With: ____________________________________
Address: _______________________________________
_______________________________________
Daytime Telephone: ___________________
Check or Money Order Enclosed in amount:
_ Mastercard _ American Express _ Carte Blanche
_ Visa _ Discover _ Diners Club
Credit Card Holder's Name: _________________
Credit Card No: ____________________________
Expiration Date: ___________________________
Signature: _________________________________
Reservation by fax, dial: +1 774-0292/774-0124
Reservation by phone, dial: +1 415 397-7000
Identify SIGCOMM '93 for conference rates.
**************************************************************************
**************************************************************************
CONFERENCE COMMITTEE
General Chair: Imrich Chlamtac, Univ. Massachusetts
Program Chair: Deepinder Sidhu, Univ. Maryland - BC
Tutorial Chair: Ian F. Akyildiz, Georgia Tech
Local Arrangements Chair: Anujan Varma, Univ. California - Santa Cruz
Treasurer: Lixia Zhang, XEROX PARC
Publicity Chair: Craig Partridge, BBN
Fund Raising Chair: Biswanath Mukherjee, Univ. California - Davis
Registration Chair: Mark Laubach, Hewlett-Packard
INDUSTRIAL SUPPORTERS OF SIGCOMM '93
SIGCOMM '93 would like to thank Digital Equipment Corporation, Hewlett
Packard, International Business Machines Corporation, and XEROX Palo
Alto Research Center for their support of SIGCOMM '93.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11494;
27 Jul 93 17:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11489;
27 Jul 93 17:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03513;
27 Jul 93 17:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11477;
27 Jul 93 17:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11473;
27 Jul 93 17:14 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa03507; 27 Jul 93 17:14 EDT
Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA25050 for IESG at cnri.reston.va.us; Tue, 27 Jul 93 17:14:54 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA06564; Tue, 27 Jul 93 14:13:26 PDT
Message-Id: <9307272113.AA06564 at aland.bbn.com>
To: IESG <IESG at CNRI.Reston.VA.US>
Cc: ietf at CNRI.Reston.VA.US
Cc: tuba at lanl.gov
Subject: re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed
Standard
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 27 Jul 93 14:13:25 -0700
X-Orig-Sender: craig at aland.bbn.com
> The IESG has received a request from the TCP/UDP over CLNP-addressed
> Networks Working Group to consider <draft-ietf-tuba-clnp-03.txt> "Use
> of ISO CLNP in TUBA Environments" for the status of Proposed Standard.
Hi:
I believe that standardizing (or putting into the standards track)
any of the IPtng proposals before we've decided which one we are likely
to pick is to revive the CMOT/SNMP/HEMS competing standards migraine.
Given that the various BOFs on IP criteria are still having trouble
determining what the right IPtng goals are, how can we possibly think of
putting one of the proposals on the standards track?
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11781;
27 Jul 93 17:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11775;
27 Jul 93 17:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04828;
27 Jul 93 17:39 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11765;
27 Jul 93 17:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11761;
27 Jul 93 17:39 EDT
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa04823;
27 Jul 93 17:39 EDT
Received: by inet-gw-1.pa.dec.com; id AA14261; Tue, 27 Jul 93 14:39:53 -0700
Received: by xirtlu.zk3.dec.com; id AA03336; Tue, 27 Jul 1993 17:39:51 -0400
Message-Id: <9307272139.AA03336 at xirtlu.zk3.dec.com>
To: Craig Partridge <craig at aland.bbn.com>
Cc: IESG <IESG at CNRI.Reston.VA.US>, ietf at CNRI.Reston.VA.US, tuba at lanl.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed Standard
In-Reply-To: Your message of "Tue, 27 Jul 93 14:13:25 PDT."
<9307272113.AA06564 at aland.bbn.com>
Date: Tue, 27 Jul 93 17:39:50 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bound at zk3.dec.com
X-Mts: smtp
I agree with Craig. Lets get the new Criteria Draft (or RFC) out based on
IPdecide, verify its objective via the IESG, and then lets look and see
if any IPng can meet the required criteria or what else they need to do.
Otherwise the SNMP/HEMS/CMOT issue will surely re-occur. I feel RFC 1380
was very close so there is a base doc to begin, and the follow up doc last
DEC 92. Prematurity will also enhance the politics and we don't need
this right now during technical basic analysis of a very important
standard for millions of Internet and TCP/IP users in the market place.
/jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12231;
27 Jul 93 18:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12224;
27 Jul 93 18:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06376;
27 Jul 93 18:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12212;
27 Jul 93 18:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12179;
27 Jul 93 18:15 EDT
Received: from netsys1.netsys.com by CNRI.Reston.VA.US id aa06349;
27 Jul 93 18:15 EDT
Received: by netsys1.netsys.com (4.1/NETSYS-1.0) id AA04707; Tue, 27 Jul 93 15:03:27 PDT
Date: Tue, 27 Jul 93 15:03:27 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rob Raisch <raisch at netsys.com>
Message-Id: <9307272203.AA04707 at netsys1.netsys.com>
To: com-priv at psi.com, ietf at CNRI.Reston.VA.US
Subject: Electronic Newsstand and Unsolicited Advertising
There has been real concern voiced over the possibility that the Internet might
be used to send unsolicited e-mail advertising to millions of unwary users.
While this is a genuine concern in any community, electronic or otherwise,
Electronic Newsstand would like to go on the record and state that this
behavior is completely anathema to our goals on the Global Internet.
We believe that the Global Internet is a community in the true sense of the
word and as such, must support a number of important social constructs which
allow its members to interact with each other as proper citizens.
One of the most important of these rules is that information must always
be requested and never force-fed.
We will never be a source of junk-email, and will never allow any of our
customers and/or advertisers to use the Global Internet in this fashion.
Robert L. Raisch -- raisch at enews.com
Chief Operating Officer,
Electronic Newsstand(tm)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00615;
28 Jul 93 2:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00611;
28 Jul 93 2:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01492;
28 Jul 93 2:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00602;
28 Jul 93 2:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00598;
28 Jul 93 2:50 EDT
Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa01482;
28 Jul 93 2:50 EDT
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA05928; Wed, 28 Jul 1993 08:17:23 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
id AA10425; Wed, 28 Jul 1993 08:17:22 +0200
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Brian Carpenter CERN-CN <brian at dxcern.cern.ch>
Message-Id: <9307280617.AA10425 at dxcern.cern.ch>
Subject: Re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed
To: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 28 Jul 1993 08:17:20 +0200 (MET DST)
Cc: IESG at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US, tuba at lanl.gov
In-Reply-To: <9307272113.AA06564 at aland.bbn.com> from "Craig Partridge" at Jul 27, 93 02:13:25 pm
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1453
Folks,
>--------- Text sent by Craig Partridge follows:
>
>
> > The IESG has received a request from the TCP/UDP over CLNP-addressed
> > Networks Working Group to consider <draft-ietf-tuba-clnp-03.txt> "Use
> > of ISO CLNP in TUBA Environments" for the status of Proposed Standard.
>
> Hi:
>
> I believe that standardizing (or putting into the standards track)
> any of the IPtng proposals before we've decided which one we are likely
> to pick is to revive the CMOT/SNMP/HEMS competing standards migraine.
>
> Given that the various BOFs on IP criteria are still having trouble
> determining what the right IPtng goals are, how can we possibly think of
> putting one of the proposals on the standards track?
>
I think there is an element of misunderstanding here. I don't see this
as putting TUBA on the IPng standards track. It is actually saying
"whatever IPng is, people WILL be running TCP and UDP over CLNP, and
this is (part of) how to do it." As a network operator, I want to
see a complete document set for TUBA so that if and when TUBA products
appear, I have something to measure them against. This is quite
independent of which proposal IESG ultimately recommends to the
IETF as IPng.
Regards,
Brian Carpenter CERN, brian at dxcern.cern.ch
voice +41 22 767 4967, fax +41 22 767 7155
| This is a personal opinion, and not an endorsement of |
| PIP, SIP, TP/IX, Nimrod, TUBA or anything. Really. |
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00737;
28 Jul 93 3:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00733;
28 Jul 93 3:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01769;
28 Jul 93 3:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00724;
28 Jul 93 3:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00720;
28 Jul 93 3:05 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa01748; 28 Jul 93 3:05 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA20117; Wed, 28 Jul 93 00:06:28 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA19678; Wed, 28 Jul 93 00:06:22 pdt
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9307280706.AA19678 at hpindda.cup.hp.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed
To: brian at dxcern.cern.ch
Date: Wed, 28 Jul 93 0:06:21 PDT
Cc: craig at aland.bbn.com, IESG at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
In-Reply-To: <9307280617.AA10425 at dxcern.cern.ch>; from "Brian Carpenter CERN-CN" at Jul 28, 93 8:17 am
Mailer: Elm [revision: 64.9]
I agree with Brian. These documents should be moved to standards on their
own merit independent of IPng. The necessary prototypes, demonstrations,
etc, have been fulfilled. If the standards have been completed sooner than
people expected, so much the better. I think that they should be forwarded
as requested.
Eva Kuiper
HP
>
> Folks,
>
> >--------- Text sent by Craig Partridge follows:
> >
> >
> > > The IESG has received a request from the TCP/UDP over CLNP-addressed
> > > Networks Working Group to consider <draft-ietf-tuba-clnp-03.txt> "Use
> > > of ISO CLNP in TUBA Environments" for the status of Proposed Standard.
> >
> > Hi:
> >
> > I believe that standardizing (or putting into the standards track)
> > any of the IPtng proposals before we've decided which one we are likely
> > to pick is to revive the CMOT/SNMP/HEMS competing standards migraine.
> >
> > Given that the various BOFs on IP criteria are still having trouble
> > determining what the right IPtng goals are, how can we possibly think of
> > putting one of the proposals on the standards track?
> >
>
> I think there is an element of misunderstanding here. I don't see this
> as putting TUBA on the IPng standards track. It is actually saying
> "whatever IPng is, people WILL be running TCP and UDP over CLNP, and
> this is (part of) how to do it." As a network operator, I want to
> see a complete document set for TUBA so that if and when TUBA products
> appear, I have something to measure them against. This is quite
> independent of which proposal IESG ultimately recommends to the
> IETF as IPng.
>
> Regards,
> Brian Carpenter CERN, brian at dxcern.cern.ch
> voice +41 22 767 4967, fax +41 22 767 7155
>
> | This is a personal opinion, and not an endorsement of |
> | PIP, SIP, TP/IX, Nimrod, TUBA or anything. Really. |
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01029;
28 Jul 93 3:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01022;
28 Jul 93 3:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02789;
28 Jul 93 3:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01010;
28 Jul 93 3:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00981;
28 Jul 93 3:54 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa02749;
28 Jul 93 3:54 EDT
Received: from itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-12)
id <AA03332>; Wed, 28 Jul 1993 00:55:16 -0700
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA01919; Wed, 28 Jul 93 03:55:10 EDT
Date: Wed, 28 Jul 93 03:55:10 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ran Atkinson <atkinson at itd.nrl.navy.mil>
Message-Id: <9307280755.AA01919 at itd.nrl.navy.mil>
To: ietf at isi.edu
Subject: Re: Last Call for TUBA stuff
Brian and Eva,
There is a distinction between a public specification and a public
specification which is on the Internet standards track.
The needs that both of you describe (ability to specify and purchase
products) can be fully met by an informational status RFC or an
experimental status RFC describing how one would do TUBA if doing TUBA
were locally deemed desirable. There is not consensus amongst the
IETF as a whole that any particular IPng proposal should be widely
deployed at this time. Many many protocols have multiple independent
implementations which interoperate and only have informational status
or experimental status RFC specifications. Gopher is a very recent
example of this (and there is more Gopher traffic than CLNP traffic
across the Internet backbone as of the last official statistics).
In practice, putting out _any_ IPng proposal document on the
standards-track prior to IPng selection will be misread by the trade
press (and also by any zealots who like that IPng proposal) as
endorsement of that proposal by the IESG. Such action will also
constitute undue interference in the IPng process by the IESG. Many
folks are not active in the IETF and will misconstrue such an action.
Craig's reasoning is quite sound and his historical examples are quite
relevant.
NONE of the IPng proposals should be put on the standards-track
until an official selection is made by the IETF as a whole. It is
clearly possible to change the status of an RFC ex post facto, so
this is not an onerous burden on any person, proposal, or group.
Ran
atkinson at itd.nrl.navy.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01060;
28 Jul 93 3:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01056;
28 Jul 93 3:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02819;
28 Jul 93 3:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01047;
28 Jul 93 3:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01043;
28 Jul 93 3:59 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa02814;
28 Jul 93 3:59 EDT
Received: from macii-morgan.Stanford.EDU by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA07496; Wed, 28 Jul 93 00:59:55 -0700
Date: Wed, 28 Jul 93 01:00:43 -0800
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: RL Bob Morgan <morgan at networking.stanford.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed
Cc: IESG at CNRI.Reston.VA.US
Message-Id: <Mailstrom.1.03.32827.-11267.morgan at networking.stanford.edu>
In-Reply-To: Your message <9307280617.AA10425 at dxcern.cern.ch> of Wed, 28 Jul 1993 08:17:20 +0200 (MET DST)
Content-Type: TEXT/plain; charset=US-ASCII
Brian Carpenter writes:
> "whatever IPng is, people WILL be running TCP and UDP
> over CLNP, and this is (part of) how to do it."
Whatever IPng is, people will be doing lots of things on their nets (eg
AppleTalk, SNA) that aren't covered by the IETF standards process.
> As a network operator, I want to
> see a complete document set for TUBA
But why do these documents have to be Internet Standards?
Either TUBA is an IPng candidate, in which case its standardization should wait
until a decision is made, or it isn't, in which case the IPng decision is made
easier. I can't see how it can be both. I agree with Craig P on this.
- RL "Bob" Morgan
Networking Systems
Stanford
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01247;
28 Jul 93 4:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01240;
28 Jul 93 4:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03334;
28 Jul 93 4:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01227;
28 Jul 93 4:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01205;
28 Jul 93 4:26 EDT
Received: from SYNW03.elettra.trieste.it by CNRI.Reston.VA.US id aa03317;
28 Jul 93 4:26 EDT
Date: Wed, 28 Jul 1993 10:25:10 +0200 (WET-DST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Claudio Allocchio - +39 40 3758523 <ALLOCCHIO at elettra.trieste.it>
To: ietf at CNRI.Reston.VA.US
Message-Id: <930728102510.2ae00228 at elettra.trieste.it>
I agree with Brian. These documents should be moved to standards on their
own merit independent of IPng. The necessary prototypes, demonstrations,
etc, have been fulfilled. If the standards have been completed sooner than
people expected, so much the better. I think that they should be forwarded
as requested.
Eva Kuiper
HP
---------------------end of quoted message
I also agree with Brian and Eva. If a protocol proves to be mature (and in my
personal opinion based on daily pruduction using CLNP/CLNS) it should be sent
to Standard Track. And, finally, the IESG/IAB should consider for selection
ONLY those IPng protocols which already have the Standard Status, i.e. have
fulfiled a serious set of requirements, tests and indipendent implementations.
If other IPng protocol implementations/specifications are late, well...
hurry up to catch the train...
Regards
Claudio Allocchio
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02476;
28 Jul 93 8:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02472;
28 Jul 93 8:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07798;
28 Jul 93 8:15 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02463;
28 Jul 93 8:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02459;
28 Jul 93 8:15 EDT
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa07793;
28 Jul 93 8:15 EDT
Received: by inet-gw-1.pa.dec.com; id AA22876; Wed, 28 Jul 93 05:15:42 -0700
Received: by xirtlu.zk3.dec.com; id AA18680; Wed, 28 Jul 1993 08:15:40 -0400
Message-Id: <9307281215.AA18680 at xirtlu.zk3.dec.com>
To: IESG at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US, tuba at lanl.gov,
bound at zk3.dec.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed Std
In-Reply-To: Your message of "Tue, 27 Jul 93 17:39:50 EDT."
<9307272139.AA03336 at xirtlu.zk3.dec.com>
Date: Wed, 28 Jul 93 08:15:40 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bound at zk3.dec.com
X-Mts: smtp
Yes it makes sense that each Technical effort provide docs on its own
merit, but one of the most important pieces to IPng for any operator,
vendor, or end user is the Transition Strategy. It did not seem that we
had consensus in the IETF IPngs on what document all IPngs should
respond to for those tracking all IPngs as to what the Transition
Strategy is for any new network layer proposed. This also relates back
to engineering costs. If a Transition strategy is costly it may not be
implemented by the market place.
The reason for not moving to Proposed Standard is the Drafts work just
fine for any argument presented thus far and force authors to advance
and evolve them every six months. Until a Transition proposal for any
IPng is completed it is probable that other proposals for that IPng will
change. What this states is that without a Transition Strategy from any
IPng moving to a Proposed Standard is awkward and premature. I see no
problem with reading Drafts.
I guess where I am going with this is that with NO TRANSITION STRATEGY
then NO PROPOSED standard, if I had an IESG vote. This also avoids the
many negative things that can happen without a formal transition
strategy for any IPng.
/jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05089;
28 Jul 93 9:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05085;
28 Jul 93 9:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12342;
28 Jul 93 9:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05075;
28 Jul 93 9:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05071;
28 Jul 93 9:43 EDT
Received: from gateway.mitre.org by CNRI.Reston.VA.US id aa12332;
28 Jul 93 9:43 EDT
Return-Path: <barns at cove.mitre.org>
Received: from cove.mitre.org by gateway.mitre.org (5.61/SMI-2.2)
id AA00844; Wed, 28 Jul 93 09:44:27 -0400
Received: by cove.mitre.org (4.1/SMI-4.1)
id AA04298; Wed, 28 Jul 93 09:44:00 EDT
Message-Id: <9307281344.AA04298 at cove.mitre.org>
To: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
Cc: barns at cove.mitre.org
Subject: Re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed Standard
In-Reply-To: John Stewart's message of "Fri, 23 Jul 93 14:35:14 EDT."
<9307231435.aa10542 at IETF.CNRI.Reston.VA.US>
Date: Wed, 28 Jul 93 09:43:58 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: barns at cove.mitre.org
Regarding the comments on suitability of this item for the standards track:
I think the IAB/IESG/IETF created a predicament for themselves by putting
IDPR on the standards track. Unless some technicality exists of which
I'm unaware, there is a good argument that the IDPR decision is *the*
relevant precedent. I've appended the IAB statement on that occasion to
this message for the sake of any who care, but don't have it handy.
At this moment, if the IESG were to decide not to put this TUBA document
on the standards track because of the objections advanced in the emails
I've seen, I would not understand why IDPR is on the standards track.
I'm not taking a position in this comment on the merits of either TUBA
or IDPR either technically or as candidates for standardization.
/Bill Barns
(speaking as an individual only)
========
From: braden at ISI.EDU (Bob Braden)
Date: Sat, 22 Aug 1992 14:25:25 -0700
Posted-Date: Sat, 22 Aug 1992 14:25:25 -0700
Message-Id: <199208222125.AA15996 at braden.isi.edu>
To: ietf at ISI.EDU
Subject: IAB Protocol Action: IDPR to Proposed Standard
Cc: iab at ISI.EDU, iab-stds at ISI.EDU, iesg at ISI.EDU
The IAB has accepted the IESG recommendation that the InterDomain
Policy Routing (IDPR) Protocol be elevated to Proposed Standard
Status.
IDPR is define in the Internet Drafts:
o <draft-ietf-idpr-architecture-04> "An Architecture for Inter-Domain
Policy Routing", and
o <draft-ietf-idpr-specv1-02> "Inter-Domain Policy
Routing Protocol Specification: Version1"
An overview document is available as Internet Drafts
<draft-ietf-idpr-summary-00> "IDPR as a Proposed Standard".
IDPR is the product of the IDPR Working Group of the IETF.
Rationale:
In May 1989, Dave Clark published RFC-1102, "Policy Routing in
Internet Protocols". After three years of further development
within IETF, many of these ideas have been realized in IDPR.
Unfortunately, it is not clear that there is even "rough consensus"
on all particulars of this IDPR specification. This divergence of
expert opinion was reflected in the lengthy technical debate
following the Last Call and in many private comments. However, we
believe that the general policy routing provided by IDPR (following
Clark's model) may be important to the future of the Internet, and
that talking about it is not enough; experience is needed. The
Working Group has stated, and the IESG has agreed, that designating
IDPR a Proposed Standard will foster a process of prototyping and
limited deployment, to allow the Internet technical community can
gather some needed experience with policy routing. To quote from
the IESG summary:
"IDPR can be deployed in an incremental manner and without
conflict with currently deployed routing protocols. ...
This deployment is not in conflict with the
ongoing efforts to select and develop the next generation
routing and addressing architecture and associated protocols."
IDPR has satisfied all formal requirements (ref. RFC-1264) for
entering a new routing protocol into the standards track, so there
are no procedural grounds for deferring its entry.
Standardizing a technical specification is not meant to imply
anything about its applicability, i.e., when and if it is
appropriate to use IDPR. For guidance on the applicability of
IDPR, refer to the forthcoming Router Requirements specification.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05252;
28 Jul 93 9:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05245;
28 Jul 93 9:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12553;
28 Jul 93 9:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05231;
28 Jul 93 9:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05158;
28 Jul 93 9:47 EDT
Received: from birch.ims.disa.mil by CNRI.Reston.VA.US id aa12468;
28 Jul 93 9:46 EDT
Received: from funnel.ims.disa.mil by birch.ims.disa.mil.ims.disa.mil (4.1/RAB-5.0)
id AA09085; Wed, 28 Jul 93 09:48:03 EDT
Received: from CC.IMS.DISA.MIL by funnel.ims.disa.mil (4.1/RB&BK-4.1.5)
id AA26358; Wed, 28 Jul 93 09:47:09 EDT
Received: from ccMail by CC.IMS.DISA.MIL
id AA743878032 Wed, 28 Jul 93 09:47:12 EST
Date: Wed, 28 Jul 93 09:47:12 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Harold C. Folts" <foltsh at cc.ims.disa.mil>
Message-Id: <9306287438.AA743878032 at CC.IMS.DISA.MIL>
To: ietf at CNRI.Reston.VA.US
Subject: Last Call: Use of ISO CLNP in TUBA Environments to Proposed
>The IESG has received a request from the TCP/UDP over CLNP-addressed
>Networks Working Group to consider <draft-ietf-tuba-clnp-03.txt> "Use
>of ISO CLNP in TUBA Environments" for the status of Proposed Standard.
*************************************
I have been following with interest all the chatter going on since the above
announcement.
I have been led to the understand that the SPIRIT of the Internet process was to
accept technically viable, properly qualified proposals as Internet standards
and let the market place take it from there.
TUBA has solidly met these conditions with substantial support.
Political bickering should not muddy the process. THE DISCUSSIONS ARE STARTING
TO SOUND LIKE A STANDARDS COMMITTEE.
Let's get on with the TUBA standards proposal.
Hal
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06911;
28 Jul 93 11:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06907;
28 Jul 93 11:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15452;
28 Jul 93 11:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06896;
28 Jul 93 11:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06892;
28 Jul 93 11:12 EDT
Received: from boa-f.gsfc.nasa.gov by CNRI.Reston.VA.US id aa15445;
28 Jul 93 11:12 EDT
Received: by boa.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3)
id AA01571; Wed, 28 Jul 1993 11:13:00 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dick desJardins <desjardi at boa.gsfc.nasa.gov>
Message-Id: <9307281513.AA01571 at boa.gsfc.nasa.gov>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US, tuba at lanl.gov
Date: Wed, 28 Jul 1993 11:12:59 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1812
Folks,
I have long argued that we need TUBA within GOSIP
quite independent of the need for an IPng. We need an
Internet standard, because GOSIP has to use
international standards, and Internet is the place where
these particular standards are done. If Internet is not going
to fulfill this role, where do we go for such needed standards?
There has been a lot of good pressure from the Internet
community for ISO to do its internetworking standards within
IETF. Here's a *perfect* example of a standard that not only
*should* be done within IETF, it already *has been done*
within the IETF. Now it needs to become a standard within
the Internet, so that GOSIP CLNP internets can run TCP and
FTP and their other Internet applications in a standard way.
So far as the issue as to whether this favors CLNP and TUBA
as the IPng, I have to say that the TUBA group has been
saying over and over that CLNP is already deployed and we
need a standard way to run TCP, UDP and the Internet
applications over it. TUBA believes that the deployment of
CLNP is de facto, and that's a rationale for its selection.
Whether or not it is selected, it *is* deployed, and people need
a *standard* way to run their Internet upper layers over it.
I say again, if Internet is not going to fulfill this role, where
do we go for such needed standards?
Dick desJardins
(My candidate for the appropriate precedent is RFC 1006.
That shows the standard way to run OSI upper layers over
Internet lower layers. TUBA shows how to run the Internet
upper layers over OSI lower layers. Seems the same.
Is there a different type of "Internet standard" that is
available for this? It doesn't want to be "experimental",
because it wants to be part of operational deployed
networks. How does the community want to do this type of
thing?)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07497;
28 Jul 93 11:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07493;
28 Jul 93 11:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17329;
28 Jul 93 11:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07484;
28 Jul 93 11:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07480;
28 Jul 93 11:45 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa17314;
28 Jul 93 11:45 EDT
Received: by ginger.lcs.mit.edu
id AA09443; Wed, 28 Jul 93 11:46:21 -0400
Date: Wed, 28 Jul 93 11:46:21 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9307281546.AA09443 at ginger.lcs.mit.edu>
To: IESG at CNRI.Reston.VA.US, craig at aland.bbn.com
Subject: re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed Standard
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
I believe that standardizing (or putting into the standards track) any of
the IPtng proposals before we've decided which one we are likely to pick
is to revive the CMOT/SNMP/HEMS competing standards migraine.
Craig, I've been musing about this for a day or so.
On the one hand, I kind of agree with you, since it may well cause
factional political warfare. Also (as others have stated) the trade rags
(egged on by partisans of the various schemes, no doubt, a crime for which
said partisans should be boiled in oil, since "what goes around comes around",
and this kind of behaviour will come back to haunt them) will inevitably
misinterpret this as "the IETF has picked X".
It's also true that the standardization rules (RFC1310) say something
to the effect that one of the elements needed to become a standard is that the
standard be useful, and of N competing internetwork layer protocols, surely
N-1 are not useful (in the long run :-).
On the other hand, the rules also say that the thing you need (in
terms of "useful") to get to PS is "to enjoy enough community interest to be
considered valuable". You'd have a hard time saying that any of the major
proposals hadn't reached this point.
There is also the precedent with IDPR and BGP/IDRP, where two
protocols which (in some sense) meet the same function were allowed to proceed
forward to the PS level. I was on the IESG at the time the IDPR issue was
decided, and I recall distinctly that while there was some concern about the
potential conflict, there no procedural grounds to deny it (as noted above),
and it was decided to let it go forward as a specification and discuss the
applicability of it and BGP/IDRP later. It's not a perfect analogy, true,
since IDPR has capabilities BGP/IDRP doesn't, and you can deploy them both at
the same time and get some use out of each of them (ad-hoc 'Unified' :-), but
it's close enough to be disturbing.
It's also not out of place to mention the potential legal liability
for bending your own rules and precedents; potential legal action was
mentioned in at least one instance while I was on the IESG.
In sum, I think we have no choice but to let these protocols advance
along the technical line, while withholding any decisions on applicability.
May I suggest the following two things to limit the fallout:
- Partisans of various schemes should realize that politicing is not the best
way to get their protocol adopted; doing good design, and getting stuff
built and deployed is. The losers in the various CMOT/etc battles may think
it was superior political skills on the other side that lost them, but it
wasn't; it was installed base. Avoiding the politics will minimze bad
feelings, which will make it easier to patch the community back together
behind whichever wins when it's all over. Remember, "what goes around comes
around".
- To deal with the trade rags, the IESG/IAB should immediately, *before* any
of the contendors advance to PS, produce a statment briefly explaining the
IETF process, specifically as it relates to the IPng contendors, and
pointing out explicity that advancing any to PS *does not* indicate that
the IETF has *chosen* that one. The IESG/IAB should distribute this to the
editors of the major trade rags, and warn the editors to beware people
who try and manipulate the press coverage; in fact, that statement should
be distributed as widely as possible. Should any rag run such a story,
the IESG/IAB should *immediately* contact the reporter responsible, and
give them a statement to the contrary (along with a copy of the initial
statement).
There is no magic solution here. If some people don't want to work in
everyone's best long term interest, there's nothing we can do to prevent a
blowup. To do that, *everyone* has to help, and *restrain themselves*. The
end *does not* justify the means.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07629;
28 Jul 93 11:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07625;
28 Jul 93 11:55 EDT
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa17876; 28 Jul 93 11:55 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK)
id AA13673; Wed, 28 Jul 93 11:45:25 -0400
X-Resent-To: ups-mib at CS.UTK.EDU ; Wed, 28 Jul 1993 11:45:24 EDT
Errors-To: owner-ups-mib at CS.UTK.EDU
Received: from seymour4.snmp.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK)
id AA13663; Wed, 28 Jul 93 11:45:22 -0400
Received: by seymour4.snmp.com (5.61++/2.8s-SNMP)
id AA07183; Wed, 28 Jul 93 11:45:08 -0400
Date: Wed, 28 Jul 93 11:45:08 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: case at snmp.com
Message-Id: <9307281545.AA07183 at seymour4.snmp.com>
To: minutes at CNRI.Reston.VA.US, ups-mib at cs.utk.edu
Subject: Amsterdam meeting minutes, UPS MIB Working Group
Cc: mrose-ietf at dbc.mtview.ca.us
Minutes of the Uninterruptible Power Supply MIB Working Group (UPSMIB)
The UPS MIB Working Group met on Monday, July 12, 1993, at the 27th Meeting
of the Internet Engineering Task Force, in Amsterdam, the Netherlands.
The meeting was a small one, with mostly new faces.
A new draft of the result of the strawman effort ongoing since the Columbus
meeting was presented and reviewed by those in attendance. A few errors were
identified during the review. These will be corrected and the results will
be posted to the mailing list and as an Internet Draft to achieve the widest
possible circulation. The meeting was helpful in that it caused the generation
of a new draft, bringing some closure to the strawman effort. This new draft
will serve as the basis for future discussions, coallescing the work to date
into a single document.
It was noted that the group is making progress more rapidly now that the
level of activity on the mailing list has increased. It was also noted that
this is essential, because the amount of time invested to date has exceeded
the chartered time for completion and that the group must complete its work
in the near term.
The next meeting of the IETF is scheduled for November 1-5, Houston, Texas.
Reported by Jeff Case / University of Tennessee
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07729;
28 Jul 93 12:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07722;
28 Jul 93 12:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18171;
28 Jul 93 12:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07698;
28 Jul 93 12:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07671;
28 Jul 93 11:59 EDT
Received: from loki.oar.net by CNRI.Reston.VA.US id aa18021; 28 Jul 93 11:59 EDT
Received: for henryc at oar.net
by loki.oar.net (5.65c+RONSKI/921206.2314) id AA20882; Wed, 28 Jul 1993 11:59:31 -0400
Date: Wed, 28 Jul 1993 11:59:31 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: henryc at oar.net
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Message-Id: <199307281559.AA20882 at loki.oar.net>
To: desjardi at boa.gsfc.nasa.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at CNRI.Reston.VA.US, tuba at lanl.gov
>So far as the issue as to whether this favors CLNP and TUBA
>as the IPng, I have to say that the TUBA group has been
>saying over and over that CLNP is already deployed and we
>need a standard way to run TCP, UDP and the Internet
>applications over it.
I disagree with the first part of that statement. Just where is
CLNP deployed *and* widely used? Does it run on 100,000 hosts yet?
Does ANS switch CLNP natively yet? How well does CLNP/TUBA routing
work now and how will it scale? Is the TUBA software incorporated
in standard releases of router and host software yet?
As a NSP, I'm very concerned (read scared s**tless) that some new
IPng protocol (let alone IPv4) will destroy my network.
henry
PS: BTW, if you're doing PIP, SIP, or TP/IX, I'll ask you the same
questions...
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07951;
28 Jul 93 12:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07947;
28 Jul 93 12:18 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa18826;
28 Jul 93 12:18 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (5.65/%I%)
id AA00959; Wed, 28 Jul 93 10:01:47 -0600
Received: by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA18019; Wed, 28 Jul 93 10:01:32 MDT
Return-Path: <foltsh at CC.ims.disa.mil>
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA18013; Wed, 28 Jul 93 10:01:31 MDT
Received: from birch.ims.disa.mil by mailhost.lanl.gov (5.65/%I%)
id AA18360; Wed, 28 Jul 93 06:29:39 -0600
Received: from funnel.ims.disa.mil by birch.ims.disa.mil.ims.disa.mil (4.1/RAB-5.0)
id AA08687; Wed, 28 Jul 93 08:29:50 EDT
Received: from CC.IMS.DISA.MIL by funnel.ims.disa.mil (4.1/RB&BK-4.1.5)
id AA25525; Wed, 28 Jul 93 08:29:04 EDT
Received: from ccMail by CC.IMS.DISA.MIL
id AA743873327 Wed, 28 Jul 93 08:28:47 EST
Date: Wed, 28 Jul 93 08:28:47 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Harold C. Folts" <foltsh at cc.ims.disa.mil>
Message-Id: <9306287438.AA743873327 at CC.IMS.DISA.MIL>
To: IETF-Announce. at cc.ims.disa.mil,
IESG Secretary <@CNRI.Reston.VA.US,@p.lanl.gov:iesg-secretary at CNRI.Reston.VA.US>,
tuba at lanl.gov
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: IESG at CNRI.Reston.VA.US
Subject: Last Call: Use of ISO CLNP in TUBA Environments to Proposed
>The IESG has received a request from the TCP/UDP over CLNP-addressed
>Networks Working Group to consider <draft-ietf-tuba-clnp-03.txt> "Use
>of ISO CLNP in TUBA Environments" for the status of Proposed Standard.
*************************************
I have been following with interest all the chatter going on since the above
announcement.
I have been led to the understand that the SPIRIT of the Internet process was to
accept technically viable, properly qualified proposals as Internet standards
and let the market place take it from there.
TUBA has solidly met these conditions with substantial support.
Political bickering should not muddy the process. THE DISCUSSIONS ARE STARTING
TO SOUND LIKE A STANDARDS COMMITTEE.
Let's get on with the TUBA standards proposal.
Hal
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08219;
28 Jul 93 12:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08212;
28 Jul 93 12:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19447;
28 Jul 93 12:39 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08198;
28 Jul 93 12:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08142;
28 Jul 93 12:37 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa19335; 28 Jul 93 12:37 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA04442; Wed, 28 Jul 93 09:37:44 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA27967; Wed, 28 Jul 93 09:37:39 pdt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9307281637.AA27967 at hpindda.cup.hp.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: henryc at oar.net
Date: Wed, 28 Jul 93 9:37:36 PDT
Cc: desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US, tuba at lanl.gov
In-Reply-To: <199307281559.AA20882 at loki.oar.net>; from "henryc at oar.net" at Jul 28, 93 11:59 am
Mailer: Elm [revision: 64.9]
>
> >So far as the issue as to whether this favors CLNP and TUBA
> >as the IPng, I have to say that the TUBA group has been
> >saying over and over that CLNP is already deployed and we
> >need a standard way to run TCP, UDP and the Internet
> >applications over it.
>
> I disagree with the first part of that statement. Just where is
> CLNP deployed *and* widely used? Does it run on 100,000 hosts yet?
> Does ANS switch CLNP natively yet? How well does CLNP/TUBA routing
> work now and how will it scale? Is the TUBA software incorporated
> in standard releases of router and host software yet?
CLNP code is available from every major router vendor as a product
today. CLNP is available on almost every host as well as a product.
CLNP is running on at least 20 regional networks. It was running
already on NSFnet. ANS is supposed to have transitioned this capability
when the network transitioned. TUBA does not require any code changes
to existing CLNP. Some the routers have already undergone CLNP
conformance testing for the US GOSIP testing program and are in the
GOSIP Product Register. There are dozens of conformance tested CLNP
hosts available. This is a very stable protocol that has been around
for years now. I don't think that your fears are really warranted as
far as robustness is concerned. As far as finding 100,000 hosts,
the hosts are still looking for more networks they can run on :-)
As far as standard product releases of TUBA being needed to advance
to proposed standard, this would be putting the cart before the horse.
Feasibility studies through prototyping have already been done. There
are TUBA systems running all over the Internet today using the
existing CLNP networks to communicate over. This phase, which is required
before advancing to proposed standard, has been completed very
successfully.
Eva Kuiper
HP
>
> As a NSP, I'm very concerned (read scared s**tless) that some new
> IPng protocol (let alone IPv4) will destroy my network.
>
> henry
>
> PS: BTW, if you're doing PIP, SIP, or TP/IX, I'll ask you the same
> questions...
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08412;
28 Jul 93 12:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08408;
28 Jul 93 12:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19965;
28 Jul 93 12:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08399;
28 Jul 93 12:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08395;
28 Jul 93 12:49 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa19960;
28 Jul 93 12:49 EDT
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA14787>; Wed, 28 Jul 1993 09:47:15 -0700
Date: Wed, 28 Jul 1993 09:47:19 -0700
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: braden at isi.edu
Posted-Date: Wed, 28 Jul 1993 09:47:19 -0700
Message-Id: <199307281647.AA22665 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA22665>; Wed, 28 Jul 1993 09:47:19 -0700
To: IESG at isi.edu, ietf at CNRI.Reston.VA.US, tuba at lanl.gov, bound at zk3.dec.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed Std
I know this won't make satisfy anybody, but I would like to observe that
the dilemma facing the community is exactly the reason for the new status of
Prototype, introduced into the draft revision of RFC-1310. A Prototype
specification is NOT yet on the standards track, yet it is more than an
Experiment. As a Prototype, it is presumably stable enough for --
you guessed it -- prototype deployment to gain experience.
Bob Braden
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08628;
28 Jul 93 13:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08621;
28 Jul 93 13:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20497;
28 Jul 93 13:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08607;
28 Jul 93 13:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08544;
28 Jul 93 12:59 EDT
Received: from lager.cisco.com by CNRI.Reston.VA.US id aa20368;
28 Jul 93 12:59 EDT
Received: by lager.cisco.com id AA14105
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Wed, 28 Jul 1993 10:00:07 -0700
Date: Wed, 28 Jul 1993 10:00:07 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tony Li <tli at cisco.com>
Message-Id: <199307281700.AA14105 at lager.cisco.com>
To: "Harold C. Folts" <foltsh at cc.ims.disa.mil>
Cc: ietf at CNRI.Reston.VA.US
Subject: Last Call: Use of ISO CLNP in TUBA Environments to Proposed
Political bickering should not muddy the process. THE DISCUSSIONS
ARE STARTING TO SOUND LIKE A STANDARDS COMMITTEE.
I guess you didn't make it to Amsterdam either, eh?
;-(
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08860;
28 Jul 93 13:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08853;
28 Jul 93 13:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20720;
28 Jul 93 13:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08813;
28 Jul 93 13:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08727;
28 Jul 93 13:07 EDT
Received: from bridge2.NSD.3Com.COM by CNRI.Reston.VA.US id aa20606;
28 Jul 93 13:07 EDT
Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA12625
(5.65c/IDA-1.4.4nsd for <ietf at cnri.reston.va.us>); Wed, 28 Jul 1993 10:08:00 -0700
Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA08634
(5.65c/IDA-1.4.4-910725); Wed, 28 Jul 1993 10:07:58 -0700
Message-Id: <199307281707.AA08634 at remmel.NSD.3Com.COM>
To: bound at zk3.dec.com
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA Environments to Proposed Std
In-Reply-To: Your message of "Wed, 28 Jul 93 08:15:40 EDT."
<9307281215.AA18680 at xirtlu.zk3.dec.com>
Date: Wed, 28 Jul 93 10:07:57 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: tracym at nsd.3com.com
> The reason for not moving to Proposed Standard is the Drafts work just
> fine for any argument presented thus far and force authors to advance
> and evolve them every six months. Until a Transition proposal for any
Drafts may not be used as documents with which conformance can be
claimed.
TUBA is a technique which some internetworking customers will use in
networks that have no IP traffic, allowing them to telnet to a router,
for instance, without having to configure IP.
This has nothing to do with IPng. Since tcp, udp, and the various
applications that use them are within the province of the IETF, TUBA
is most certainly a suitable candidate for IETF standardization. It
probably shouldn't even be thought of as a new protocol, but more in
line with encapsulation standards.
> I guess where I am going with this is that with NO TRANSITION STRATEGY
> then NO PROPOSED standard, if I had an IESG vote. This also avoids the
> many negative things that can happen without a formal transition
> strategy for any IPng.
It's quite clear that a candidate for IPng requires much more than
simply a standardized internetwork protocol, including, but not
limited to, routing protocols, address assignment mechanisms, and the
all-important transition strategy.
There is a clear need for a proposed standard for TUBA, completely
independent of IPng.
Regards,
Tracy
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09134;
28 Jul 93 13:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21158;
28 Jul 93 13:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09115;
28 Jul 93 13:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08955;
28 Jul 93 13:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-bgp-mibv4-02.txt
Date: Wed, 28 Jul 93 13:18:18 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307281318.aa08955 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : Definitions of Managed Objects for the Border Gateway
Protocol (Version 4)
Author(s) : S. Willis, J. Burruss, J. Chu
Filename : draft-ietf-bgp-mibv4-02.txt
Pages : 17
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Border Gateway Protocol.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-mibv4-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-bgp-mibv4-02.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-bgp-mibv4-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-mibv4-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09347;
28 Jul 93 13:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09340;
28 Jul 93 13:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21685;
28 Jul 93 13:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09328;
28 Jul 93 13:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09275;
28 Jul 93 13:34 EDT
Received: from lbl.gov by CNRI.Reston.VA.US id aa21585; 28 Jul 93 13:34 EDT
Received: from [131.243.64.68] (macruss.lbl.gov) by lbl.gov (4.1/1.39)
id AA03050; Wed, 28 Jul 93 10:40:01 PDT
Date: Wed, 28 Jul 93 10:40:01 PDT
Message-Id: <9307281740.AA03050 at lbl.gov>
To: henryc at oar.net, desjardi at boa.gsfc.nasa.gov
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Russ Wright <wright at lbl.gov>
X-Sender: wright at net.lbl.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at CNRI.Reston.VA.US, tuba at lanl.gov
At 11:59 AM 7/28/93 -0400, henryc at oar.net wrote:
>>So far as the issue as to whether this favors CLNP and TUBA
>>as the IPng, I have to say that the TUBA group has been
>>saying over and over that CLNP is already deployed and we
>>need a standard way to run TCP, UDP and the Internet
>>applications over it.
>
>I disagree with the first part of that statement. Just where is
>CLNP deployed *and* widely used? Does it run on 100,000 hosts yet?
>Does ANS switch CLNP natively yet? How well does CLNP/TUBA routing
>work now and how will it scale? Is the TUBA software incorporated
>in standard releases of router and host software yet?
>
Just a quick comment (I'll let someone else give a long, well written response).
The HEPNet (high energy physics) community is currently migrating from
DECNet Phase IV (the current version of DECNet) to DECNet Phase V, which
uses CLNP, so CLNP is very important to them (maybe someone can give the #
of hosts in HEPnet). The bottom line is that CLNP will not go away.
The fact that CLNP is supported on a large part of the Internet should tell
you something. Network providers don't support something unless people ask
for it and can justify its use.
Russ
P.S. I just saw Eva's response. I think she visited all your questions.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09423;
28 Jul 93 13:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09416;
28 Jul 93 13:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21825;
28 Jul 93 13:39 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09401;
28 Jul 93 13:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09365;
28 Jul 93 13:37 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa21702;
28 Jul 93 13:37 EDT
Received: from Valinor.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-12)
id <AA16283>; Wed, 28 Jul 1993 10:38:16 -0700
Received: by Valinor.Stanford.EDU (5.65/inc-1.0)
id AA29579; Wed, 28 Jul 93 10:38:15 -0700
Date: Wed, 28 Jul 93 10:38:15 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf at valinor.stanford.edu>
To: ietf at isi.edu
Office: Spruce Hall F15, (415) 723-6860
Usmail: Pine Hall 115, Stanford, CA, 94305-4122
Subject: Re: Last Call for TUBA stuff
Message-Id: <CMM.0.90.2.743881095.vaf at Valinor.Stanford.EDU>
What he said.
The Internet cannot afford the political fallout which would result from
putting any of the IPng proposals on the standards track at this time.
The media will go after this one like sharks to a wounded seal...
--Vince
---------------
Date: Wed, 28 Jul 93 03:55:10 EDT
Sender: ietf-request at IETF.CNRI.Reston.VA.US
From: Ran Atkinson <atkinson at itd.nrl.navy.mil>
Message-Id: <9307280755.AA01919 at itd.nrl.navy.mil>
To: ietf at isi.edu
Subject: Re: Last Call for TUBA stuff
Brian and Eva,
There is a distinction between a public specification and a public
specification which is on the Internet standards track.
The needs that both of you describe (ability to specify and purchase
products) can be fully met by an informational status RFC or an
experimental status RFC describing how one would do TUBA if doing TUBA
were locally deemed desirable. There is not consensus amongst the
IETF as a whole that any particular IPng proposal should be widely
deployed at this time. Many many protocols have multiple independent
implementations which interoperate and only have informational status
or experimental status RFC specifications. Gopher is a very recent
example of this (and there is more Gopher traffic than CLNP traffic
across the Internet backbone as of the last official statistics).
In practice, putting out _any_ IPng proposal document on the
standards-track prior to IPng selection will be misread by the trade
press (and also by any zealots who like that IPng proposal) as
endorsement of that proposal by the IESG. Such action will also
constitute undue interference in the IPng process by the IESG. Many
folks are not active in the IETF and will misconstrue such an action.
Craig's reasoning is quite sound and his historical examples are quite
relevant.
NONE of the IPng proposals should be put on the standards-track
until an official selection is made by the IETF as a whole. It is
clearly possible to change the status of an RFC ex post facto, so
this is not an onerous burden on any person, proposal, or group.
Ran
atkinson at itd.nrl.navy.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09911;
28 Jul 93 14:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09904;
28 Jul 93 14:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23156;
28 Jul 93 14:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09880;
28 Jul 93 14:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09795;
28 Jul 93 14:03 EDT
Received: from nic.near.net by CNRI.Reston.VA.US id aa23002; 28 Jul 93 14:03 EDT
Received: from BRONZE.BBN.COM by nic.near.net id aa02923; 28 Jul 93 14:03 EDT
To: Eva Kuiper <eva at hpindda.cup.hp.com>
cc: henryc at oar.net, desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of Wed, 28 Jul 1993 09:37:36 -0700.
<9307281637.AA27967 at hpindda.cup.hp.com>
Date: Wed, 28 Jul 1993 14:01:09 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Curran <jcurran at nic.near.net>
Message-ID: <9307281403.aa23002 at CNRI.Reston.VA.US>
--------
] From: Eva Kuiper <eva at hpindda.cup.hp.com>
] Subject: Re: Last Call: Use of ISO CLNP in TUBA
] Date: Wed, 28 Jul 93 9:37:36 PDT
]
] > (henryc at oar.net)
] > I disagree with the first part of that statement. Just where is
] > CLNP deployed *and* widely used? Does it run on 100,000 hosts yet?
] > Does ANS switch CLNP natively yet? How well does CLNP/TUBA routing
] > work now and how will it scale? Is the TUBA software incorporated
] > in standard releases of router and host software yet?
]
] CLNP code is available from every major router vendor as a product
] today. CLNP is available on almost every host as well as a product.
] ...
] TUBA does not require any code changes to existing CLNP.
] There are dozens of conformance tested CLNP hosts available. This is
] a very stable protocol that has been around for years now. I don't think
] that your fears are really warranted as far as robustness is concerned.
To be fair, CLNP is quite stable as a datagram delivery service. ESIS
and ISIS work today (although the scaling properties of large CLNP networks
are as well known as the scaling properties of large IPv4/CIDR networks. ;-)
On the other hand, TUBA is not "mature" by any means, and its robustness
and operational characteristics are _unknown_. Once the first high-tech
firm shuts down IPv4 internally and switches to using one of the IPng
proposals internally, we'll begin getting true operational feedback on
these protocols.
Can we divert the thread on CLNP/TUBA maturity back to the TUBA mailing list?
The proper handling of IPng proposals appears to be a generic issue; perhaps
the IESG can consider this issue separately and let us know the result?
/John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10179;
28 Jul 93 14:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10170;
28 Jul 93 14:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23715;
28 Jul 93 14:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10145;
28 Jul 93 14:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10091;
28 Jul 93 14:17 EDT
Received: from [128.55.184.155] by CNRI.Reston.VA.US id aa23630;
28 Jul 93 14:17 EDT
Date: Wed, 28 Jul 1993 11:17:33 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tony Hain <ALH at eagle.es.net>
Message-Id: <930728111733.439 at EAGLE.ES.NET>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: henryc at oar.net, ietf at CNRI.Reston.VA.US, tuba at lanl.gov
X-Vmsmail-To: smtp%"henryc at oar.net"
Henry,
This whole discussion is based on a serious 'not-invented-here' attitude that
the IETF needs to loose or die.
>>So far as the issue as to whether this favors CLNP and TUBA
>>as the IPng, I have to say that the TUBA group has been
>>saying over and over that CLNP is already deployed and we
>>need a standard way to run TCP, UDP and the Internet
>>applications over it.
>
>I disagree with the first part of that statement. Just where is
>CLNP deployed *and* widely used? Does it run on 100,000 hosts yet?
If we do not look forward beyond the current deployment we will not be
ready to deal with the limitations of IPv4. The issue is not so much 'has
it been deployed' as it is 'how quickly can it be deployed'.
>Does ANS switch CLNP natively yet?
This has nothing to do with next generation planning. If ANS chooses not to
deploy CLNP they and their customers will live with the limitations of IPv4.
>How well does CLNP/TUBA routing
>work now and how will it scale? Is the TUBA software incorporated
>in standard releases of router and host software yet?
Since BGP4 was defined by the same people it takes many of its concepts from
IDRP. Scale will not be its problem. As for incorporation in releases, the
gating item there is advancing this as a standard. Vendors are VERY reluctant
to invest in development of "non-standard" software, and even more so when
there appears to be a political issue involved. In a way this may relate back
to the ANS deployment issue, would ANS move to deploy CNLP if TUBA were a std?
>As a NSP, I'm very concerned (read scared s**tless) that some new
>IPng protocol (let alone IPv4) will destroy my network.
>
>henry
I share your concern about a new IPng, but I have no concern about the use
of CLNP since we have been running it for several years. I think there should
be more concern about the short life of IPv4. For the last 4 years I have been
trying to get the point across that if the IETF would spend its effort fixing
the problems it can identify in the OSI definitions instead of fighting we
would all be ahead. This gets back to my original comment about 'n-i-h',
TUBA is an attempt to merge the stacks in a non-destructive manner. It suffers
from a contingent that would rather 'OWN' the stack than admit that someone
else might have a useful idea. Integrators have long known how to take the
best ideas from different sources and minimize the amount of work they have
to do to glue it all together.
>>PS: BTW, if you're doing PIP, SIP, or TP/IX, I'll ask you the same
> questions...
Good....but you should also ask how well IPv4 will scale over the next few years.
Tony
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10742;
28 Jul 93 14:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24534;
28 Jul 93 14:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10724;
28 Jul 93 14:48 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08934;
28 Jul 93 13:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-fuller-cidr-strategy-03.txt
Date: Wed, 28 Jul 93 13:17:59 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307281318.aa08934 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Classless Inter-Domain Routing (CIDR): an Address
Assignment and Aggregation Strategy
Author(s) : V. Fuller, T. Li, J. Yu, K. Varadhan
Filename : draft-fuller-cidr-strategy-03.txt
Pages : 24
This memo discusses strategies for address assignment of the existing IP
address space with a view to conserve the address space and stem the
explosive growth of routing tables in default-route-free routers.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-fuller-cidr-strategy-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-fuller-cidr-strategy-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-fuller-cidr-strategy-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-fuller-cidr-strategy-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11287;
28 Jul 93 15:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25690;
28 Jul 93 15:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11275;
28 Jul 93 15:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11152;
28 Jul 93 15:11 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa25519;
28 Jul 93 15:11 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA07879>; Wed, 28 Jul 1993 12:11:45 -0700
Message-Id: <199307281911.AA07879 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1484 on User Friendly Naming
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 28 Jul 93 12:11:43 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1484:
Title: Using the OSI Directory to achieve User Friendly
Naming (OSI-DS 24 (v1.2))
Author: S. Hardcastle-Kille
Mailbox: S.Kille at ISODE.COM
Pages: 25
Characters: 48,974
Updates/Obsoletes: none
The OSI Directory has user friendly naming as a goal. A simple
minded usage of the directory does not achieve this. Two aspects not
achieved are:
o A user oriented notation
o Guessability
This proposal sets out some conventions for representing names in a
friendly manner, and shows how this can be used to achieve really
friendly naming. This then leads to a specification of a format for
representing names, and to procedures to resolve them. This leads to
a specification which allows directory names to be communicated
between humans. The format in this specification is identical to that
defined in 1485, and it is intended that these specifications are
compatible.
This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard. Discussion and suggestions
for improvement are requested. Please refer to the current edition of
the "IAB Official Protocol Standards" 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1484.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1484.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11340;
28 Jul 93 15:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25801;
28 Jul 93 15:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11328;
28 Jul 93 15:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11306;
28 Jul 93 15:15 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa25747;
28 Jul 93 15:15 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA08000>; Wed, 28 Jul 1993 12:15:55 -0700
Message-Id: <199307281915.AA08000 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1485 on Distinguished Names
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 28 Jul 93 12:15:51 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1485:
Title: A String Representation of Distinguished Names
(OSI-DS 23 (v5))
Author: S. Hardcastle-Kille
Mailbox: S.Kille at ISODE.CO
Pages: 7
Characters: 11,158
Updates/Obsoletes: none
The OSI Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in ASN.1.
When a distinguished name is communicated between to users not using a
directory protocol (e.g., in a mail message), there is a need to have
a user-oriented string representation of distinguished name. This
specification defines a string format for representing names, which is
designed to give a clean representation of commonly used names, whilst
being able to represent any distinguished name.
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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-REQUEST at NIC.DDN.MIL.
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 NIC.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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1485.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1485.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12100;
28 Jul 93 15:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12093;
28 Jul 93 15:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27398;
28 Jul 93 15:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12079;
28 Jul 93 15:58 EDT
Received: from SYNW03.elettra.trieste.it by IETF.CNRI.Reston.VA.US id aa12031;
28 Jul 93 15:56 EDT
Date: Wed, 28 Jul 1993 21:55:13 +0200 (WET-DST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Claudio Allocchio - +39 40 3758523 <ALLOCCHIO at elettra.trieste.it>
To: ietf at IETF.CNRI.Reston.VA.US
CC: ALLOCCHIO at elettra.trieste.it
Message-Id: <930728215513.2ae002de at elettra.trieste.it>
Subject: Re: Last Call: Use of ISO CLNP in TUBA - CLNP in HEPnet.
Russ wrote:
>Just a quick comment (I'll let someone else give a long, well written response
>).
>
>The HEPNet (high energy physics) community is currently migrating from
>DECNet Phase IV (the current version of DECNet) to DECNet Phase V, which
>uses CLNP, so CLNP is very important to them (maybe someone can give the #
>of hosts in HEPnet). The bottom line is that CLNP will not go away.
>
>The fact that CLNP is supported on a large part of the Internet should tell
>you something. Network providers don't support something unless people ask
>for it and can justify its use.
>
>
>Russ
well, Russ, I can give you the answer: HEPnet (and its sister twin network
SPAN, the Space Physics Analysis Network) enumerates 45000 so called "visible"
hosts and more than another 70000 hosts currently confined in "regional
networks" (the "hidden areas"). I just got these up to date figures from
Antonia Ghiselli (INFN), the European HEPnet/SPAN manager (the US manager is
Phil Demar - Fermilab)... The whole HEPnet/SPAN started to migrate its
PRODUCTION environemnt to CLNP (DECnet Phase V) already last year, and had
a strict coordination and interaction both with DEC and CISCO to implement
a real multivendor CLNP production network. The migration, due to backward
compatibility reasons, is proceding "as an oil spot", expanding from Turin,
a city in North-West Italy which was the pioneer in late 1991. Currently
the CLNP production environment covers already 4000 hosts and the whole
North and Central Italian HEPnet/SPAN run CLNP. Within 1993 CLNP will cover
completely Italy, France and various regions of Switzerland, Germany,.. and
start to expand to US via the Fermilab-Bologna 512K link.
Sorry about this "little history" of real CLNP... being one of those who
made the bits get through I just wanted to give you some feelings.
This simply imply that CLNP is there and will stay there. Running old
style DECnet style applications like "copy", "set host", "phone", "RMS",
OSI applications like "X.400", "FTAM", or just putting with TUBA "ftp"
"telnet", "talk", "finger" on top of CLNP is somehow "a question of
users' taste". Having a common "lower layers" transport mechanism could
just make life for networkers easier... but time will tell...
Thus I'm really happy about the message from Noel Chiappa... Get rid of
"politics", adopt as Internet Standards the protocols which really works
(nothing against PIP, SIP... is they just work well, fine! the market
will decide) and put IETF back to its technical work (Internet
ENGENEERING task force... is it?).
Ok, that's all, folks! (Bugs Bunny).
Claudio
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12420;
28 Jul 93 16:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12413;
28 Jul 93 16:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28319;
28 Jul 93 16:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12401;
28 Jul 93 16:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12364;
28 Jul 93 16:25 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa28242; 28 Jul 93 16:25 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA00694 for ietf at cnri.reston.va.us; Wed, 28 Jul 93 16:25:42 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA13557; Wed, 28 Jul 93 13:24:19 PDT
Message-Id: <9307282024.AA13557 at aland.bbn.com>
To: Tony Hain <ALH at eagle.es.net>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: henryc at oar.net, ietf at CNRI.Reston.VA.US, tuba at lanl.gov
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 28 Jul 93 13:24:18 -0700
X-Orig-Sender: craig at aland.bbn.com
> This whole discussion is based on a serious 'not-invented-here' attitude that
> the IETF needs to loose or die.
Tony:
I assume the "whole discussion" you are talking about is the question
of whether the current CLNP deployment is sufficiently large to make it
possible to extrapolate how it will scale, not the discussion about whether
we've worked out how we want to handle standardization of the proposed IP:tng
proposals.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12586;
28 Jul 93 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12578;
28 Jul 93 16:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28594;
28 Jul 93 16:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12564;
28 Jul 93 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12522;
28 Jul 93 16:34 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa28527;
28 Jul 93 16:34 EDT
Received: from lbl.gov by venera.isi.edu (5.65c/5.61+local-12)
id <AA22260>; Wed, 28 Jul 1993 13:34:44 -0700
Received: from [131.243.64.68] (macruss.lbl.gov) by lbl.gov (4.1/1.39)
id AA05454; Wed, 28 Jul 93 13:39:46 PDT
Date: Wed, 28 Jul 93 13:39:46 PDT
Message-Id: <9307282039.AA05454 at lbl.gov>
To: Vince Fuller <vaf at valinor.stanford.edu>, ietf at isi.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Russ Wright <wright at lbl.gov>
X-Sender: wright at net.lbl.gov
Subject: Re: Last Call for TUBA stuff
At 10:38 AM 7/28/93 -0700, Vince Fuller wrote:
>What he said.
>
>The Internet cannot afford the political fallout which would result from
>putting any of the IPng proposals on the standards track at this time.
>
Let's not stall this RFC based on weak political reasons. If there are
technical problems, speak up. If not, remember that this is the IETF,
where we pride ourselves on deciding things on technical merit.
>The media will go after this one like sharks to a wounded seal...
>
> --Vince
>
Cute line.
No, we should not ignore the media. As the Internet expands beyond the R&E
community, the media will play a larger role. Let's learn how to work with
them.
Russ
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12886;
28 Jul 93 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12879;
28 Jul 93 16:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29293;
28 Jul 93 16:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12867;
28 Jul 93 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12840;
28 Jul 93 16:53 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa29228;
28 Jul 93 16:53 EDT
Received: from THOR.INNOSOFT.COM by venera.isi.edu (5.65c/5.61+local-12)
id <AA22885>; Wed, 28 Jul 1993 13:53:47 -0700
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id
<01H121MKX58W984NNW at INNOSOFT.COM>; Wed, 28 Jul 1993 13:53:41 PST
Date: Wed, 28 Jul 1993 13:51:17 -0800 (PST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ned Freed <NED at innosoft.com>
Subject: RE: Last Call for TUBA stuff
In-Reply-To: Your message dated "Wed, 28 Jul 1993 10:38:15 -0700 (PDT)"
<CMM.0.90.2.743881095.vaf at Valinor.Stanford.EDU>
To: Vince Fuller <vaf at valinor.stanford.edu>
Cc: ietf at isi.edu
Message-Id: <01H12TQRCO20984NNW at INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
> The Internet cannot afford the political fallout which would result from
> putting any of the IPng proposals on the standards track at this time.
I agree with Ran and Vince on this. The fallout would be huge, the benefits no
greater than simply issuing these documents as either experimental or prototype
specifications.
> The media will go after this one like sharks to a wounded seal...
This is, if anything, an understatement. We've already had enough press
problems with IPng; we don't need any more.
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12973;
28 Jul 93 17:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12966;
28 Jul 93 17:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29582;
28 Jul 93 17:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12953;
28 Jul 93 17:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12929;
28 Jul 93 17:00 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa29472; 28 Jul 93 17:00 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA04268 for ietf at cnri.reston.va.us; Wed, 28 Jul 93 17:00:56 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA13765; Wed, 28 Jul 93 13:59:32 PDT
Message-Id: <9307282059.AA13765 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: re: Last Call for TUBA...
Reply-To: Craig Partridge <craig at aland.bbn.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 28 Jul 93 13:59:32 -0700
X-Orig-Sender: craig at aland.bbn.com
Hi folks:
It seems to me that the critical issue before advancing any proposal,
TUBA, SIP, PIP, etc. (there was another proposed in a note to tcp-ip
yesterday :-)), is that we have a clearly enunciated plan for handling
issues like press perceptions that one proposal is ahead or behind based
on when it achieves proposed standard status, and some thoughts about how
we're eventually going to resolve the muddle.
My initial note was motivated in large part by the strong belief that
the IETF and IESG have not yet developed such a plan and that forging ahead
without a plan is a good way to get lost. Private communications today with
various IESG, IAB and IETF members, plus the discussion on this list
have confirmed that this is indeed the case. We don't have a clear
plan. Everyone's doing their best but we aren't quite there yet.
My sense of today's public discussion is that few people think it would
be a travesty to make TUBA a Proposed Standard, once a clear plan is in
place and has been explained both to the IETF and the larger community
of users and media for handling the IP:tng issues. But a lot of people
(myself included) feel moving a protocol document ahead when we don't know
why and how we're doing it, is premature.
Craig
E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13134;
28 Jul 93 17:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13130;
28 Jul 93 17:11 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa29837;
28 Jul 93 17:11 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (5.65/%I%)
id AA25794; Wed, 28 Jul 93 15:01:59 -0600
Received: by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA21414; Wed, 28 Jul 93 14:59:11 MDT
Return-Path: <@bronze.bbn.com:jcurran at nic.near.net>
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA21406; Wed, 28 Jul 93 14:59:10 MDT
Received: from nic.near.net by mailhost.lanl.gov (5.65/%I%)
id AA10220; Wed, 28 Jul 93 12:04:43 -0600
Message-Id: <9307281804.AA10220 at mailhost.lanl.gov>
Received: from BRONZE.BBN.COM by nic.near.net id aa02923; 28 Jul 93 14:03 EDT
To: Eva Kuiper <eva at hpindda.cup.hp.com>
Cc: henryc at oar.net, desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of Wed, 28 Jul 1993 09:37:36 -0700.
<9307281637.AA27967 at hpindda.cup.hp.com>
Date: Wed, 28 Jul 1993 14:01:09 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Curran <jcurran at nic.near.net>
--------
] From: Eva Kuiper <eva at hpindda.cup.hp.com>
] Subject: Re: Last Call: Use of ISO CLNP in TUBA
] Date: Wed, 28 Jul 93 9:37:36 PDT
]
] > (henryc at oar.net)
] > I disagree with the first part of that statement. Just where is
] > CLNP deployed *and* widely used? Does it run on 100,000 hosts yet?
] > Does ANS switch CLNP natively yet? How well does CLNP/TUBA routing
] > work now and how will it scale? Is the TUBA software incorporated
] > in standard releases of router and host software yet?
]
] CLNP code is available from every major router vendor as a product
] today. CLNP is available on almost every host as well as a product.
] ...
] TUBA does not require any code changes to existing CLNP.
] There are dozens of conformance tested CLNP hosts available. This is
] a very stable protocol that has been around for years now. I don't think
] that your fears are really warranted as far as robustness is concerned.
To be fair, CLNP is quite stable as a datagram delivery service. ESIS
and ISIS work today (although the scaling properties of large CLNP networks
are as well known as the scaling properties of large IPv4/CIDR networks. ;-)
On the other hand, TUBA is not "mature" by any means, and its robustness
and operational characteristics are _unknown_. Once the first high-tech
firm shuts down IPv4 internally and switches to using one of the IPng
proposals internally, we'll begin getting true operational feedback on
these protocols.
Can we divert the thread on CLNP/TUBA maturity back to the TUBA mailing list?
The proper handling of IPng proposals appears to be a generic issue; perhaps
the IESG can consider this issue separately and let us know the result?
/John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13276;
28 Jul 93 17:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13269;
28 Jul 93 17:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00226;
28 Jul 93 17:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13257;
28 Jul 93 17:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13224;
28 Jul 93 17:17 EDT
Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa00146;
28 Jul 93 17:17 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id
<01H121MKX58W984NNW at INNOSOFT.COM>; Wed, 28 Jul 1993 14:18:12 PST
Date: Wed, 28 Jul 1993 14:08:26 -0800 (PST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ned Freed <NED at innosoft.com>
Subject: RE: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message dated "Wed, 28 Jul 1993 11:17:33 -0700 (PDT)"
<930728111733.439 at EAGLE.ES.NET>
To: Tony Hain <ALH at eagle.es.net>
Cc: henryc at oar.net, ietf at CNRI.Reston.VA.US, tuba at lanl.gov
Message-id: <01H12UM49SLC984NNW at INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
> This whole discussion is based on a serious 'not-invented-here' attitude that
> the IETF needs to loose or die.
I beg your pardon? While some contributers to this discussion might possibly
have said things that could be contrued this way, plenty of posters have
objected and cited reasons having nothing whatsoever to do with where work was
done. As such, any characterization of the entire group of those opposed to the
elevation of this part of TUBA to proposed standard status as practitioners of
NIH is *grossly* in error.
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.
